Voting Quorum

Quorums are defined as either absolute (a fixed number or percentage of total voting power) or relative (a percentage of votes cast).

• Absolute Quorum: Requires a minimum like 4% of all governance tokens to vote 'Yes', regardless of turnout. Common in systems like Compound.
• Relative Quorum: Requires a simple majority (e.g., >50%) of the votes that were cast. This is simpler but can lead to low participation validating decisions.

Setting the quorum threshold is a critical security and participation parameter.

• High Thresholds (e.g., 20%+): Increase legitimacy and make governance attacks more expensive, but can lead to governance paralysis where no proposals pass.
• Low Thresholds (e.g., 1-5%): Make governance more agile but risk allowing a small, coordinated group to pass proposals. Many DAOs adjust this dynamically based on voter apathy.

Some protocols implement a quorum that declines over the voting period, a mechanism known as quorum damping or fallback quorum.

• Mechanism: Starts with a high quorum requirement (e.g., 20%). If not met after a set time, the requirement gradually lowers.
• Purpose: Balances the need for broad consensus with the practical need to execute decisions, preventing stalemates. Used by protocols like Uniswap.

A quorum is distinct from, but works in conjunction with, the approval threshold.

• Quorum: Minimum participation required for the vote to be valid.
• Approval Threshold: The percentage of cast votes required to pass (e.g., >50% for simple majority, >66% for supermajority). A proposal must first meet the quorum, then meet the approval threshold to execute. Failure in either condition causes rejection.

What happens when a quorum is not met determines the proposal's fate.

• Standard Rejection: The proposal fails and is closed. Any delegated voting power is unlocked.
• Grace Period Extension: Some systems allow a grace period for more voters to participate before final failure.
• Fallback Execution: Rare, but some setups allow execution with a lower quorum after a long delay. This highlights quorum's role as a safety delay or veto mechanism.

The most common model, where a proposal passes if it receives more "yes" votes than "no" votes, provided a minimum percentage of the total voting power has participated. This protects against low-turnout attacks.

Examples:

• Compound Governance: Proposals require a minimum quorum of 4% of COMP tokens to pass.
• Uniswap Governance: Historically used a 4% quorum, now employs a dynamic quorum mechanism.

A quorum threshold that adjusts automatically based on voter turnout or proposal support, designed to prevent stagnation from static, high quorums.

Mechanism: The required quorum decreases as the level of support (e.g., percentage of "for" votes) increases.

Example:

• Uniswap: Implements a quorum floor (e.g., 2%) that scales down from a ceiling (e.g., 20%) as the "for" vote margin increases, making it easier for highly popular proposals to pass.

Quorums are typically calculated based on token voting power, not the number of individual voters. This aligns decision-making with economic stake in the protocol.

Key Distinction:

• Token-Weighted: Quorum = % of total token supply voted. Used by Aave, Compound, MakerDAO.
• One-Person-One-Vote: Quorum = % of eligible voters. Rare in on-chain governance due to Sybil attack vulnerability, but seen in some off-chain signaling.

Protocols often tier quorum requirements based on a proposal's significance and impact, applying higher thresholds for more critical changes.

Common Tiers:

• Standard Protocol Upgrades: Lower quorum (e.g., 2-5%).
• Treasury or Fund Allocation: Moderate quorum (e.g., 5-10%).
• Constitutional Changes (e.g., modifying core contracts): Highest quorum (e.g., 10-20%+).

Example: MakerDAO's Governance Security Module requires a higher threshold for executive spells that modify core system parameters.

If a proposal fails to meet the quorum by the voting deadline, it is defeated and does not execute, regardless of the vote margin. This resets the governance process.

Consequences:

• No state changes are made.
• Proposal gas deposits may be forfeited (protocol-dependent).
• The topic must be re-submitted as a new proposal, often after community re-evaluation.

A critical distinction in governance design. These are separate, consecutive requirements for a proposal to pass.

Definitions:

• Quorum: Minimum participation required for the vote to be valid.
• Approval Threshold: The majority margin (e.g., >50%, 66%) required among the votes cast after quorum is met.

