Governance Quorum vs Majority: Count the Votes

Governance quorum is the minimum qualifying voting weight required by a proposal's rules. Majority is a separate approval test, often comparing For votes with Against votes. A proposal can win that comparison and still fail quorum. Reproduce both calculations using the governor's counted vote categories, supply denominator and snapshot; current token holdings or exchange balances do not automatically establish voting power.

A dashboard displaying “79.41% support” can describe a defeated proposal accurately. The percentage answers one question about the ballots. It does not establish whether enough qualifying weight participated, whether voting has closed or whether an approved change has executed.

A winning tally that fails quorum

Consider an original hypothetical proposal with 10 million voting units in total supply at its snapshot. Exactly 600,000 units have been delegated at that snapshot. Its governor uses OpenZeppelin Contracts v5.4.0's unmodified simple counting module, historical token voting weights and a quorum fraction of 4%. The example assumes a block-number clock, no cancellation and no extensions that change deadlines or allow early success.

In this specific GovernorCountingSimple implementation, For plus Abstain must reach quorum, while For must strictly exceed Against. Against contributes to the comparison but does not help satisfy quorum. Equality meets the quorum condition; a tie fails the approval condition.

The quorum-fraction module calculates the required amount from historical total voting supply and the applicable fraction. Our stipulated requirement is therefore 10,000,000 × 4 / 100 = 400,000 units. The 600,000 delegated units are not the denominator for that calculation.

Directional support is 270,000 / (270,000 + 70,000) = 79.41%. The approval comparison succeeds because 270,000 exceeds 70,000.

Quorum fails because 270,000 + 100,000 = 370,000, leaving a 30,000-unit shortfall. Even though all cast votes equal 4.4% of total supply, only 3.7% qualifies under this rule. Counting every ballot as participation would produce the wrong result.

Dividing For by all cast weight gives another valid descriptive statistic: 270,000 / 440,000 = 61.36%. It needs the label “share of all cast weight.” Neither percentage replaces the two contract tests.

An especially misleading shortcut would calculate 4% of the delegated 600,000, producing a requirement of only 24,000. That silently changes the denominator and would incorrectly make this proposal appear comfortably above quorum. In the stipulated system, undelegated supply still matters to the requirement.

Abstaining and not voting are different actions

Of the 600,000 delegated units, 160,000 have not cast a ballot in the initial example. Suppose one delegate with 30,000 unused snapshot units now votes. These two alternative choices produce different outcomes after voting closes:

The Abstain variant reaches quorum exactly and retains the For lead. The Against variant still has a For lead but remains below quorum. Both variants contain 470,000 cast units. The difference comes entirely from the counted category, not turnout size.

Under the first variant, a delegate can help the proposal meet its participation requirement without expressing support. Not voting contributes no counted weight. That distinction should be visible before someone selects Abstain; calling it equivalent to staying out of the vote conceals its effect.

The same labels can mean something different elsewhere. The official Compound Governor Bravo repository implementation records abstentions but tests whether For exceeds Against and For reaches its quorum amount. Abstain does not satisfy that quorum check. Applying that rule to the fictional 400,000 requirement leaves even the additional-abstention variant short, because For remains 270,000. This compares implementations; it does not assert a current Compound deployment's parameters.

Reaching quorum also cannot rescue a tied vote. In a separate hypothetical proposal with the same supply and requirement, 200,000 For, 200,000 Against and 200,000 Abstain would provide 400,000 qualifying units under the OpenZeppelin simple rule. The tie still fails its strict approval comparison.

Fix voting authority at the proposal's snapshot

Now examine where the initial 270,000 For units came from. Before the snapshot, holder A owns 100,000 units and holder B owns 170,000. Both delegate to address X. X holds no tokens itself. The remaining 330,000 delegated units belong to other voting addresses; 170,000 of those units supply the initial Against and Abstain ballots.

