# Validator Count and Nakamoto Coefficient by Chain

> Validator count by blockchain with the Nakamoto coefficient at a third and at half of stake, the top ten's share, set limits and how validators join each chain.

Markdown copy of https://voltfincrypto.com/apps/validator-count-by-chain

**Question:** How many validators does each chain have, and how few of them control a third of the stake?

- Kind: Table in Voltfin Strata
- Topic: [Staking and restaking](https://voltfincrypto.com/topics/staking)
- Chains: Multi-chain, Ethereum, Solana, Sui, Aptos, Avalanche, BNB Chain, Polygon, Cardano, NEAR, TON, Tron, Hyperliquid, Monad, Sonic, Berachain
- Status: Planned. The data is not published yet, so this page states no figure; each figure will open its receipt when it is.

Proof-of-stake chains are secured by validators whose weight in consensus follows their stake, so how many validators a chain has matters less than how stake is spread among them. This table puts each chain's validator set side by side: how many validators are active, any limit on the set and how they join, along with the Nakamoto coefficient, the fewest validators that together hold enough stake to stall or overrule the rest.

Every chain is measured with one formula from its own staking state at the latest epoch boundary. Where one operator runs many validators and the chain or a public label shows it, they are grouped; where not, the row says so. Sort by the coefficient to compare concentration, and open any row to see the epoch and calls behind it.

## Blueprint

One row: One row per proof-of-stake chain, at its latest completed epoch boundary

- **Chain** (`chain`): The proof-of-stake chain the row describes.
- **Counted as** (`counted_as`): What one validator is on this chain: a vote account, a stake pool, a super representative or validator keys grouped by staking entity.
- **Validators** (`validators`): Active validators in the consensus set at the latest epoch boundary.
- **Active set limit** (`set_limit`): The most validators the active set can hold under the protocol's parameters; empty where there is no cap.
- **Nakamoto coefficient, one third** (`nakamoto_third`): The fewest validators whose combined stake exceeds one third of active stake.
- **Nakamoto coefficient, half** (`nakamoto_half`): The fewest validators whose combined stake exceeds half of active stake.
- **Top 10 share** (`top10_share`): The share of active stake held by the ten largest validators or groups.
- **How validators join** (`entry`): Permissionless by stake, elected by votes, the top stakers into a capped set or approved by governance or a foundation.
- **Change, 30 days** (`change_30d`): The net change in active validators against the epoch closest to thirty days earlier.
- **Receipt** (`receipt`): The epoch, block and staking calls behind the row.

## How it will be measured

- Each chain's active validator set and stake weights are read from its own staking state at the latest epoch boundary: vote accounts on Solana, the system state on Sui, the validator set on Aptos, getCurrentValidators on Avalanche's P-Chain, stake per pool on Cardano, config param 34 on TON and equivalents elsewhere.
- The Nakamoto coefficient is the fewest validators whose combined stake exceeds a threshold: one third, enough to halt chains with BFT consensus, and half, the threshold that matters for chains that follow the longest chain.
- Validators run by one operator are grouped where the chain records it or a public label supports it, such as Ethereum validator keys grouped by staking entity; elsewhere each validator counts on its own, which can overstate decentralization.
- Every row names the epoch and block it was read at, with the calls behind it.

## Data it needs

- `staking_networks_daily` (to build): Staked supply, staking ratio, validators and nominal rewards per proof-of-stake network per day.
- `eth_staking_daily` (to build): Active validators, ETH staked, deposits, withdrawals and the entry and exit queues on the Ethereum beacon chain, by day, with staking-provider labels where known.
- `address_labels` (to build): Labels for known addresses: exchanges, bridges, protocols, funds, treasuries, sanctioned addresses and known attackers.
- Source: Solana getVoteAccounts, the Sui system state, the Aptos validator set and Avalanche P-Chain getCurrentValidators at epoch boundaries
- Source: Cardano stake distribution per pool, NEAR validators, TON config param 34 and Tron witnesses with their votes
- Source: BNB Chain StakeHub validators, the Polygon PoS StakeManager on Ethereum and Hyperliquid validator stakes
- Source: Monad, Sonic and Berachain staking contracts and consensus validator sets at epoch boundaries
- Source: Ethereum beacon chain validators with balances and withdrawal credentials, grouped by staking entity labels
- Source: Protocol parameters that cap the active set, where a chain has one

## Questions

### What is the Nakamoto coefficient?

The smallest number of validators that together control enough stake to disrupt consensus. On chains with BFT consensus that threshold is one third of stake, enough to stop blocks from being finalized; a higher coefficient means control is spread more widely. It measures stake concentration, not who runs the machines.

### Why does a validator count alone mislead?

Because weight follows stake. A chain with many validators can still have most of its stake on a few, and one company can run many validators. The table shows the count beside the Nakamoto coefficient and the share held by the top ten, which together describe concentration better.

### Why do some chains cap their validator set?

Some designs keep a fixed or limited number of block producers to keep consensus fast: Tron's super representatives and BNB Chain's active validators are chosen by votes or stake into a set of limited size. A capped set puts a ceiling on the count, so the coefficient is read against the cap.

### How are Ethereum validators counted?

An Ethereum validator is a key holding staked ETH, and large operators run many keys. Counting keys would overstate decentralization, so Ethereum's row groups validators by staking entity, using withdrawal credentials and public labels, and states how much stake could not be attributed.

### How often is the table updated?

Daily, from the latest completed epoch on each chain. Epoch lengths differ widely between chains, from a few hours on some to about a day on Sui and five days on Cardano, so each row names the epoch and the block it was read at.

## Glossary

- **Nakamoto coefficient**: The fewest validators whose combined stake passes a consensus threshold, such as one third of stake on BFT chains.
- **Active set**: The validators that take part in consensus in the current epoch, as opposed to candidates waiting to join.
- **BFT consensus**: Byzantine fault tolerant consensus, which keeps finalizing blocks while less than a third of stake is faulty or offline.
- **Staking entity**: The operator or service behind a group of validators, identified from on-chain records or public labels.

## Related apps

- [Solana Validator Count and Stake Concentration](https://voltfincrypto.com/apps/solana-validator-count)
- [Staking Yield and Staking Ratio by Chain](https://voltfincrypto.com/apps/staking-yield-by-chain)
- [Layer 1 Blockchain List: Activity, Fees and Staking](https://voltfincrypto.com/apps/layer-1-blockchain-list)
- [Total ETH Staked and Ethereum Staking Ratio](https://voltfincrypto.com/apps/total-eth-staked)
- [Bitcoin Mining Pools: Hashrate Share by Pool](https://voltfincrypto.com/apps/bitcoin-mining-pool-share)
- [EigenLayer Restaking: TVL, Operators, AVSs and Slashing](https://voltfincrypto.com/apps/eigenlayer-restaking-dashboard)

Build it in Voltfin Studio: https://app.voltfincrypto.com/signup?next=%2F