K ♣ · Coordination · Draft
Time-delay Execution
A mandatory waiting period between a proposal passing and its code running, so members can react.
How it works
A proposal passes its vote. Instead of executing at once, it is queued in a timelock contract with a fixed delay, often 24 to 72 hours. During the delay, the queued actions are public and anyone can inspect them. If members spot a bug or an attack, they can respond: sell, exit, or call an emergency veto if one exists. When the delay ends, anyone can trigger execution and the actions run exactly as queued. The same delay also stops a rushed change from surprising users and other projects built on it.
Use it when
- You want members to be able to exit before a decision they oppose takes effect.
- Protect the protocol from a flash-loan vote or a hijacked multisig.
- Give auditors and dependent projects time to check an upgrade before it goes live.
Watch out for
- Urgent fixes, such as patching a live exploit, must also wait, unless there is a separate emergency path.
- A delay only helps if someone is watching the queue and can act on what they see.
Example
MakerDAO. MakerDAO added a Governance Security Module in 2019 that holds every passed executive vote for a set delay before it can change the protocol.