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.
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.
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”.
quorum=bravo. Its state() function defeats a proposal when proposal.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.quorum=for,abstain. GovernorCountingSimple.COUNTING_MODE() returns the literal string "support=bravo&quorum=for,abstain", and _quorumReached tests quorum(proposalSnapshot(proposalId)) <= proposalVote.forVotes + proposalVote.abstainVotes. Abstaining materially advances a proposal toward passage; voting against does not.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.
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.
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.
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.
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:
quorum=for,abstain, is misinforming its own delegates about what their button does.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%.
That ladder falls, and the bar it describes does not: the share is a share of the Borda pool, not of the electorate, and on a full-permutation count no option can take more than 2 / option_count of that pool, reached only when every voter ranks it first. 1.5 / option_count is therefore three-quarters of unanimity at every ballot width – the derivation is on ranked and alternative ballot methods. 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: a 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 earned by taking part, not bought: each ballot cast mints the voter soulbound vote tokens, nothing else mints them, and they can never be moved to another account, because the vote token's depositor role admits only the caper's own state component. A wallet that has never cast a ballot holds no vote tokens, but its first ballot still carries weight, because the vote tokens that ballot earns count straight away.
The stake term is not custodied. Casting a ballot is a plain wallet transaction and the tokens stay liquid throughout – but the weight is clamped rather than merely observed: the crystallization crank folds every ballot at min(balance at cast, balance now), so weight that arrives for one vote and leaves before the count is counted at whatever is left. That is the escrow-free replacement for a lock, and it is the reason a borrowed position cannot vote and then be repaid inside the window.
The proposal threshold is deliberately flat rather than proportional: a proposer must hold at least one governance token of the caper and pay the configured proposal fee – 1% of the largest option's XRD value, at least 500 XRD, on the deployment live since 6 October 2026 – which goes to that caper's own treasury rather than being burned. Voting costs a separate ballot fee, 100 XRD on the same deployment, on the same terms. Neither is a constant in the Scrypto sense – both are state fields on the logic component, readable straight off the gateway – but the deployed logic exposes no setter for either: its twenty-one methods include nothing that rewrites a fee.
Moving one means deploying a new logic package and swapping the registry's current_main, which is itself the UPGRADE proposal kind and subject to the same two-phase resolution. Until the redeploy of 11 September 2026 the 500 was also pinned to the per-proposal settlement-gas allowance the treasury reimbursed cranks from; that subsidy was removed, so the fee now prices proposing and nothing else. 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.
IGovernor.sol – the COUNTING_MODE specification defining quorum=bravo and quorum=for,abstain.GovernorCountingSimple.sol – _quorumReached over forVotes + abstainVotes.GovernorVotesQuorumFraction.sol – quorum as getPastTotalSupply(timepoint) × numerator / denominator.quorum(uint256 timepoint) and proposalThreshold().GovernorBravoDelegate.sol – the 400,000 COMP constant and the forVotes < quorumVotes defeat condition.NounsDAODynamicQuorum.sol – the dynamic quorum formula and its stated rationale.