Multisigs & Timelocks

Multisig wallets and Timelock contracts are governance primitives that reduce single points of failure in protocol administration. When a contract's owner is a 3-of-5 multisig with a 48-hour timelock, malicious upgrades require compromising multiple parties and surviving public scrutiny. When the owner is a single EOA, one leaked private key ends the game.

---

TL;DR

• Multisigs require M-of-N signers to approve transactions—no single party can act alone
• Timelocks enforce mandatory delays between proposal and execution, giving users time to exit
• Neither technology prevents attacks—they raise the bar for coordination and provide warning windows
• The $1.5B Bybit hack (February 2025) bypassed a multisig cold wallet by compromising the signing interface, not the smart contract
• Look for multisig + timelock combinations when evaluating protocol security; either alone is insufficient
• Common configurations: 2-of-3 for small teams, 3-of-5 for treasuries, 4-of-7+ for major protocols
• Timelock delays under 24 hours provide limited protection; 48-72 hours is standard for critical functions

---

What Is a Multisig?

A multi-signature (multisig) wallet is a Smart Contract that requires multiple private keys to authorize transactions. Instead of a single owner controlling funds or admin functions, authority is distributed across N signers, with M signatures required to execute any action.

flowchart LR
    subgraph Signers
        S1[Signer 1]
        S2[Signer 2]
        S3[Signer 3]
    end

    S1 -->|Signs| TX[Transaction Proposal]
    S2 -->|Signs| TX
    S3 -.->|Optional| TX

    TX -->|2-of-3 Threshold Met| MS[Multisig Contract]
    MS -->|Execute| TARGET[Target Contract]

Figure 1: A 2-of-3 multisig requires any two signers to approve before execution.

M-of-N Configurations

The threshold configuration determines the balance between security and operational flexibility:

CONFIG	REDUNDANCY	SECURITY	USE CASE
2-of-3	Can lose 1 key	2 compromises needed	Small teams, personal funds
3-of-5	Can lose 2 keys	3 compromises needed	Protocol treasuries
4-of-7	Can lose 3 keys	4 compromises needed	Major DAOs, exchanges
6-of-9	Can lose 3 keys	6 compromises needed	High-value treasuries

Avoid edge cases:

• 1-of-N: Single point of failure, defeats the purpose
• N-of-N: One lost key locks funds permanently

The general rule: M = (N/2) + 1 balances security with redundancy.

---

What Is a Timelock?

A timelock is a smart contract that enforces a mandatory delay between proposing an action and executing it. Privileged functions must wait in a queue, visible on-chain, before taking effect.

sequenceDiagram
    participant Admin
    participant Timelock
    participant Protocol
    participant Users

    Admin->>Timelock: Queue transaction
    Note over Timelock: Delay period starts (e.g., 48h)
    Timelock-->>Users: Transaction visible on-chain
    Note over Users: Review window
    Users->>Users: Exit if malicious
    Admin->>Timelock: Execute (after delay)
    Timelock->>Protocol: Apply changes

Figure 2: Timelock flow showing the review window between proposal and execution.

Common Delay Periods

DELAY	PROTECTION LEVEL	TYPICAL USE
6 hours	Minimal	Non-critical parameter changes
24 hours	Low	Routine upgrades
48 hours	Standard	Treasury operations, contract upgrades
72+ hours	High	Critical protocol changes

PancakeSwap uses a 6-hour timelock for all protocol changes. The Beanstalk protocol used a 24-hour delay—which proved insufficient when attackers executed a malicious governance proposal before the community could respond.

---

Why They Matter

Single Points of Failure

Without these mechanisms, protocol security reduces to protecting a single private key:

OWNER TYPE	ATTACK VECTOR	IMPACT
Single EOA	Phishing, malware, social engineering	Immediate total loss
Multisig only	Compromise M signers	Immediate total loss
Timelock only	Single key compromise	Delayed but unstoppable
Multisig + Timelock	Compromise M signers + survive delay	Attackers exposed, users can exit

The Trust Spectrum

Less Secure                                                    More Secure
    │                                                              │
    ▼                                                              ▼
┌────────┐    ┌──────────┐    ┌───────────┐    ┌─────────────────┐
│Single  │───▶│ Multisig │───▶│ Multisig  │───▶│ DAO Governance  │
│  EOA   │    │   Only   │    │+ Timelock │    │ + Multisig +    │
│        │    │          │    │           │    │   Timelock      │
└────────┘    └──────────┘    └───────────┘    └─────────────────┘

