Inheritable Smart Contract Wallet

Summary

The issue of Missing ETH Receive Functionality is identified in the InheritanceManager contract. Specifically, it stems from the absence of a receive() or fallback() function in the contract, which prevents the contract from natively accepting Ether sent via direct transfers (e.g., transfer() or send()).

Finding Description

The InheritanceManager contract has functions like sendETH for sending Ether out of the contract, but it does not have a mechanism to receive Ether directly. For example:

While this function allows the owner to send ETH out of the contract, there is no corresponding function to handle incoming ETH transfers. If someone sends ETH directly to the contract address (e.g., via transfer() or send()), the transaction will fail because the contract cannot handle such transfers.

Why This Is a Problem

• ETH Locked: Any ETH sent directly to the contract (not through sendETH) will be permanently locked because the contract cannot process it.

• User Experience: Users expecting to deposit ETH directly into the contract (e.g., for inheritance purposes) will face failed transactions, leading to confusion and potential loss of funds.

• Documentation Misalignment: The contract's functionality implies it can handle ETH (since it has sendETH), but the lack of a receive() function contradicts this expectation.

Impact Explanation

While this does not directly lead to fund loss (since ETH can still be sent via sendETH), it creates a poor user experience and risks locking funds if users mistakenly send ETH directly to the contract.

Recommendation

Add a receive() function to handle direct ETH transfers and reset the inactivity timer: