The LikeRegistry
contract does not provide a mechanism to manage or withdraw Ether that is sent directly to the contract. Due to the presence of a receive()
function, the contract can receive Ether outside of standard transaction flows. Additionally, Ether may be sent to the contract through selfdestruct
, which forcefully transfers funds without invoking any function in the contract. Since there is no logic in place to handle these scenarios, any Ether received in this manner becomes permanently locked within the contract, making it inaccessible to users or the contract owner.
The contract includes a receive()
function, which allows it to accept direct Ether transfers. However, there is no function to manage or withdraw these funds, meaning that any Ether received outside of controlled transactions is effectively trapped. This issue is further compounded by the fact that Ethereum’s selfdestruct
function allows external contracts to forcibly send Ether to any address, including LikeRegistry
. Since the contract does not have a withdrawal or recovery mechanism, funds received through these methods cannot be retrieved or utilized.
Once Ether is locked in the contract’s balance, there is no way for users or the owner to access it. This can result in an accumulation of unusable funds over time, reducing the contract’s efficiency and potentially creating financial losses. Without a proper way to reclaim these funds, the contract remains vulnerable to an unintended Ether accumulation problem, where a growing balance of inaccessible funds becomes a long-term issue.
The inability to manage the contract's balance can lead to a scenario where Ether accumulates indefinitely without any means of retrieval. This not only results in financial inefficiencies but also increases the risk of accidental fund losses. If a significant amount of Ether is sent to the contract through direct transfers or selfdestruct operations, those funds become permanently unusable. Over time, this could create an operational burden, where the contract holds a large, inaccessible balance that serves no functional purpose.
Manual Audit
To prevent Ether from becoming permanently locked within the contract, a controlled withdrawal mechanism should be implemented. The contract should include a function that allows an authorized entity, such as the owner, to withdraw excess Ether that is not actively used in the protocol. This function should ensure that only legitimate funds are accessible while preventing unauthorized withdrawals.
Additionally, the contract should restrict direct transfers by modifying the receive()
function to revert transactions unless explicitly called within a known, controlled process. Implementing a safeguard against unintended deposits can help prevent funds from being unintentionally locked.
If external contracts are expected to interact with LikeRegistry
, alternative designs should be considered, such as enforcing structured deposit and withdrawal mechanisms. By implementing these improvements, the contract can prevent the risk of uncontrolled Ether accumulation while maintaining proper financial management within the system.
Not the best design, but if you send money accidentally, that's a user mistake. Informational.
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.