Holding is not voting The pat…delegate-incentive-programs) .Two other fixes avoid a wrappe…xyz/blogs/11-merkle-voting) ).

How Caper approaches this Cap…, contracts/logic/src/lib.rs).Activation here is therefore n…til its holder casts a ballot.There is no founder allocation…r) for the surrounding model.

Holding is not voting The pat…delegate-incentive-programs) . Two other fixes avoid a wrapper token. Agora (/wiki/dao-governance/tooling/voting/agora) and the restaking protocol Karak announced in January 2025 that Karak's contracts would implement ERC20Votes themselves, so tokens restaked there keep their votes ( Agora (https://www.agora.xyz/blogs/5-restaking-governance) ). Since March 2026 Agora's governor can instead take voting power published as a Merkle root, computed from any source such as a staking position or a balance on another chain; voters prove their weight against the root, and anyone may challenge the snapshot before voting opens ( Agora (https://www.agora.xyz/blogs/11-merkle-voting) ).

Holding is not voting The pat…the beneficial owner's behalf. The same gap opens when tokens go to work elsewhere. A token deposited in a lending market, a liquidity pool or a restaking contract takes its votes to a contract that does not vote. Tally (/wiki/dao-governance/tooling/voting/tally) 's 2024 case for liquid staked governance tokens rested on this: it claimed Uniswap had 158% of its quorum sitting in DeFi and on exchanges, and proposed a staked token whose issuing contract keeps the voting power and hands undelegated power to active delegates ( Tally (https://newsletter.tally.xyz/p/introducing-the-tally-protocol) ). Arbitrum voted to fund the approach for ARB in September 2024; see delegate incentive programs (/wiki/dao-governance/concepts/analysis/delegate-incentive-programs) .

How Caper approaches this Cap…y one vote token to the voter –(VOTE_MINT), alongside a flat 100 XRD vote fee at the protocol's rate of 0.01 per XRD – butpaid into the caper's treasury, and it is not the only mint a member can reach. Buying or selling on the cap…i/markets/bonding-curve) mintsed vote tokens at that same rate,too, at 0.01 per XRD of gross value on each leg, in the same transaction as the tradeuntil the redeploy of 11 September 2026 removed the trade-side mint (contracts/logic/src/lib.rs).…s follow directly. First, the vote-token balance is read before the ballot's own mint, so a first ballot carries only theballot's snapshot counts its own mint in both the voter's vote-tokens its voter already held. That is rarely zero: casting requires holding at least one of the caper's tokens, and balance and the supply it divides by, so a first ballot always carries weight: with ballots the only source, a snapshot toakens bought on the curve minted vote tokens as they were bought. A first ballot counts for nothing only for a holder who came by their tokens without trading – by transfer, orefore the mint would score every member's first ballot at zero and no caper's first proposal could pass. Holding without voting, by contrast, activates nothing. A bag bought on the curve, swapped or transferred in, or accrued as the founder's cut accrued out of other people's buys carries no vote tokens until its holder casts a ballot. There is no founder allocati…s, so a founder who has never bought into their own capervoted is exactly the holder this ca…u activate by participating – trading orby voting – rather than by deleg…r) for the surrounding model.

How Caper approaches this Cap…hen the product of two factors read at vote time: the ballot records at vote time – the voter's token balance and…t caper's soulbound vote token, and weight is computed as those two multiplied and divided by the vote-token supply and the token's circulating supply – multiplied and divided by the vote-token supply and the token's circulating supply. It is not settled at vote time, though. The ballot stores those readings and no weight; the weight is computed afterwards, when the permissionless crystallize crank folds the ballot and credits the smaller of the balance recorded at the cast and the balance still held at the fold (fold_ballot_batch, contracts/logic/src/lib.rs). Activation here is therefore not a thing you do once and leave standing: selling down after casting shrinks the ballot you have already cast. Voting mints exactly one vot… trading – by transfer, or as athe founder's allocation at creationcut accrued out of other people's buys. There is no founder allocation at creation to hold – founder_token_balance starts at zero and fills one purchase at a time (contracts/core/src/caper_dao.rs) – and withdrawing that cut mints no vote tokens, so a founder who has never bought into their own caper is exactly the holder this case describes (see what a founder can and cannot take (/wiki/foundations/what-a-founder-can-take) ). Activation exists, and you a…r) for the surrounding model.

How Caper approaches this Cap…ly one vote token to the voter, and that min – a flat 100 XRD vote fee at the protocol's rate of 0.01 per XRD – but it is not the only way vote tokens are ever created. Two consequences follow directly. First, the vote-token balance is read before the ballot's own mint, and weight is zero when that balance is zero – so a member's first ballot is recorded and counts for nothing; it buysmint. Buying or selling on the caper's bonding curve (/wiki/markets/bonding-curve) mints vote tokens at that same rate, 0.01 per XRD of gross value on each leg, in the same transaction as the trade (contracts/logic/src/lib.rs). Two consequences follow directly. First, the vote-token balance is read before the ballot's own mint, so a first ballot carries only the vote tokens its voter already held. That is rarely zero: casting requires holding at least one of the caper's tokens, and tokens bought on the curve minted vote tokens as they were bought. A first ballot counts for nothing only for a holder who came by their token that gives their second one weights without trading – by transfer, or as a founder's allocation at creation. Activation exists, and you activate by participating – trading or voting – rather than by delegating. Se…r) for the surrounding model.

The same DAO can have two elec…chain vote that failed quorum. A space can also answer the problem at the venue instead of leaving it to holders. ether.fi (/wiki/daos/staking/ether-fi) 's etherfi-dao.eth space runs both accounting methods side by side over the same tokens, on Ethereum and Arbitrum: erc20-balance-of for tokens sitting in a wallet and erc20-votes for weight that has been delegated on-chain. Read on 13 August 2026, that choice was load-bearing. The largest voter on its most recent proposal held 1,862,678.93 ETHFI and its delegates() returned the zero address – it had never activated, not even to itself – so an erc20-votes read alone would have scored the DAO's single biggest participant at zero. The cost of the belt-and-braces configuration is the mirror image of the failure above: the space polls inert supply as if it were active, and any Governor it later executes through would not.

Failure modes - Inert supply …rmant delegate is a quorum tax; see delegate accountability and dormant delegates (/wiki/dao-governance/concepts/voting/delegate-accountability) for the mechanisms DAOs have deployed against it. - Threshold capture. When p…oting/token-weighted-voting) .

