Why a DAO vote failed even though quorum was met

25 September 2026

A DAO vote can fail despite meeting quorum because quorum only sets a minimum participation threshold - it does not guarantee that a proposal will pass. A vote fails when the proposal does not receive enough "for" votes to satisfy the approval threshold, or when it is vetoed, blocked by a timelock, or invalidated by a governance attack. Quorum is a necessary condition for a valid vote, but it is rarely the only condition.

Approval thresholds vs. quorum

The most common reason a vote fails after quorum is met is that the proposal does not reach the required approval threshold. These are two separate parameters in most on-chain governance systems:

• Quorum defines the minimum total voting power that must participate (cast a vote, not just abstain).
• Approval threshold defines the minimum percentage of participating votes that must be "for" the proposal.

A proposal can easily meet quorum but still fail. For example, if quorum is 10% of total supply and approval threshold is 60% of votes cast, a vote where 15% of supply participates but only 55% vote "for" will fail. The quorum is met, but the approval threshold is not.

In some systems, the approval threshold is calculated against total supply rather than participating votes. This makes failure even more likely: a proposal might meet a 10% quorum but fail because it needs 50% of total supply to vote "for", and only 15% participated at all.

Veto mechanisms and guardian vetoes

Some DAOs include a veto power held by a multisig, a guardian address, or a security council. If quorum is met and the vote passes, the veto can still kill the proposal during a cancellation window. This is common in DAOs that use the OpenZeppelin Governor contract with a guardian role.

The veto is typically time-limited. If the guardian does not act before the timelock executes, the proposal stands. But if the guardian vetoes after quorum and approval are satisfied, the proposal fails regardless.

Timelock Cancellation

Even after a vote passes, most DAO proposals are queued in a timelock contract before execution. The timelock introduces a delay - often 24 hours to several days - during which the proposal can be cancelled.

Cancellation can be triggered by:

• The proposer, if the contract allows it.
• A DAO vote that overturns the original result.
• A guardian or multisig with cancellation authority.
• A detected exploit or malicious code in the proposal's calldata.

If the proposal is cancelled during the timelock period, it never executes. To an observer who only checks the vote result, it looks like the vote failed - but it actually passed and was then cancelled.

Proposal Expiry

Many on-chain governance systems set a maximum time between proposal creation and execution. If the proposer does not queue the proposal for timelock within that window, or if the timelock period expires before execution, the proposal dies.

This can happen when:

• The proposer fails to call the queue function after the vote ends.
• Network congestion delays the queue transaction past the deadline.
• The governance contract's parameters change during the voting period, making the proposal ineligible.

Quorum was met, the vote passed, but the proposal expired anyway.

Governance attacks that look like failed votes

Some attacks cause a vote to appear to fail even though quorum and approval were technically satisfied. These include:

• Flash loan manipulation: An attacker borrows a large amount of governance tokens, votes, then returns them. If the vote passes during the manipulation but the tokens are removed before execution, the system may treat the vote as invalid or the proposal may fail a post-vote sanity check.

• Sybil or delegation attacks: An attacker accumulates delegated voting power through many small wallets. If the delegation is later challenged or reversed, the votes become invalid retroactively.

• Reentrancy or front-running: An attacker submits a proposal, votes with borrowed power, and then drains the treasury through a separate transaction before the timelock executes. The vote technically passed, but the proposal fails because the funds are gone.

These attacks are rare but documented in practice. They are one reason some DAOs require a delay between vote end and execution, and why some use veto mechanisms even after quorum and approval are met.

How to Diagnose Why a Vote Failed

If you see a proposal that met quorum but did not execute, follow these steps:

1. Check the approval threshold. Compare the "for" votes against the required percentage. Most block explorers for DAO contracts show the threshold and the actual result.

2. Look for a veto or cancellation event. Search the timelock contract for "Cancelled" events. If one exists, the proposal was killed after passing.

3. Check the proposal expiry. See if the proposer called the queue function. If not, the proposal may have expired.

4. Review the governance parameters at the time of the vote. Some DAOs change quorum or threshold between proposal creation and vote end. If the parameters changed, the vote might have failed against the new rules.

5. Search for governance forum discussions. Most DAOs require off-chain discussion before on-chain voting. A proposal that meets quorum but fails often has a forum thread explaining why.

Summary

Quorum is a floor, not a guarantee. A DAO vote fails after quorum is met because approval thresholds are not reached, vetoes are exercised, proposals expire, timelocks cancel execution, or attacks invalidate the result. Understanding which mechanism caused the failure requires checking the specific governance contract's parameters and event logs.

Back to daos