MultiSig Timelock

First Flight #55
Beginner FriendlyWallet
100 EXP
Submission Details
Impact: high
Likelihood: high

No proposal/confirmation rate limits enable signer fatigue attacks

Author Revealed upon completion

Scope
src/MultiSigTimelock.sol: proposeTransaction, confirmTransaction

Root + Impact

Description

  • Normal behavior: Multisigs should throttle proposal and approval cadence.

  • Issue: There are no per-signer or global rate limits. An attacker with the owner key can spam thousands of proposals; a malicious signer can spam confirmations/revocations to create alert fatigue and front-run legitimate executions.

// no per-signer counters or cooldowns

Risk

Likelihood:

  • Reason 1 // Automation makes spam trivial

  • Reason 2 // Social-engineering relies on noisy channels to hide payloads

Impact:

  • Impact 1 // Signers miss critical malicious proposals buried in noise

  • Impact 2 // Gas and time wasted on repeated confirmations/revocations

Proof of Concept

Explanation: Bot submits hundreds of proposals per minute; signers cannot review them all, increasing odds of approving a hidden malicious call.

// tight loop proposeTransaction(); confirmTransaction() in same block

Recommended Mitigation

Explanation: Add cooldowns and per-signer daily quotas on proposals and confirmations, enforced on-chain.

+ mapping(address => uint256) private s_lastConfirm;
+ require(block.timestamp - s_lastConfirm[msg.sender] > CONFIRM_COOLDOWN, "cooldown");

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!