Topic Which tokens are eligibl…l Activation step Delegation —– including self-delegation —– under ERC-5805 / ERC20Votes …oncepts/analysis/voter-apathy)

Voting power activation is the…s an explicit on-chain action —– a delegation, usually to them…ation thresholds built on top —– the minimum voting power to s…or to be listed as a delegate —– are all measured against that…his is the half underneath it.

Holding is not voting The pat…eg when the receiver has none —– so tokens moving between two … signed one extra transaction —– and since that transaction co…the beneficial owner's behalf.

Activation is a deadline, not …eads it at a fixed past point —– the snapshot. Delegating afte…kens between wallets mid-vote —– OpenZeppelin's module documen…snapshot sits in the sequence.

Three denominators, three diff…rameworks pick different ones —– usually by inheritance rather…n Votes only on mint and burn —– delegation never touches it. …m is a fraction of the second —– 50% of Delegated Votable Toke…rum is really asking for 4/60 —– about 6.7% —– of the tokens that are capabl… treats from the quorum side.

Delegation thresholds: the bar…d before accepting a proposal —– a lookup into the delegate ch…selves cannot open a proposal —– not because they lack tokens,…to put anything on the agenda.

The same DAO can have two elec…other. None of this is hidden —– it is all in the space settings —– but it is rarely reconciled, …chain vote that failed quorum.

Failure modes - Inert supply … bar than its number suggests —– and it tightens further with …oting/token-weighted-voting) .

How Caper approaches this Cap…othing to activate by signing —– but the eligibility question …ero when that balance is zero —– so a member's first ballot is…nator problem described above —– it relocates it. Caper's deno…r) for the surrounding model.

