A timelock is a delay between when a governance vote passes and when the change actually executes on-chain. Two days, seven days, sometimes longer for high-impact changes.
The timelock exists for one reason: the window for users to exit before they are bound by the new rule.
Without a timelock
A malicious proposal — say, "change the treasury withdrawal address to attacker.eth" — passes at midnight, executes at 12:01am, drains the treasury by 12:05am. By the time you wake up, the rule was changed AND its consequence was applied.
With a 48-hour timelock
The same proposal passes at midnight but cannot execute until two days later. Users see the queued action, scream about it on social media, withdraw their funds, and exit. The attacker still wins the vote but cannot capture the value because everyone has left.
Timelock anti-patterns to recognise
- Timelocks that the council can bypass. If a multisig has the power to fast-track, the timelock is theatre.
- Inconsistent timelocks per action. Critical actions should always have the longest timelock, not the shortest.
- Timelocks shorter than the protocol's withdrawal time. If you cannot exit before the change takes effect, the timelock did not protect you.
- Pause keys without an attendant timelock. A "pause" action that takes effect instantly is a privileged operator capability, not a governance one.