Core Contracts

The `_executeProposal()` function calls the timelock's `executeBatch()` in the `TimelockController.sol` function to forward ETH to target contracts as part of scheduled operations. However, the timelock contract itself lacks a `receive()` or `fallback()` function to accept ETH. This design will cause as it is expected to hold ETH for executing operations.

​

​

Within `_executeProposal()`, the contract retrieves a proposal, computes a unique operation ID using a salt, and then calls the timelock's `executeBatch()` function. The `executeBatch()` function is declared as payable and forwards ETH to the target contracts using the specified values array:

​

Each target is called with a specific ETH value, as shown in the loop within `executeBatch()`. However, the timelock contract itself does not implement a `receive()` or `fallback()` function. As a result:

​

Accidental ETH Transfers: If a user mistakenly sends ETH directly to the timelock contract (outside of a function call), the transaction will revert, since the contract cannot accept such transfers.

Funding Challenges: the design expects the timelock to hold ETH (e.g., via explicit deposits), the lack of a receive mechanism will lead to insufficient funds for executing scheduled operations, or any ETH sent to it might become inaccessible.

​

​

​

Since the contract lacks a receive() function, the transaction immediately reverts, and the ETH is not deposited.

Alternatively, if the protocol intends for the timelock to be pre-funded for executing operations, the absence of a fallback mechanism will prevent the accumulation of necessary funds, causing later operations to fail.

Operational Failures: Scheduled operations will fail if the timelock cannot receive or hold the necessary ETH, potentially leading to reverts during the execution of proposals.

Implement a `receive()` Function:

Add a simple receive function to allow the timelock contract to accept ETH:

​

receive() external payable {}

Implement a `fallback()` Function (if necessary):

​

Optionally, add a fallback function to handle any unexpected calls with ETH:

​

fallback() external payable {}

​

Clarify the Funding Mechanism:

Document the intended method for funding the timelock contract. If the contract is expected to be pre-funded through a specific function or mechanism, ensure that this is clearly defined and that any excess ETH is handled gracefully.

​

By implementing these changes, the timelock contract will be able to receive ETH, thereby reducing the risk of operational failures and preventing potential user errors or locked funds.

​