OpenZeppelin's v5.4.0 Votes source requires voting units to be delegated, including self-delegation for a holder voting directly. Delegation assigns voting authority; it does not itself transfer the underlying tokens. Its historical checkpoints also retain undelegated units in total voting supply. Thus balance, delegated authority and supply are three different readings.

For this hypothetical proposal, set the snapshot to the end of block 10,000 and the deadline to block 10,500. X's checkpointed weight is 270,000 at the snapshot. Address Y initially holds no tokens and has no voting weight.

After the transfer, X's current delegated weight is only 100,000 and Y's is 170,000. Reading those current values would reconstruct the earlier proposal incorrectly. The GovernorVotes module reads historical token votes, and the base Governor's ballot path supplies the proposal snapshot to that lookup.

Y cannot add the transferred 170,000 units to this proposal: Y had zero snapshot weight. A and B do not retain a second set of direct ballots merely because they supplied X's authority. Reconstruct the delegation map at the snapshot instead of adding holder balances to delegate totals.

Check the clock before interpreting the snapshot number. OpenZeppelin's current governance guide documents block-number and timestamp clock configurations. A value from one is not a date or duration in the other's units. The guide also distinguishes the proposal threshold, which restricts proposal creation, from the voting requirements that decide an existing proposal.

Holdings, access and independent people

An exchange balance alone does not identify an on-chain address with proposal-specific voting authority. It does not establish whether the venue supports customer voting or whether any needed delegation existed at the snapshot. Establish the supported voting route before treating the displayed amount as a usable ballot.

For a self-custodied holding, verify the recognized token or wrapper, its voting-unit rule and the historical delegate. For a custodied holding, obtain evidence of how customers' instructions become recorded votes. An assumed right to withdraw later does not document historical voting authority.

The token-holder concentration guide explains why address balances do not identify independent owners. Governance adds a further mapping: multiple holders may appoint one delegate, while several voting addresses may share control. A tally can reproduce the contract outcome without establishing broad participation by independent people.

Likewise, a governor's weighted-vote quorum should not be interpreted as a multisig signer ratio. The multisig threshold and independence guide examines which custody roots can authorize a signing path. Here the question is which historical voting units can satisfy a proposal's conditions.

Checking the balance recognized by a mechanism is also useful when comparing Ethereum effective and total validator balances. Record the relevant weighting rule before assigning significance to an account balance; the number displayed alone is insufficient.

Rebuild the result before calling it passed

Use a read-only review record for an actual proposal. Begin with the chain, governor address, proposal identifier and observation block. Save the deployed implementation and relevant configuration, rather than assuming the project's name fixes its rules.

For governors exposing OpenZeppelin's documented query interface, inspect CLOCK_MODE, COUNTING_MODE, proposalSnapshot, proposalDeadline, quorum(snapshot) and proposalVotes. Match those returned values to the implementation's comparisons. A familiar ballot label does not establish that an unmodified counting module is deployed.

First reproduce the raw totals in the contract's smallest voting units. Apply decimal conversion consistently and avoid rounding a displayed percentage before deciding an integer threshold. Then run the quorum and approval tests independently. If a front end disagrees, check whether it uses the same observation block, counts abstentions differently or displays a forecast while voting is still active.

For the fictional base governor, block 10,500 is still within its voting window; at 10,501 the initial tally is Defeated and the additional-abstention variant is Succeeded. That conclusion assumes no further ballots or configuration exceptions in the fixture. A lead observed earlier was provisional.

Succeeded is another checkpoint, not evidence that a treasury transfer or parameter update occurred. Follow any required queue, delay and execution receipt using the governance timelock and execution guide. Record the resulting state change before describing the approved action as implemented.

For the next proposal you inspect, write both tests with units: “Quorum: X qualifying units against a requirement of Q” and “Approval: F For units versus A Against units, using rule R.” Attach the snapshot and current state. Those statements make a support percentage useful without asking it to prove more than it measures.