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.

Holding is not voting

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.

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 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 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 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 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 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 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.

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 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; see delegate accountability and dormant delegates for the mechanisms DAOs have deployed against it.
• 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.

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 for the mechanics and what is a caper for the surrounding model.

References

• OpenZeppelin Contracts – governance/utils/Votes.sol (the delegation requirement and the total-supply checkpoint)
• OpenZeppelin Contracts – ERC20Votes.sol (self-delegation to activate checkpoints)
• OpenZeppelin Contracts – GovernorVotesQuorumFraction.sol (quorum as a fraction of past total supply)
• Compound – Comp.sol (_moveDelegates and the zero-address skip)
• Compound – GovernorBravoDelegate.sol (quorum constant and proposal-threshold bounds)
• The Arbitrum DAO Constitution (Votable Tokens, Delegated Votable Tokens, quorum floors and caps)
• Snapshot docs – Voting strategies and Delegation
• ERC-5805: Voting with delegation