Encyclopedia DeFi · Entry 175
Governance timelocks: a delay, not an automatic veto
In this article
At a glance
Key facts
| Fact | Detail | Source |
|---|---|---|
| Sequence | With a timelock, the documented proposal flow includes queueing before execution. | [1] |
| Delay | Execution must wait for the configured delay after scheduling. | [1] |
| Authority | The timelock needs the assets or permissions required to execute the governed action. | [1] |
Start the waiting period at the right event
If a hypothetical proposal finishes voting on Monday but is queued on Tuesday with a two-day delay, the execution waiting period starts with queueing under that configuration. It does not necessarily start when the vote was first proposed.
The example is illustrative. Actual contracts determine the clock, minimum delay and whether the proposal has been scheduled successfully.
Time passing does not send a transaction
After the required delay, an eligible actor still needs to execute the operation. The target call can also depend on permissions, balances and other state.
A proposal can therefore be successful at voting yet remain unexecuted. Follow the proposal’s execution status and resulting transaction rather than treating a favorable vote as proof the requested change already happened.
Trace every route to the privileged action
OpenZeppelin’s setup places control in the timelock so the Governor’s decisions follow the delayed execution path. Separate administrators or other privileged roles require their own examination.
Ask what the timelock controls, who can propose or execute operations and how its permissions are configured. A delay helps observers react only when they can identify the action and have meaningful response options; it is not a substitute for reviewing the proposal itself.
Direct answers
Questions people ask
Does every DAO vote have a mandatory timelock?
No. OpenZeppelin’s Governor tutorial explicitly supports configurations with or without one. The deployed governance modules and permissions determine whether a delay is enforced.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
A governance timelock delays eligible actions between scheduling and execution. In OpenZeppelin’s Governor example, a successful proposal is queued, waits the configured delay and can then be executed. The delay creates an observation period; it does not prove the proposal is safe, guarantee that users can exit or automatically constrain powers held outside the timelock.
Scope: DeFi · data through 2026-10-02. Verification: verified · 2026-10-02T18:19:48.887Z.
Link to this claimSequence: With a timelock, the documented proposal flow includes queueing before execution.
Scope: DeFi · data through 2026-10-02. Verification: verified · 2026-10-02T18:19:48.887Z.
Link to this claimDelay: Execution must wait for the configured delay after scheduling.
Scope: DeFi · data through 2026-10-02. Verification: verified · 2026-10-02T18:19:48.887Z.
Link to this claimRevision history
- — First publication after primary-source research and independent automated verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- How to set up on-chain governanceOpenZeppelin
Delegation, historical checkpoints, quorum and execution delays.
Locator: Voting token; Governor; Timelock · Version / scope: OpenZeppelin Contracts 5.x · Retrieved: 2026-10-02T17:03:45.975ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “Governance timelocks: a delay, not an automatic veto.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/governance-timelocks/