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 covers the social half: who to delegate to, how delegate markets form, and how they re-concentrate. This is the half underneath it.
The pattern originates in Compound's Comp token, was generalised by OpenZeppelin's Votes module, and is now standardised as ERC-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 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.
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'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). Arbitrum voted to fund the approach for ARB in September 2024; see delegate incentive programs.
Two other fixes avoid a wrapper token. 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). 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).
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 for where the snapshot sits in the sequence.
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.
GovernorVotesQuorumFraction 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.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.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 treats from the quorum side.
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.
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 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, 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.
A space can also answer the problem at the venue instead of leaving it to holders. 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.
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 the ballot records at vote time – the voter's token balance and their balance of that caper's soulbound vote token – 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 vote token to the voter (VOTE_MINT), alongside a flat 100 XRD vote fee paid into the caper's treasury, and it is the only mint a member can reach. Buying or selling on the caper's bonding curve minted vote tokens too, at 0.01 per XRD of gross value on each leg, until the redeploy of 11 September 2026 removed the trade-side mint (contracts/logic/src/lib.rs).
Two consequences follow directly. First, the ballot's snapshot counts its own mint in both the voter's vote-token balance and the supply it divides by, so a first ballot always carries weight: with ballots the only source, a snapshot taken before 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 out of other people's buys carries no vote tokens until its holder casts a ballot.
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 voted is exactly the holder this case describes (see what a founder can and cannot take). Activation exists, and you activate by participating – by voting – 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 for the mechanics and what is a caper for the surrounding model.
governance/utils/Votes.sol (the delegation requirement and the total-supply checkpoint)ERC20Votes.sol (self-delegation to activate checkpoints)GovernorVotesQuorumFraction.sol (quorum as a fraction of past total supply)Comp.sol (_moveDelegates and the zero-address skip)GovernorBravoDelegate.sol (quorum constant and proposal-threshold bounds)