The LikeRegistry
contract's likeUser()
function has a potential vulnerability where funds can become permanently locked if a match is not successfully established. Since fund distribution relies on mutual execution of likeUser()
, any one-sided interaction without a corresponding response results in the funds being trapped in the contract indefinitely, with no ability for the owner or any user to retrieve them.
When using the likeUser()
function in the LikeRegistry
contract, if a match is not established, the funds used for the transaction become locked within the contract.
For a successful match and subsequent fund distribution, both parties must execute likeUser()
reciprocally. However, if only one party executes likeUser()
and no further action is taken, the funds remain trapped in the contract. In this scenario, even the contract owner is unable to retrieve or control the locked funds.
The inability to retrieve locked funds in the contract can lead to significant financial and operational risks. Users who initiate a likeUser()
transaction without receiving a reciprocal action may permanently lose the funds they sent, as there is no mechanism to reclaim them. This creates a financial loss for participants who are unable to complete a match.
Additionally, the accumulation of locked funds over time compromises the contract’s overall usability and efficiency. As more users encounter this issue, the contract may become increasingly difficult to use, discouraging participation and limiting its effectiveness. The lack of a resolution process means that funds will continue to accumulate in the contract without a way to distribute or return them, potentially leading to scalability issues. If a large number of transactions result in locked funds, the contract’s functionality may degrade, increasing inefficiencies and reducing its long-term viability.
Manual Audit
To mitigate the risk of funds being permanently locked in the contract, implementing a timeout mechanism would be an effective solution. If a match is not completed within a predefined period, the funds should automatically be refunded to the initiating user. Additionally, introducing an admin recovery function could provide a controlled way for the contract owner or an authorized entity to retrieve and reallocate locked funds under specific conditions.
An escrow-based approach may also improve the security of fund management by ensuring that funds are only deducted when a match is successfully established. Furthermore, allowing users to reclaim their funds if no match occurs within a reasonable timeframe would provide an additional safeguard, preventing funds from being indefinitely trapped in the contract.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.