Why timelocks exist On-chain …, a single malicious proposal —– or a governance attack that b…ed enough votes for one block —– could act before anyone could…s the community time to react —– to coordinate a counter-propo…th-smart-contract-timelocks) .

Where it sits in the proposal … grace period after the delay —– a bounded window in which the…ust be executed or it expires —– so stale, forgotten proposals…eto arrives inside the window.

Choosing the delay: the core t…slows every legitimate change —– including urgent security fix…nance/tooling/treasury/safe) —– a security council (/wiki/da…damentals/security-councils) —– that can act inside a much sh…art of a DAO's security model.

In production - Compound (ht…ster/contracts/Timelock.sol) —– the original on-chain Governo…ontracts/5.x/api/governance) —– the audited, reusable standar…osystem/governance/overview) —– a Governor Bravo derivative w…superchain/privileged-roles) —– L2 DAOs that combine constitu…rnance/tooling/voting/tally) .

Limits and failure modes A ti… passing through the timelock —– a bypass that makes the visib…at is malicious and unnoticed —– the window only helps if some…and-governance-attacks) , and —– for the opposite end state, w…ble so nothing can be changed —– governance minimization (/wi…als/governance-minimization) .

Why timelocks exist On-chain …or trigger an emergency pause. It is also the usual answer to a late-vote swings (/wiki/dao-governance/concepts/voting/late-vote-swings) , where the surprise arrives too late in the voting period for anyone to vote against it. And it makes vote-borrowing a…th-smart-contract-timelocks) .

How Caper approaches this Caper builds an execution delay window directly into its proposal machinery. Every proposal carries an execution window that opens when voting closes and stays open for a fixed execution-delay period — a delay the protocol describes in its own source as the "timelock against vote-bombing." A winning option cannot settle instantly on the vote closing; it has to wait out that period first, so a proposal that only won because someone bought votes at the last moment does not get to act before that pressure unwinds, 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 sec…a-caper) for the wider model.

How Caper approaches this Cap…e unwinds. Platform upgrades go further, using an explicit two-phasuse a second, separate timelock: the passing $CAPER…oses the new logic and starts thea delay, and a second call only…it once the delay has elapsed —– the same propose → timelock →…ed 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/governa…nance/proposals) for how the per-proposal window fits into a Caper vote,…a-caper) for the wider model.

Topic The enforced delay betwe…ernance) , Uniswap (https://docevelopers.uniswap.org/conceptsdocs/ecosystem/governance/overview) ); minut…/contracts/5.x/api/governance)

In production - Compound (ht…nDelay. - Uniswap (https://docevelopers.uniswap.org/conceptsdocs/ecosystem/governance/overview) — a Gov…rnance/tooling/voting/tally) .

Choosing the delay: the core t…e/tooling/treasury/safe) — a security council (/wiki/dao-governance/concepts/fundamentals/security-councils) — that can act inside a much s…art of a DAO's security model.

Choosing the delay: the core t…(/wiki/dao-governance/tooling/treasury/safe) — a security council — …art of a DAO's security model.

In production - Compound (ht…(/wiki/dao-governance/tooling/voting/tally) .

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://docs.uniswap.org/concepts/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/safe) — a security council — 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://docs.uniswap.org/concepts/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/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 an execution delay directly into its proposal machinery. Every proposal carries an execution window that opens when voting closes and stays open for a fixed execution-delay period — a delay the protocol describes in its own source as the "timelock against vote-bombing." A winning option cannot settle instantly on the vote closing; it has to wait out that period first, so a proposal that only won because someone bought votes at the last moment does not get to act before that pressure unwinds. Platform upgrades go further, using an explicit two-phase timelock: the passing $CAPER proposal first proposes the new logic and starts the 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. See Execution (/wiki/governance/execution) and Proposals (/wiki/governance/proposals) for how the window fits into a Caper vote, and What is a Caper (/wiki/foundations/what-is-a-caper) for the wider model.