# Governance timelocks: a delay, not an automatic veto

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.

Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)

Canonical: https://degreesofsatoshi.com/encyclopedia/governance-timelocks/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:19:48.887Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Sequence:** With a timelock, the documented proposal flow includes queueing before execution. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance))
- **Delay:** Execution must wait for the configured delay after scheduling. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance))
- **Authority:** The timelock needs the assets or permissions required to execute the governed action. ([How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance))

## 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.

Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)

## 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.

Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)

## 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.

Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)

## Questions

### 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.

Evidence: [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance)

## Claims and scope

### governance-timelocks-quick-answer

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: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null}

### governance-timelocks-fact-sequence

Sequence: With a timelock, the documented proposal flow includes queueing before execution.

Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null}

### governance-timelocks-fact-delay

Delay: Execution must wait for the configured delay after scheduling.

Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null}

### governance-timelocks-fact-authority

Authority: The timelock needs the assets or permissions required to execute the governed action.

Scope: {"collection":"defi","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [How to set up on-chain governance](https://docs.openzeppelin.com/contracts/5.x/governance) — OpenZeppelin. Delegation, historical checkpoints, quorum and execution delays. Locator: Voting token; Governor; Timelock. Retrieved: 2026-10-02T17:03:45.975Z.

## Revision history

- 2026-10-02: First publication after primary-source research and independent automated verification.

## Cite this entry

Degrees 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/