References - OpenZeppelin Contracts —– governance/utils/Votes.sol (h…t) - OpenZeppelin Contracts —– ERC20Votes.sol (https://githu…s) - OpenZeppelin Contracts —– GovernorVotesQuorumFraction.s…st total supply) - Compound —– Comp.sol (https://github.com/…ro-address skip) - Compound —– GovernorBravoDelegate.sol (ht…s and caps) - Snapshot docs —– Voting strategies (https://do…ps.ethereum.org/EIPS/eip-5805)

Topic Which tokens are eligible to count as votes at all Activation step Delegation — including self-delegation — under ERC-5805 / ERC20Votes The three denominators Total supply · delegated supply · votes cast Thresholds it gates Proposal submission · quorum · delegate eligibility Chief failure A quorum priced against supply that structurally cannot vote Related Voting and delegation (/wiki/dao-governance/concepts/voting/voting-and-delegation) , Quorum and threshold design (/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) , Voter apathy (/wiki/dao-governance/concepts/analysis/voter-apathy)

Voting power activation is the step between owning a governance token and being able to vote with it. In the dominant on-chain governance stack, the two are not the same thing: a balance sitting in a wallet confers no voting power until its owner performs an explicit on-chain action — a delegation, usually to themselves. Until then the tokens are inert. They appear in every supply chart, every "% of supply held by the community" statistic and every market cap, and they cannot move a single proposal. This page covers the supply-side arithmetic that follows from that: how activation works mechanically, why it turns a DAO's electorate into a number distinct from its supply, and how the delegation thresholds built on top — the minimum voting power to submit a proposal, to reach quorum, or to be listed as a delegate — are all measured against that smaller number. Voting and delegation (/wiki/dao-governance/concepts/voting/voting-and-delegation) covers the social half: who to delegate to, how delegate markets form, and how they re-concentrate. This is the half underneath it.

Holding is not voting The pattern originates in Compound's Comp token (https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) , was generalised by OpenZeppelin's Votes (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/Votes.sol) module, and is now standardised as ERC-5805 (https://eips.ethereum.org/EIPS/eip-5805) , the interface OpenZeppelin's implementation declares. Its own source comment states the rule without hedging: voting units must be delegated in order to count as actual votes, and an account has to delegate to itself if it wants to participate and has no representative it trusts. The mechanism is a bookkeeping decision. A token contract that tracked voting power on every balance would have to write a checkpoint on every transfer, for every holder, forever. Instead these contracts keep two separate ledgers: balances, and a per-delegate checkpoint history. Transfers move balances always, and move votes only between the delegates the two parties have nominated. In Compound's token, _moveDelegates skips the source leg when the sender has no delegate and skips the destination leg when the receiver has none — so tokens moving between two never-delegated wallets change no vote count anywhere. OpenZeppelin's ERC20Votes (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol) says the same in its header: by default token balance does not account for voting power, which makes transfers cheaper, at the cost of requiring holders to self-delegate to activate checkpoints. The consequence is that a DAO's real electorate is not its holder set. It is the subset of holders who have signed one extra transaction — and since that transaction costs gas, produces nothing visible, and is easy to mistake for "giving someone else your tokens", a large share of any airdropped or exchange-held supply never takes it. Exchange-custodied balances in particular are almost never delegated on the beneficial owner's behalf.

Activation is a deadline, not a switch Because voting power is stored as a timestamped checkpoint history, every proposal reads it at a fixed past point — the snapshot. Delegating after that point does not retroactively create weight for that proposal. A holder who notices a contentious vote and self-delegates in response has activated for the next proposal, not the one they were reacting to. This is deliberate. Checkpointing at a past block is the standard defence against flash-loan governance attacks and against double-voting by transferring tokens between wallets mid-vote — OpenZeppelin's module documents exactly that motivation. But it converts activation from a thing you can do when it matters into a thing you had to have done already, which is a much weaker prompt. It is one reason turnout responds so poorly to controversy: by the time a proposal is controversial, the electorate for it is closed. See the DAO proposal lifecycle (/wiki/dao-governance/concepts/voting/proposal-lifecycle) for where the snapshot sits in the sequence.

Three denominators, three different electorates Once activation exists, a DAO has at least three defensible answers to "how big is the electorate", and governance frameworks pick different ones — usually by inheritance rather than by decision. - Total supply. OpenZeppelin's GovernorVotesQuorumFraction (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol) computes quorum as getPastTotalSupply(timepoint) × numerator / 100. That total is checkpointed in Votes only on mint and burn — delegation never touches it. So the stock configuration measures quorum against the whole supply while the votes that can satisfy it come only from the delegated part. - A fixed constant. Compound's Governor Bravo (https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) hard-codes quorumVotes = 400000e18, annotated in the source as 4% of COMP. It does not move with supply or with delegation at all, which makes it predictable and makes it drift out of calibration as either changes. - Delegated supply. The Arbitrum DAO Constitution (https://docs.arbitrum.foundation/dao-constitution) defines two terms rather than one: Votable Tokens are all ARB in existence excluding Foundation-held tokens and unclaimed airdrops, and Delegated Votable Tokens are the Votable Tokens that have actually been delegated. Quorum is a fraction of the second — 50% of Delegated Votable Tokens for a Constitutional AIP, 40% for a non-Constitutional one. The first option has an arithmetic problem that is easy to state and rarely stated. If 40% of a token's supply has never been delegated, a nominal 4% quorum is really asking for 4/60 — about 6.7% — of the tokens that are capable of voting. The bar is harder than the number printed on it, by a factor nobody voted for, that changes whenever holders delegate or undelegate. The third option has the mirror problem, which is why Arbitrum's constitution does not use the percentage alone. A quorum denominated in delegated supply falls when delegation falls, so an exodus of delegates would quietly make proposals easier to pass. The constitution caps and floors the result: the Constitutional quorum is pinned at 150,000,000 tokens if half of delegated supply comes out below that, and capped at 450,000,000 above it, with a 100,000,000 / 300,000,000 pair for non-Constitutional AIPs. Those bounds exist precisely because the denominator is the kind of number that can collapse. This is the same design question quorum and threshold design (/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) treats from the quorum side.

Delegation thresholds: the bar to speak Activation also gates the right to propose, and proposal thresholds are measured in delegated votes rather than in tokens held. Compound's Governor Bravo checks comp.getPriorVotes(msg.sender, block.number - 1) > proposalThreshold before accepting a proposal — a lookup into the delegate checkpoint history, not the balance mapping. Its configurable range is bounded in the source at MIN_PROPOSAL_THRESHOLD = 1000e18 and MAX_PROPOSAL_THRESHOLD = 100000e18, so the governor can never be set to accept proposals from an address with no delegated weight at all, and can never demand more than 100,000 COMP. Arbitrum sets the same kind of bar at both ends of its process: an on-chain AIP requires a proposer address delegated at least 1,000,000 Votable Tokens, and even the optional off-chain temperature check requires an address that can vote at least 0.01% of Votable Tokens. A holder of a million ARB who has never delegated to themselves cannot open a proposal — not because they lack tokens, but because the contract cannot see them. The practical effect is that proposal rights concentrate faster than token ownership does. A threshold set at some fraction of supply is met by a much smaller number of addresses once you count only delegated weight, and it is met almost exclusively by professional delegates who have accumulated others' power. That is the supply-side reason DAO agendas are set by a short list of names; it is not only that most holders do not care, it is that most holders are not eligible to put anything on the agenda.

The same DAO can have two electorates at once Most DAOs run an off-chain signalling vote before an on-chain execution vote, and the two venues often do not count the same thing. Snapshot's voting strategies (https://docs.snapshot.box/user-guides/voting-strategies) are configured per space, and the default is erc20-balance-of, which reads a raw ERC-20 balance. A separate erc20-votes strategy exists specifically to read delegated balances instead, and a delegation strategy layers delegation on top of any other. A DAO that leaves the default in place and then executes through an on-chain Governor is therefore polling one electorate and binding a different, smaller one. Never-delegated tokens carry full weight in the temperature check and zero weight in the vote that actually moves funds. Snapshot also runs its own native delegation (https://docs.snapshot.box/user-guides/delegation) , separate again from the token contract's, so a holder can be delegated in one venue and not the other. None of this is hidden — it is all in the space settings — but it is rarely reconciled, and it is a standing source of the gap between a signal vote that passed comfortably and an on-chain vote that failed quorum.

Failure modes - Inert supply read as decentralisation. Distribution statistics count holders; governance counts delegates. A DAO can report broad token ownership and still have an electorate of a few hundred addresses. Any comparison of DAOs on "% of supply held by the community" is measuring something that governance does not use. - A quorum nobody re-priced. A percentage-of-supply quorum inherited from a template, applied to a token where a large fraction has never activated, is a stricter bar than its number suggests — and it tightens further with every new holder who does not delegate. See voter apathy (/wiki/dao-governance/concepts/analysis/voter-apathy) for the participation half of the same failure. - Reactive activation arrives too late. The snapshot means the response to a contentious proposal cannot affect it. Campaigns that successfully mobilise holders routinely mobilise them into the following vote. - Delegated power without a live delegate. Delegation does not expire. Weight assigned to a delegate who has stopped voting is worse than undelegated weight: it is counted in the delegated-supply denominator, so it raises a delegated-supply quorum, while never voting. A dormant delegate is a quorum tax. - Threshold capture. When proposal rights require delegated weight that only a handful of addresses hold, the set of people who can put a question to the DAO is decided by the delegation market rather than by the token distribution. See token-weighted voting (/wiki/dao-governance/concepts/voting/token-weighted-voting) .

How Caper approaches this Caper has no delegation primitive, so there is nothing to activate by signing — but the eligibility question does not disappear, and its answer is unusual enough to be worth stating plainly. Casting a ballot requires a proof of at least one of that caper's tokens; holding is the entry ticket. Weight is then the product of two factors read at vote time: the ballot records the voter's token balance and their balance of that caper's soulbound vote token, and weight is computed as those two multiplied and divided by the vote-token supply and the token's circulating supply. Voting mints exactly one vote token to the voter, and that mint is the only way vote tokens are ever created. Two consequences follow directly. First, the vote-token balance is read before the ballot's own mint, and weight is zero when that balance is zero — so a member's first ballot is recorded and counts for nothing; it buys the token that gives their second one weight. Activation exists, and you activate by participating rather than by delegating. Second, holdings are a multiplicative factor rather than the whole story: a large balance with no participation history multiplies by zero, and a long participation history with no holdings does too. Neither leg carries a vote alone. What this does not do is solve the denominator problem described above — it relocates it. Caper's denominator is the token's circulating supply, which is knowable on-ledger rather than dependent on how many holders remembered to sign something. See Voting (/wiki/governance/voting) for the mechanics and what is a caper (/wiki/foundations/what-is-a-caper) for the surrounding model.

References - OpenZeppelin Contracts — governance/utils/Votes.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/Votes.sol) (the delegation requirement and the total-supply checkpoint) - OpenZeppelin Contracts — ERC20Votes.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol) (self-delegation to activate checkpoints) - OpenZeppelin Contracts — GovernorVotesQuorumFraction.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol) (quorum as a fraction of past total supply) - Compound — Comp.sol (https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) (_moveDelegates and the zero-address skip) - Compound — GovernorBravoDelegate.sol (https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) (quorum constant and proposal-threshold bounds) - The Arbitrum DAO Constitution (https://docs.arbitrum.foundation/dao-constitution) (Votable Tokens, Delegated Votable Tokens, quorum floors and caps) - Snapshot docs — Voting strategies (https://docs.snapshot.box/user-guides/voting-strategies) and Delegation (https://docs.snapshot.box/user-guides/delegation) - ERC-5805: Voting with delegation (https://eips.ethereum.org/EIPS/eip-5805)