A governance timelock is an enforced waiting period between the moment a proposal passes and the moment it can actually run. Instead of a winning vote executing immediately, its calls are queued in a timelock contract and become executable only after a fixed delay has elapsed. The pattern was popularised by Compound's Timelock.sol and is now a near-universal component of on-chain governance, standardised as the OpenZeppelin TimelockController. It is the safety valve that turns a governance vote from an instant, irreversible command into a change everyone can see coming.
On-chain governance concentrates enormous power in a passing vote: the ability to upgrade a contract, drain a treasury, or repoint an oracle. If that power executed the instant a vote closed, a single malicious proposal – or a governance attack that borrowed enough votes for one block – could act before anyone could respond. The timelock breaks that immediacy. Between the vote and the action there is a public, on-chain queue and a countdown.
That window does three things. It gives users an exit: anyone who disagrees with a queued change can withdraw funds or unwind positions before it lands. It gives the community time to react – to coordinate a counter-proposal, alert exchanges, or trigger an emergency pause. It is also the usual answer to a late-vote swings, where the surprise arrives too late in the voting period for anyone to vote against it. And it makes vote-borrowing attacks far less profitable, because an attacker who flash-borrows governance tokens to pass a proposal has long since had to return them by the time the timelock lets the proposal execute. OpenZeppelin frames the timelock as the mechanism that lets a project protect users by making privileged actions publicly visible before they take effect.
The timelock is the step between approval and execution. In a typical Governor-plus-Timelock system the flow runs: propose → vote → queue → timelock delay → execute (see the full DAO proposal lifecycle). Compound's timeline is the reference shape: a 3-day voting period, then a 2-day timelock before the queued calls can run, so any protocol change takes at least a week end to end.
Many implementations also add a grace period after the delay – a bounded window in which the proposal must be executed or it expires – so stale, forgotten proposals cannot be actioned months later. The timelock is also the enabling primitive for optimistic governance, where a queued proposal executes automatically once the delay passes unless a veto arrives inside the window.
Timelock length is a direct tradeoff between safety and agility. A longer delay gives users more time to exit and the community more time to catch a bad proposal, but it also slows every legitimate change – including urgent security fixes. A delay that is too short protects no one; a delay that is too long makes the protocol unable to respond to a live exploit.
Large protocols resolve this tension with a two-track design: a long timelock for ordinary governance, plus a small, fast-moving multisig – a security council – that can act inside a much shorter window for emergencies. Arbitrum's constitution pairs constitutional timelocks with a 12-of-12 Security Council that can fast-track patches, and Optimism's Superchain documents a similar set of privileged, time-bounded roles. The council's own power is itself a centralisation risk, which is why its membership, thresholds, and scope are usually the most-scrutinised part of a DAO's security model.
minDelay.A timelock is only as strong as what it actually gates. Common failure modes include a privileged admin key or upgradeable proxy that can change contract logic without passing through the timelock – a bypass that makes the visible delay theatre; an executor or canceller role concentrated in too few hands; and a delay set so short that no real user could act inside it. Timelocks also cannot stop a proposal that is malicious and unnoticed – the window only helps if someone is watching, which is why the timelock is paired with monitoring, alerting, and an engaged electorate rather than trusted to work alone.
The window a timelock creates is the on-chain analogue of a broader principle: the value of the exit lies in being able to leave before a decision binds you. See rage-quit and exit rights, DAO security and governance attacks, and – for the opposite end state, where a contract is made immutable so nothing can be changed – governance minimization.
Caper builds a window directly into its proposal machinery, and it is a veto window rather than a delay. A legislative pass executes nothing: a winning executive option has to be triggered, and the trigger opens the market window, during which the caper's own holders can stop the action by selling. The proposal executes only if the token's time-weighted average price over that window is at or above the trailing baseline locked at the trigger, so a proposal that only won because someone bought votes at the last moment still has to survive a window in which everyone else can sell against it (proposals, execution).
Platform upgrades use a second, separate timelock: the passing $CAPER proposal first proposes the new logic and starts a delay, and a second call only activates it once the delay has elapsed – the same propose → timelock → activate shape this page describes, applied to the protocol's own code. The length of that delay is a stored field on the registry rather than a constant, and on the live deployment it is set to zero: the one upgrade performed so far proposed and activated inside a single transaction, its MainProposed event recording a not_before equal to the second it committed. The shape is a timelock; the window, as configured today, is not one. See Execution and Proposals for how the per-proposal window fits into a Caper vote, and What is a Caper for the wider model.