The contract lacks an internal accounting ledger. The proposeTransaction function does not verify if the value is valid or if it exceeds the contract's available balance. Furthermore, executeTransaction only checks address(this).balance instead of verifying the actual usable funds. This allows multiple invalid transactions to be proposed, leading to significant Gas waste as signers expend resources on transactions destined to fail. Additionally, it causes management chaos, flooding the multisig queue with unexecutable "zombie transactions.
Likelihood: The contract fails to verify the actual available balance, allowing owners to create transactions that are destined to fail due to the lack of fund tracking.
Impact:
Gas Waste: Signers lose non-refundable gas fees confirming transactions destined to fail.
Operational DoS: The queue is cluttered with "zombie transactions," hindering the identification of valid operations.
Fund Blocking: Pending high-value proposals may obscure or delay urgent, executable transactions.
The owner created two transactions with a total value exceeding the contract balance. Due to the lack of balance checks, both were successfully proposed and confirmed. However, only the first transaction could execute; the second one inevitably reverted due to insufficient funds. As a result, a transaction destined to fail wasted 199,680 Gas.
place the following code in MultiSigTimelockTest.t.sol:
Implement a state variable s_totalPendingAmount to track funds committed to active proposals.
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.