Token-weighted voting — often called one-token-one-vote — is the rule that a voter's influence is proportional to how many governance tokens they hold. It is the on-chain default: the great majority of DAOs count votes this way, and it is the baseline against which every other governance model is defined. Its appeal is that it is simple, fully mechanical, and Sybil-resistant by construction — because influence is tied to a scarce, market-priced asset, splitting your holdings across a thousand wallets changes nothing, and buying more influence means buying more of the token. This page covers how it works on-chain, why it won, and the well-documented ways it fails.

How on-chain token voting works

The dominant implementation is the OpenZeppelin Governor pattern, standardized after Compound's 2020 Governor Bravo and now running under hundreds of DAOs. A governance token implements a votes extension (ERC-20 ERC20Votes) that records a checkpointed balance history, so the contract can ask "how many tokens did this address control at block N?". Voting power must be activated by delegation — holders delegate to themselves or to a representative — which is why raw token balances and active voting power often differ sharply.

A proposal then moves through a fixed lifecycle: it is submitted (subject to a proposal threshold), enters a voting period during which each address's weight is read from a snapshot block fixed at proposal creation, and — if support clears the threshold and quorum is met — is queued in a timelock before it can execute. The snapshot is load-bearing: because weight is counted as of a past block, tokens acquired after a proposal is filed carry no weight, which is the standard structural defense against flash-loan vote seizure.

Why it became the default

Token voting won for practical reasons, not because it is fair. It needs no identity layer — the hardest unsolved problem in on-chain governance — because it never has to know who anyone is, only how many tokens they moved. It is legible: anyone can compute the outcome from public balances. It is composable: a single ERC-20 doubles as the fundraising instrument, the liquidity-mining reward, and the ballot, and it drops straight into off-the-shelf tools like Tally and Snapshot. For a protocol that has to ship, "issue a token and wire it to a Governor" is the path of least resistance — and so it became the path almost everyone took. (Chainlink: governance tokens and DAO voting)

The plutocracy critique

The defining objection is that one-token-one-vote is one-dollar-one-vote: whoever holds the most tokens decides, so a protocol that calls itself decentralized can be steered by a handful of founders, funds, and exchanges. The concentration is measurable — analysts track a DAO's Nakamoto coefficient (how few addresses it takes to reach a majority) — one of the core DAO health metrics — and for many large DAOs that number is uncomfortably small. Compounding it is voter apathy: because a small holder's vote almost never changes an outcome, turnout in token-weighted DAOs routinely runs in the single digits, which concentrates effective power even further into the few large holders who do show up. Forbes summarized a decade of findings under a blunt 2026 headline: DAOs keep centralizing.

Vote-buying and token lending

The subtler failure is that token voting decouples influence from stake. A voter who borrows tokens to vote and returns them afterward has, as Vitalik Buterin argues, "zero net exposure" to the consequences of the decision — they capture any upside of a self-serving vote while bearing none of the downside to the token. This is not hypothetical: lending markets, liquid-staking wrappers, and outright bribe markets (the Curve Wars' vote-incentive platforms) all let voting power be rented. The result is a bundling vulnerability — voting rights that were supposed to be tied to long-term ownership become just another yield to be farmed, and a well-capitalized outsider can assemble a temporary majority without any lasting alignment. It is the mechanism behind several governance attacks.

Mitigations

Rather than abandon token voting, most DAOs bolt defenses onto it. Past-block snapshots neutralize flash-loaned weight. Timelocks and guardian vetoes buy time to react to a captured vote. Vote-escrow (ve) locks — as in Curve's veCRV — time-weight tokens so transient capital counts for less than committed capital. Delegation lets apathetic holders hand their weight to engaged representatives, raising effective participation. And a growing number of designs combine stake with something money cannot cheaply buy — verified identity (for quadratic voting), elapsed time, or demonstrated participation — accepting a little more complexity to escape pure plutocracy. (a16z governance FAQ)

How Caper approaches this

A caper deliberately departs from pure token weighting. Stake still matters — a member's holdings are one factor in their weight — but weight is the product of that stake and the member's earned participation, recorded as non-transferable tokens minted one per vote. A large balance that has never voted therefore carries little weight, which blunts both the plutocracy problem (idle capital does not automatically rule) and the vote-buying problem (borrowed or freshly-acquired tokens bring no participation history, and that history cannot be rented). Combined with a ranked-choice super-majority, an execution delay, and a pro-rata exit right that ties each member's voice to their claim on the treasury, the design keeps token voting's Sybil-resistance while shedding its one-dollar-one-vote default. The mechanics are on the linked governance pages.

References

• Vitalik Buterin, Moving beyond coin voting governance (2021).
• Chainlink, Governance Tokens and DAO Voting.
• a16z crypto, DAO governance FAQ.
• OpenZeppelin, Governor & Votes contracts.
• Forbes, DAOs Keep Centralizing (2026).