---

How They Work Together

The combination of multisig and timelock creates defense in depth:

1. Multisig prevents unilateral action—multiple parties must collude
2. Timelock provides transparency—proposed changes are publicly visible
3. Together they create an exit window—users can withdraw before malicious changes execute

Real-World Implementations

Compound Finance pioneered the pattern with their governance timelock. Administrative changes require:

• Proposal submission (visible on-chain)
• Voting period (token holders vote)
• Timelock queue (mandatory delay)
• Execution (after delay expires)

Uniswap DAO manages over $2B using a 4-of-7 Safe multisig. Major protocol changes go through governance votes with timelocked execution.

---

What Can Go Wrong

The Bybit Hack (February 2025)

The largest crypto heist in history—$1.5 billion stolen from a multisig cold wallet—demonstrated that smart contract security is necessary but not sufficient.

What happened:

• Bybit used a Safe (Gnosis) multisig for their cold wallet
• The Lazarus Group (North Korean state hackers) compromised a Safe developer's machine
• Malicious JavaScript was injected into Safe's AWS S3 bucket
• The code specifically targeted Bybit's contract address
• During a routine transfer, the signing interface displayed legitimate-looking transaction data
• Signers approved what appeared to be a normal transfer
• The actual transaction replaced the multisig implementation contract with an attacker-controlled version (exploiting Proxy Contract upgrade mechanism)
• Attackers drained 400,000+ ETH without needing additional signatures

Key lesson: The multisig smart contract was never compromised. The attack exploited the human-computer interface layer. Signers approved a malicious transaction because they trusted what their screens displayed.

For technical details on how proxy upgrades work and what can go wrong, see Proxy Contracts & Upgradeability.

Other Attack Vectors

ATTACK	DESCRIPTION	MITIGATION
Blind signing	Signers approve without verifying transaction details	Hardware wallet verification, transaction simulation
Social engineering	Manipulating signers through phishing or impersonation	Security training, out-of-band verification
Signer collusion	M signers coordinate malicious action	Geographic/organizational distribution of signers
Key compromise	Individual signer keys stolen	Hardware wallets, key rotation procedures
Short timelock	Insufficient delay for community response	48+ hour minimum for critical functions
Timelock bypass	Admin retains ability to skip delay	Verify timelock cannot be bypassed

Warning Signs

Red flags when evaluating protocol governance:

• ☒ Single EOA owner with no multisig
• ☒ Multisig with low threshold (1-of-N or 2-of-N with large N)
• ☒ Timelock under 24 hours for critical functions
• ☒ Admin can bypass timelock for "emergencies"
• ☒ Signer addresses are unknown or anonymous
• ☒ No transaction simulation or verification process

Green flags:

• ☑ 3-of-5 or higher multisig threshold
• ☑ 48+ hour timelock on upgrades and treasury
• ☑ Known, distributed signer set (different orgs, geographies)
• ☑ Hardware wallet requirement for signers
• ☑ Transaction simulation before signing
• ☑ Public governance process with community oversight

---

Verification Checklist

When researching a protocol's governance:

1. Find the owner address - Check the admin/owner slot on the main contracts
2. Identify wallet type - Is it an EOA or contract? If contract, is it a known multisig?
3. Check threshold - For Safe wallets, call getThreshold() and getOwners()
4. Verify timelock - Look for timelock contracts in the admin chain
5. Review delay period - Check the delay variable on timelock contracts
6. Monitor proposals - Watch for queued transactions in the timelock

Tools for verification:

• Etherscan contract read functions
• Safe{Wallet} interface for multisig details
• DefiLlama governance dashboards
• Protocol documentation (verify against on-chain data)

---

References

• Cantina: A Guide to Multi-Sig Security in 2025
• Certora: The Bybit Hack and Multisig Wallet Security
• Hacken: Bybit Hack Investigation
• OpenZeppelin: Protect Your Users With Smart Contract Timelocks
• OpenZeppelin: Admin Accounts and Multisigs
• SEAL: Secure Multisig Best Practices
• CertiK: What is a Timelock?
• Safe{Wallet}

---

Changelog

DATE	AUTHOR	NOTES
2026-01-04	Artificial.	Generated by robots.
2026-01-08	Denizen.	Reviewed, edited, and curated by humans.