A quorum is the minimum amount of voting weight that must participate before a DAO proposal's result is allowed to count. A proposal threshold is the minimum weight an address must control before it may submit a proposal at all. Together they are the two numeric gates on every token-governed DAO, and in most deployments they are the only two parameters standing between a well-funded outsider and the treasury.
They are usually discussed as a single dial – a percentage, tuned once at launch and rarely revisited. That framing hides the three decisions actually being made: what goes in the denominator, which vote types count toward the numerator, and whether the bar is fixed or moves. The major governance frameworks answer all three differently, in ways their own source code states plainly and their own governance forums almost never discuss.
The denominator is the design
Every quorum is a ratio, and the interesting choice is what sits underneath it. Four denominators are in live production, and they price very different things.
An absolute token constant. Compound's Governor Bravo hard-codes it: uint public constant quorumVotes = 400000e18; // 400,000 = 4% of Comp. The comment records what the number meant when it was written; the number itself does not track it. Because the value is a constant in the implementation contract rather than a storage variable, the DAO cannot change its own quorum by voting – it has to deploy and adopt a new implementation. The bar is denominated in tokens while everything it protects is denominated in dollars, so the real cost of clearing it moves every time the token price does, without anyone proposing anything.
A fraction of past total supply. OpenZeppelin's GovernorVotesQuorumFraction computes quorum(timepoint) = getPastTotalSupply(timepoint) × numerator / denominator, with the denominator defaulting to 100 so the numerator reads as a percent. This re-prices automatically as supply changes, and the numerator is adjustable through updateQuorumNumerator under an onlyGovernance modifier – the DAO can raise its own bar without a redeployment. The catch is in the word total: tokens sitting on exchanges, locked in bridges, held by the DAO's own treasury and never claimed from an airdrop all sit in the denominator and never vote. A nominal 4% quorum is therefore a much steeper bar on the addresses that actually turn up than the headline percentage suggests.
Delegated votable tokens, clamped. Arbitrum's constitution narrows the denominator twice over – not total supply but Delegated Votable Tokens – and then puts a floor and a ceiling on the result. For a Constitutional AIP it specifies that if the proportional value “is less than 150,000,000, then 150,000,000 applies”, the proportional value applies between 150,000,000 and 450,000,000, and above that the 450,000,000 ceiling applies; non-Constitutional AIPs run the same three-branch clamp between 100,000,000 and 300,000,000. The clamp is the design: a purely proportional quorum inherits every swing in the supply figure beneath it, and the floor and ceiling bound how far the bar can drift from what the DAO originally agreed to.
A share of weight actually cast. The fourth option removes the participation floor entirely and asks only about agreement among those who voted. It cannot be bought, because there is no absolute number to hit – but it also guarantees nothing about turnout. Caper takes this route; see below.
What an “against” vote does to quorum
This is the part that surprises people, including delegates who vote weekly. Whether opposition counts toward the participation floor is a separate switch from the floor itself, and the frameworks disagree.
OpenZeppelin's IGovernor interface makes the two options explicit in its own specification of the COUNTING_MODE string: “quorum=bravo means that only For votes are counted towards quorum” and “quorum=for,abstain means that both For and Abstain votes are counted towards quorum”.
- Compound Governor Bravo is
quorum=bravo. Itsstate()function defeats a proposal whenproposal.forVotes < quorumVotes– against-votes and abstentions are simply absent from the test. Voting against does nothing to help a proposal reach quorum, and nothing to stop it either. - OpenZeppelin's default counting module is
quorum=for,abstain.GovernorCountingSimple.COUNTING_MODE()returns the literal string"support=bravo&quorum=for,abstain", and_quorumReachedtestsquorum(proposalSnapshot(proposalId)) <= proposalVote.forVotes + proposalVote.abstainVotes. Abstaining materially advances a proposal toward passage; voting against does not. - Arbitrum follows the same shape at the constitutional level: its Threshold 2 counts tokens that “have cast votes either ‘in favor’ or ‘abstain’”.
The consequence is worth stating plainly, because it inverts how most voting guidance is written. Under the two most widely deployed configurations, a delegate who wants to block a proposal by denying it quorum must not vote at all. Voting against is strictly weaker than abstaining from the record entirely, and abstaining on-chain is not neutral – under quorum=for,abstain it is a contribution to the proposal clearing its floor. “Abstain” is presented in every governance UI as the neutral middle button. In the contract it is not.
This also explains a pattern that turnout data makes look like apathy and is partly strategy: on a contested proposal under a For-only or For-plus-Abstain quorum, organised opposition is rationally silent. The absence of votes against is not always the absence of objection.
Dynamic quorum: pricing contentiousness
Nouns DAO takes the opposite position and makes opposition the input. Its NounsDAODynamicQuorum library computes the bar per proposal rather than per DAO, and its own header comment states the rule: “Quorum votes required for a specific proposal to succeed … Differs from GovernerBravo which uses fixed amount”, and “The more against-votes there are for a proposal, the higher the required quorum is.”
The arithmetic is a clamped linear function. Against-votes are expressed in basis points of total supply at proposal creation, multiplied by a quorumCoefficient (a fixed-point integer with six decimals), added to a minQuorumVotesBPS floor, and the result is capped at maxQuorumVotesBPS:
againstVotesBPS = 10000 × againstVotes / totalSupply
adjustedQuorumBPS = minQuorumVotesBPS + (quorumCoefficient × againstVotesBPS) / 1e6
quorumBPS = min(maxQuorumVotesBPS, adjustedQuorumBPS)The parameters are checkpointed by block, so a proposal is judged against the configuration in force when it was created rather than whatever the DAO has since adopted. The design target is agility without defencelessness: an uncontested proposal clears a low floor and passes quickly, while a proposal that draws real opposition has to assemble a proportionally larger coalition to carry. It is the only widely-deployed quorum that treats a vote against as information about how much agreement the proposal ought to need, rather than as a number to be out-counted.
The cost is a new attack surface. Because against-votes raise the bar, a minority holding enough weight can push the quorum requirement to its ceiling and defeat a proposal that has clear majority support but modest turnout – a veto obtained by opposing loudly rather than by winning. Nouns bounds this with maxQuorumVotesBPS; the bound is the whole defence, and choosing it is choosing how much minority veto power the DAO is willing to sell.
Proposal thresholds: the gate on the way in
Quorum governs the exit from deliberation. The proposal threshold governs the entrance, and it is the parameter that decides who is a participant and who is an audience. OpenZeppelin defines proposalThreshold() as “the number of votes required in order for a voter to become a proposer”.
The two gates trade against each other in a way that is easy to miss. A high proposal threshold reduces spam and keeps the ballot short, which raises the chance that any given proposal clears quorum – at the price that the set of people who can start a conversation is the set of people who already hold a large position. A low threshold widens participation and lengthens the ballot, which spreads the same finite attention across more proposals and makes quorum failures more common. Neither setting is neutral about who governs; they simply move the exclusion to different ends of the process.
Compound's Governor Bravo treats the two gates asymmetrically, and the asymmetry is instructive. Quorum is a constant the DAO cannot change by voting, while the proposal threshold is a storage variable set at initialisation and bounded by two further constants – MIN_PROPOSAL_THRESHOLD = 1000e18 and MAX_PROPOSAL_THRESHOLD = 100000e18, per the Bravo source. The entrance is adjustable within a hard-coded corridor; the exit is frozen. Whichever way round a DAO wants that, it is a decision worth making on purpose rather than inheriting from a template.
A threshold denominated in tokens has the same drift problem as an absolute quorum: the dollar cost of the right to propose moves with the token price, with no governance decision behind the move, and a corridor written in tokens does not bound it in any currency anyone spends. Some DAOs route around this with delegation minimums, sponsorship (a small holder drafts, a large delegate submits), or an off-chain temperature check that filters before the on-chain gate is reached at all.
Two failure modes, one dial
Both ends of the range fail, and they fail in ways that look nothing alike.
Set too high, the DAO stalls. Proposals expire unresolved, the treasury cannot be deployed, and the practical effect is a status-quo bias that nobody voted for. Because a failed-quorum proposal produces no outcome at all – not a rejection, just an absence – a DAO can go months without deciding anything while its forum remains busy. The reasonable response is usually to fix turnout rather than lower the bar, but lowering the bar is the change that requires only one vote.
Set too low, the electorate has a price. This is the BonkDAO case of July 2026, and it is the clearest recent demonstration of what a supply-denominated quorum actually publishes. The quorum was 1% of BONK supply – roughly 880 billion BONK – set when the treasury held very little. The treasury subsequently grew into eight figures; the quorum was never re-priced. By July 2026 the whole electorate cost about $4.4m to assemble and the treasury behind it was worth roughly $20m, so the attack was profitable at a ratio of about 22 cents spent per dollar taken. An attacker paid it, and BIP #76 passed and executed on 6 July 2026. No contract was broken and no rule was bent – the vote was valid. The full sequence is documented on DAO security and governance attacks.
The general statement is uncomfortable: a quorum denominated in tokens, guarding a treasury denominated in dollars, is a published purchase price for control, and the exchange rate between the two moves continuously without any vote. Every DAO with a fixed supply-percentage quorum is quoting that price right now. Most have never checked what it currently reads.
Re-pricing a parameter nobody revisits
Quorum is the most consequential parameter in a DAO's constitution and among the least often amended, because amending it requires clearing the very bar under review. Raising a quorum is hard precisely when turnout is low, which is exactly when it most needs raising; lowering one is easy precisely when the DAO is frustrated, which is exactly when the decision is worst-informed.
A few practices reduce the drift without adding mechanism:
- Denominate the review, not the parameter. The number stays in tokens, because that is what the contract can read – but the DAO periodically checks what that number costs to acquire at current market prices, against the current treasury value. The ratio, not the percentage, is the health metric.
- Exclude what cannot vote. Treasury holdings, unclaimed distributions and bridge-locked supply inflate a total-supply denominator and quietly raise the effective bar on real voters. Arbitrum's “Delegated Votable Tokens” is the strict version of this correction. The arithmetic underneath – which tokens are eligible to count at all, and why a stock total-supply denominator measures a pool the votes cannot come from – is set out in voting power activation and delegation thresholds.
- Pair the floor with a delay. A timelock does not stop a bought quorum, but it converts an instant drain into a window in which the theft is visible and members can exit. Several of the attacks that made a low quorum catastrophic were catastrophic because there was no delay behind it.
- Read the counting mode before writing the guidance. A DAO publishing voter guidance that calls “abstain” neutral, while running
quorum=for,abstain, is misinforming its own delegates about what their button does.
How Caper approaches this
A caper has no supply-denominated quorum at all. When a proposal settles, the contract computes the leading option's share of the weight actually cast – top_weight / total_weight – and passes the proposal when that share reaches 1.5 / option_count and the leading option is not a “no” option. At two options that is 75% of cast weight, at three 50%, at four 37.5%, at five 30%. There is no absolute participation number anywhere in the settlement path, so there is no figure an attacker can price and buy. A proposal that nobody votes on has zero total weight, so its share is zero and it fails.
That removes the BonkDAO failure mode and accepts a different one honestly: Caper has no participation floor. A proposal decided by a handful of members passes if they agree strongly enough. The defence is moved off the quorum and onto the weight itself. Voting weight is (t·v)/(V·T) – token balance t times the voter's vote tokens v, over vote-token supply V times circulating supply T – and vote tokens are earned one per ballot cast, with each ballot snapshotting v before minting the token it earns. A wallet voting for the first time contributes exactly zero weight to the proposal it is voting on. The tally also credits min(held_at_vote, live_balance), and anyone may permissionlessly re-clamp that figure downward during a challenge window after voting closes, so weight that arrives for one vote and leaves afterwards does not keep its credit.
The proposal threshold is deliberately flat rather than proportional: a proposer must hold at least one governance token of the caper and pay a 500 XRD fee, which goes to that caper's own treasury rather than being burned. Voting costs 100 XRD per ballot on the same terms. The gate is a fixed cost, not a percentage of supply, so it does not concentrate the right to propose in the largest holders as the token appreciates – though, like every fixed fee, its real weight moves with the XRD price. Mechanics in Proposals and Voting.
References
- OpenZeppelin Contracts,
IGovernor.sol– theCOUNTING_MODEspecification definingquorum=bravoandquorum=for,abstain. - OpenZeppelin Contracts,
GovernorCountingSimple.sol–_quorumReachedoverforVotes + abstainVotes. - OpenZeppelin Contracts,
GovernorVotesQuorumFraction.sol– quorum asgetPastTotalSupply(timepoint) × numerator / denominator. - OpenZeppelin, Governance API reference –
quorum(uint256 timepoint)andproposalThreshold(). - Compound,
GovernorBravoDelegate.sol– the 400,000 COMP constant and theforVotes < quorumVotesdefeat condition. - Nouns DAO,
NounsDAODynamicQuorum.sol– the dynamic quorum formula and its stated rationale. - Arbitrum Foundation, The Constitution of the Arbitrum DAO – Threshold 1 and Threshold 2, Delegated Votable Tokens, and the clamped quorum formulas.