---
title: "Governance timelocks"
url: "https://caper.network/wiki/dao-governance/concepts/voting/governance-timelocks"
updated: 2026-09-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Governance timelocks

|  |  |
| --- | --- |
| **Topic** | The enforced delay between a governance proposal passing and its on-chain execution |
| **Core rule** | A passed proposal is _queued_, not run; it can only be executed after a fixed waiting period elapses |
| **Also called** | Governance timelock, execution delay, timelock controller, review window |
| **Solves** | Gives token holders and users a window to react, exit, or raise the alarm before a malicious or mistaken change takes effect |
| **Typical delay** | ~2 days on major protocols ([Compound](https://docs.compound.finance/v2/governance), [Uniswap](https://developers.uniswap.org/docs/ecosystem/governance/overview)); minutes-to-days depending on stakes |
| **Key risk** | A delay short enough to be useless, or a privileged key that can bypass it entirely |
| **Canonical implementations** | [Compound Timelock](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol), [OpenZeppelin TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance) |

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`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol) and is now a near-universal component of on-chain governance, standardised as the [OpenZeppelin `TimelockController`](https://docs.openzeppelin.com/contracts/5.x/api/governance). It is the safety valve that turns a governance vote from an instant, irreversible command into a change everyone can see coming.

## Why timelocks exist

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. 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](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks).

## Where it sits in the proposal lifecycle

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](/wiki/dao-governance/concepts/voting/proposal-lifecycle)). [Compound's timeline](https://docs.compound.finance/v2/governance) 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](/wiki/dao-governance/concepts/voting/optimistic-governance), where a queued proposal executes automatically once the delay passes _unless_ a veto arrives inside the window.

## Choosing the delay: the core tradeoff

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](/wiki/dao-governance/tooling/treasury/safe) — a [_security council_](/wiki/dao-governance/concepts/fundamentals/security-councils) — that can act inside a much shorter window for emergencies. [Arbitrum's constitution](https://docs.arbitrum.foundation/dao-constitution) pairs constitutional timelocks with a 12-of-12 Security Council that can fast-track patches, and [Optimism's Superchain](https://docs.optimism.io/superchain/privileged-roles) 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.

## In production

- **[Compound](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol)** — the original on-chain Governor + Timelock, with a 2-day execution delay and enforced minimum/maximum delay bounds. Its design was forked across DeFi.
- **[OpenZeppelin TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance)** — the audited, reusable standard most new DAOs deploy, with separate proposer, executor, and canceller roles and a configurable `minDelay`.
- **[Uniswap](https://developers.uniswap.org/docs/ecosystem/governance/overview)** — a Governor Bravo derivative whose passed proposals queue into a timelock before execution.
- **[Arbitrum](https://docs.arbitrum.foundation/dao-constitution)** and **[Optimism](https://docs.optimism.io/superchain/privileged-roles)** — L2 DAOs that combine constitutional timelocks with an emergency Security Council. Queued actions are typically surfaced by governance dashboards such as [Tally](/wiki/dao-governance/tooling/voting/tally).

## Limits and failure modes

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](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), and — for the opposite end state, where a contract is made immutable so _nothing_ can be changed — [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization).

## How Caper approaches this

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](/wiki/governance/proposals), [execution](/wiki/governance/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](https://stokenet-dashboard.radixdlt.com/transaction/txid_tdx_2_1gyn66jhux2qcx7qgrfyt4e7m0pkq8yhymauqn6sgh3ghuk7culasxshjz3) 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](/wiki/governance/execution) and [Proposals](/wiki/governance/proposals) for how the per-proposal window fits into a Caper vote, and [What is a Caper](/wiki/foundations/what-is-a-caper) for the wider model.