What Happens If a DAO Proposal Passes but the Timelock Expires?

17 October 2026

The proposal dies without being executed. Once the timelock period expires, the queued transaction can no longer be executed through the normal governance flow. The DAO would need to submit an entirely new proposal if the community still wants that action taken.

How the timelock works

A DAO timelock is a delay inserted between a proposal passing and the actual execution of its code or transactions. This gives the community time to review the pending action, spot potential issues, and - in some designs - cancel a malicious proposal before it takes effect.

The typical sequence is:

1. A proposal passes the on-chain vote (quorum met, majority in favor).
2. The winning proposal is queued in the timelock contract.
3. The timer starts counting down from the specified delay period (commonly 24 hours to 7 days).
4. After the delay expires, anyone can trigger execution by calling the timelock's execute function.

If no one calls that execute function before the timelock period ends, the proposal's queued transaction expires.

What expiration actually means

When a timelock expires, the contract treats the queued transaction as canceled. The proposal's encoded function call and parameters are removed from the pending queue. No funds move. No contract upgrades happen. No parameter changes take effect.

The proposal still exists in the voting history - it shows as passed - but the intended action never occurred. The DAO's state remains exactly as it was before the proposal was submitted.

Why a timelock might expire

Several scenarios can lead to an expired timelock:

No one executes. The most common reason. After a vote passes, someone must manually call the execute function. If the community forgets, lacks a bot or script to do it automatically, or simply doesn't notice the window closing, the proposal expires.

Disagreement after passage. A proposal passes, but during the timelock period new information emerges that makes the action seem harmful or unnecessary. The community may collectively decide not to execute, letting the timelock expire as a soft rejection.

Technical issues. The execute transaction might fail due to gas price spikes, reorgs, or contract errors. After a few failed attempts, the window may close.

Intentional delay. Some DAOs set very long timelocks (30 days or more) for high-risk proposals. If the community changes its mind during that period, or if the situation that motivated the proposal resolves itself, the timelock may expire by design.

Consequences of Expiration

The direct consequence is that nothing changes. The DAO continues operating under its existing rules and contract state. But there are indirect effects:

• Wasted gas. The proposal submission and voting cost gas. If the proposal never executes, that gas was spent for nothing.
• Uncertainty. Token holders who voted for the proposal expected a change. Expiration creates confusion about whether the DAO actually supports the measure.
• Reputation damage. A DAO that regularly lets proposals expire looks disorganized or dysfunctional.
• Opportunity cost. The action the proposal intended - whether a treasury payment, a contract upgrade, or a parameter change - never happens. If it was time-sensitive, the opportunity may be lost permanently.

What Happens Next

If the community still wants the action, the only path is to start over:

1. Write and submit a new proposal with the exact same parameters.
2. Go through the full voting cycle again (any minimum holding period, the voting window, the quorum and majority requirements).
3. If the new proposal passes, queue it in the timelock and ensure someone executes it before the new expiration.

Some DAOs have attempted to bypass this by having the expired proposal's author call the timelock's cancel function (which removes the queued transaction) and then immediately queue a new identical proposal. But this shortcut only works if the DAO's governance contract explicitly supports re-queuing. Most standard implementations do not allow this - each proposal must go through a full vote.

Preventing Expiration

DAOs can reduce the risk of expiration by:

• Automating execution. Setting up a keeper bot or script that monitors the timelock and executes any queued proposal as soon as the delay expires.
• Shorter timelocks. Using minimal delays (24 hours) for low-risk proposals. Long timelocks increase the chance of expiration through neglect.
• Clear responsibilities. Assigning a specific address or multisig the duty of executing passed proposals.
• Notification systems. Using Discord bots or email alerts to tell the community when a proposal is queued and when execution is due.

When expiration is a feature

Not all expired timelocks are failures. Some DAOs deliberately use long timelocks as a way to allow the community to "veto" a passed proposal without a formal second vote. If the community simply refuses to execute, the proposal dies silently. This is an informal safeguard that puts the burden of action on supporters rather than forcing opponents to mount a cancellation vote.

In this view, timelock expiration acts as a soft rejection mechanism - a way to kill a proposal that technically passed but lost community support during the review period. The cost is time and gas, but the alternative (executing a proposal that no longer has majority support) could be worse.

Summary

If a DAO proposal passes but the timelock expires, the intended action does not happen. The proposal is dead. To proceed, the DAO must submit a new proposal and run the full voting process again. Whether this outcome is a bug or a feature depends on the DAO's design and the circumstances around the specific proposal.

Back to daos