Process: 1) Check if quorum is met. 2) If yes, check if "for" votes exceed the approval threshold. Both must be satisfied for execution.

Quorum failure occurs when a proposal fails to meet the minimum participation threshold, rendering it invalid regardless of the vote outcome. This leads to governance paralysis, where critical upgrades or treasury actions cannot be executed. Risks include:

• Voter apathy diluting participation.
• Strategic abstention by large stakeholders to block proposals.
• Network congestion preventing timely voting during critical periods.

An excessively low quorum threshold amplifies the risk of whale dominance or low-cost attacks. A malicious actor with a significant token stake can pass self-serving proposals with minimal opposition if general participation is low. This undermines the Sybil-resistance of token-weighted voting and can lead to treasury drains or harmful protocol changes being approved by a tiny, unrepresentative fraction of the community.

Quorum sniping is an attack where a malicious actor monitors a proposal nearing its quorum threshold near the voting deadline. They then cast a large, decisive vote at the last moment to swing the outcome, leaving no time for a community response. This exploits the time-bound nature of governance and can be combined with flash loan attacks to temporarily acquire voting power, passing proposals that would otherwise fail.

Static quorums (a fixed percentage) can become insecure over time as token distribution changes or participation wanes. Dynamic quorums (e.g., based on past participation) aim to adapt but introduce new risks:

• Quorum inflation can make passing any proposal nearly impossible.
• Manipulation of the baseline by whales during low-activity periods.
• Increased complexity and reduced predictability for voters.

High transaction gas costs on the underlying blockchain create a significant barrier to participation, effectively disenfranchising smaller token holders. This economic friction can artificially suppress quorum attainment and centralize voting power among entities that can absorb gas fees. Solutions like gasless voting via meta-transactions or vote delegation introduce their own security trade-offs, such as reliance on centralized relayers or delegate apathy.

Several mechanisms exist to mitigate quorum-related risks:

• Quorum floors and caps to bound the dynamic range.
• Vote escalation mechanisms for critical proposals.
• Bonded voting or conviction voting to signal commitment.
• Separation of concerns via a security council for time-sensitive emergency actions, distinct from general governance.

The specific percentage or absolute number of voting power that must participate for a vote to be valid. This is the core parameter of a quorum.

• Absolute Quorum: A fixed number (e.g., 1,000,000 tokens must vote).
• Relative Quorum: A percentage of the total eligible supply (e.g., 4% of circulating tokens).

Setting this threshold is a critical governance decision that balances security against voter apathy.

The minimum level of support a proposal must receive from participating voters to pass, distinct from the quorum. Often expressed as a supermajority.

• Simple Majority: >50% of votes cast.
• Supermajority: A higher bar, such as 66.7% or 75%, required for significant protocol changes.
• Relative vs. Absolute: Can be a percentage of votes for or require a minimum absolute number of yes votes.

A proposal can meet quorum but fail if it doesn't reach the approval threshold.

A system where voting power is weighted by the amount and duration tokens are locked, often used to align voters with long-term protocol health.

• Mechanism: Tokens are locked in a veToken contract (e.g., veCRV, vlAURA). Longer locks grant more voting power per token.
• Purpose: Discourages short-term speculation and incentivizes committed, informed governance.
• Impact on Quorum: Concentrates voting power among long-term holders, affecting quorum dynamics and proposal outcomes.

A security mechanism that imposes a mandatory waiting period between a vote passing and the execution of its on-chain code. This is a critical defense against malicious proposals.

• Purpose: Provides a final "cooling-off" period for the community to react if a harmful proposal slips through.
• Process: Once a vote passes, the proposal action is queued in a Timelock contract and can only be executed after the delay expires.
• Governance Role: The length of the delay is often itself a governance parameter.

The minimum amount of governance tokens or delegated support required to submit a proposal for a vote. This gatekeeps the proposal process.

• Purpose: Prevents governance spam and ensures proposals have a baseline of community support before consuming attention and resources.
• Mechanism: Can be a flat token amount (e.g., 100,000 UNI) or require delegation from a certain number of addresses.
• Relation to Quorum: A high proposal threshold can indirectly affect quorum by limiting proposals to those with established support.