Security
Governance timelocks and how to size them

A timelock is the community's exit window. It converts an irreversible action into a reviewable one, and it is the single cheapest security control in onchain governance.
What the delay actually buys
Time for holders to inspect the queued calldata, time for security researchers to object, and time to cancel if the payload is not what was approved.
A timelock also creates a public, timestamped commitment. Once an action is queued, everyone can see the exact function call, the target contract and the earliest moment it can run. That transparency is what turns a governance vote into an accountable process rather than a private handoff to a core team.
Exchanges, integrators and risk teams rely on that window too. If your protocol can change a fee, an oracle or a collateral factor with no notice, downstream products have to treat you as unpredictable infrastructure.
Choosing a duration
Parameter tweaks often sit at 24 to 48 hours. Upgrades and treasury movements commonly run 3 to 7 days. The right number scales with how much damage the action could cause.
A workable default is three tiers: a short tier for reversible parameter changes, a medium tier for treasury transfers and integrations, and a long tier for contract upgrades and anything touching custody. Publish the tiers before you need them so nobody argues about the clock during a live proposal.
Longer is not automatically safer. A delay nobody watches adds risk instead of removing it, because the protocol is slower to respond without gaining any real review. Pair every delay with a named reviewer and an alert when something is queued.
Cancellation and guardian roles
A timelock without a credible cancel path is just a waiting period. Decide in advance who can cancel a queued action, on what grounds, and how that decision gets disclosed.
Most mature setups give a guardian multisig cancel-only power. It can stop a malicious or malformed payload but cannot queue or execute anything on its own, which keeps the governance process the only route to change.
Emergency paths
Keep a separate, narrowly scoped emergency route with a higher signature requirement and a mandatory post-hoc disclosure, rather than shortening the standard timelock.
Scope the emergency path to a fixed list of actions such as pausing a market or freezing a bridge. If the emergency route can also move funds or upgrade logic, attackers will target it instead of the normal process.
How long should a timelock be
The delay should be long enough for a determined user to read the queued call, understand it and leave if they disagree. For protocols holding user deposits that usually means at least two days, and often longer for upgrades that touch custody of funds.
Longer is not automatically safer. An excessive delay pushes teams toward emergency paths for ordinary work, which is exactly how the safety mechanism gets hollowed out. Set separate delays for routine parameter changes and for upgrades.
Monitoring the queue
A timelock only protects users who know something is queued. Publish the queue somewhere readable, with the decoded call and the earliest execution time, and alert on every new entry rather than relying on people to check.
Cancellation should be a real capability, not a theoretical one. Decide in advance who can cancel a queued action, on what grounds, and how that decision is recorded, so a genuine mistake can be stopped without improvisation.
Keep the execution path connected: this guide pairs well with multisig wallet, dao voting and governance token, which cover the neighbouring steps between an approved vote and a settled onchain transaction.
Key concepts explained
New to this topic? These are the core terms you will meet again and again in governance work. Understanding them makes every proposal easier to read.
- Timelock
- A mandatory delay between a vote passing and its transaction becoming executable. It gives token holders time to review, exit or challenge before funds move.
- Queue
- The stage where an approved action waits out its timelock. Queued actions are public, which is what makes the delay a security feature.
- Grace period
- The window after the timelock matures during which execution is still allowed. Miss it and the action may need to be re-queued.
- Timelock bypass
- An emergency path that skips the delay. Powerful and dangerous - it should require a higher threshold and be reserved for exploits or outages.
Frequently asked questions
- What is a timelock in crypto governance?
- A timelock is a contract that holds an approved transaction for a fixed delay before it can be executed. The waiting period gives users time to review the change and exit if they disagree.
- Can a timelock be bypassed?
- Only through a separate emergency path that the protocol deliberately configured, such as a guardian pause. If ordinary proposals can skip the delay, the timelock is decorative.
- What happens when a timelock expires?
- Many implementations include a grace period after which a queued action becomes stale and can no longer be executed. The proposal must then be resubmitted and approved again.