A vote closes, the tally is published, and it reads as a decision the community made. Voter concentration asks the narrower question underneath it: how few parties had to agree for that outcome to exist. The answer is not the holder list, it is not fixed by the token supply, and it moves depending on which denominator the share is measured against.
What voter concentration measures
Voter concentration is a property of votes cast, not of tokens held. It asks how the weight that decided a proposal was spread across the addresses that submitted it. A DAO can have a wide holder base and a narrow decision base at the same time, because holding is passive and voting is an action somebody has to take.
The unit of measurement is voting weight, not headcount. One address casting the weight of a million tokens and one address casting the weight of ten each count as a single voter, and only the first of them changes the result. A participation rate expressed in wallets tells you how many parties showed up; it does not tell you which of them decided.
That is why the analysis has to name its outcome before it counts anything. The concentration relevant to passing a routine parameter change is not the concentration relevant to reaching quorum, to blocking a proposal, or to approving an upgrade that can move the treasury. Each of those has its own threshold, and the number of independent parties needed to reach one is not the number needed to reach another.
Holder concentration is a different reading
A top-holder list answers who owns the token. Concentration metrics built on balances describe how the supply is spread, and a heavily concentrated balance sheet is a standing reason to expect governance capture. But a balance is a capacity, not a record of use. A governance token sitting in a wallet that has never voted contributes nothing to any tally.
The two readings come apart in both directions. A large holder that abstains has a share of votes cast of zero while its share of supply is untouched. A small holder that votes on every proposal can hold a share of decisions far above its share of supply, because the rest of the base is absent. Reading supply concentration and reporting it as voter concentration substitutes the capacity for the exercise.
Both belong in the same report, measured against the same snapshot. Supply concentration describes the worst case if everyone voted. Voter concentration describes what happened when they did not. The distance between the two numbers is the room a small coordinated group has to work in.
What a concentration figure has to declare
A concentration figure does not travel unless it states four things: the subsystem it covers, the threshold it is testing, the weight it counts, and the rule that grouped addresses into entities. The Nakamoto coefficient applies that discipline to networks, asking for the smallest number of independent entities whose combined weight reaches a stated threshold. A governance version of the same question is readable only when those four fields travel with the number.
The threshold is the field that gets borrowed by accident. An organisation whose proposals pass on a simple majority of votes cast, one that requires a supermajority, and one whose treasury sits behind a separate multisignature contract are testing three different conditions. A coefficient computed under one of them says nothing about another.
The snapshot is the field that goes stale. Voting weight is fixed at a point in time, delegations are revocable, and a distribution measured before a large unlock describes an organisation that no longer exists afterwards. Record the block or timestamp beside every share, and treat a figure without one as unreproducible rather than as current.
Turnout decides the denominator
Turnout is the ratio of weight cast to weight that could have been cast, and it moves a concentration reading without any holding changing hands. The same address, holding the same tokens, can be a rounding error against supply and a majority against the weight that was actually submitted. Neither statement is wrong; they answer different questions.
A share is therefore interpretable only with its denominator attached. Three denominators are in play, and they are not interchangeable.
| Denominator | What a share of it means | What it leaves out |
|---|---|---|
| Circulating supply | Capacity to vote if everyone did | Nobody is obliged to use that capacity |
| Eligible voting weight at the snapshot | Weight that could be cast under the rules in force | Tokens that carry no weight are excluded |
| Weight actually cast | Weight that produced this outcome | Says nothing about who stayed away |
Report all three, or say which one is in use. A concentration series compiled across proposals with a shifting denominator will move for reasons that have nothing to do with who controls the organisation.
Delegation moves voting power without moving tokens
In OpenZeppelin's governance contracts, voting weight is carried by delegates: a holder who wants to participate either appoints a representative or becomes a delegate by self-delegating, and the token extension keeps historical balances so that weight is read from a past snapshot rather than a current balance. A holder who has never delegated therefore holds tokens with no voting weight attached to them.
This breaks the correspondence between a balance and a vote in a way an address-level analysis will miss. Weight can accumulate at a delegate address that owns almost nothing, and a large balance can sit outside the electorate entirely. The delegate register, not the holder list, is where the concentration relevant to a vote is visible.
Offchain voting adds a second layer. Snapshot computes voting power from a configured strategy rather than from a balance directly, and it documents that several strategies can be combined so that the total is the sum of the power each one returns. Two organisations reporting the same concentration figure under different strategy configurations are not reporting the same measurement.
A worked example on one proposal
Set the inputs by hand. Suppose the weight cast on a proposal amounts to 10% of circulating supply, the largest single voter holds 5% of circulating supply and voted, and the five largest voters hold 8% of circulating supply between them and all voted.
Measured against supply, the largest voter looks small. Measured against the weight actually cast, it holds 50% of the total on its own, and the five largest hold 80% between them. The addresses and the balances did not change; only the denominator did. One framing says a small holder decides nothing alone, the other says one address carried the proposal.
Now add the quorum rule, which interacts with turnout rather than with concentration. The OpenZeppelin governance documentation defines quorum as a percentage of total supply at the block the voting power is retrieved from, and illustrates the setting with a quorum of 4% of total supply. Under the inputs above, the five largest voters clear that bar without any other participant appearing at all, and the proposal is both quorate and decided by five addresses.
Addresses are not entities
Every share computed above is a share across addresses, and addresses are technical records. One party can spread a position over many of them, and one custodial address can hold balances belonging to thousands of unrelated people. Grouping is an inference, and it should be recorded as one, with the evidence behind each grouping and an explicit bucket for addresses that could not be attributed.
Getting the grouping wrong moves the answer in both directions. Splitting one party across several addresses understates concentration; merging independent parties into one labelled cluster overstates it. Where the mapping is incomplete, report a range with its assumptions stated instead of one exact figure that hides them.
The rest of the picture sits outside the vote record. A tokenomics checklist covers the supply, unlocks, allocation and treasury facts that determine who will be able to vote next quarter, and the contract layer determines whether a passed vote can be executed at all. Voter concentration is one input into that assessment.
| Field to record | Question it answers | An answer that fails |
|---|---|---|
| Subsystem | Which decision the figure covers | Governance, unqualified |
| Threshold | What outcome counts as control | A threshold borrowed from another organisation |
| Weight | What is being added up | A count of wallets |
| Entity map | Which addresses were grouped, on what evidence | Addresses treated as parties |
| Snapshot | When the weight was fixed | A live dashboard with no timestamp |
The bottom line
Voter concentration measures the spread of the weight that decided something, and it answers a different question from the one a holder list answers. Turnout sets the denominator, delegation sets who carries the weight, and the entity mapping sets how many independent parties the count believes exist. Change any of the three and the same organisation produces a different number.
So write the four declarations down before reporting a figure, attach a snapshot to it, and keep the supply reading beside the vote reading rather than in place of it. A concentration number without those fields is not a measurement of control, only an arithmetic result. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- How to Revoke a Governance Delegation
- Why a Token Migration Asks for a Wallet Approval
- Token Migration Completed but New Tokens Are Not in Your Wallet
- NFT Mint Succeeded but the NFT Is Not Showing in Your Wallet
- What Is Crypto Wallet Encryption? How Your Keys Stay Safe
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] OpenZeppelin, Contracts for Solidity 5.x, Governance docs.openzeppelin.com
[2] Snapshot Documentation, User guides, Voting strategies docs.snapshot.box






