Solana Validator Count and Stake Concentration
How many validators secure Solana each epoch, how stake is spread among them, the Nakamoto coefficient, skip rates and who joined or left.
SolanaTable · StrataPlanned
Validator Count and Nakamoto Coefficient by Chain
How many validators does each chain have, and how few of them control a third of the stake?
Proof-of-stake validator sets side by side: active validators, any cap on the set, how validators join and the Nakamoto coefficient.
ShareEmail it
Blueprint
What the table will hold.
The table as it will open in Strata. Each figure is named here and arrives with its receipt; until its data is published, its place stays empty.
One row One row per proof-of-stake chain, at its latest completed epoch boundarySorted by Nakamoto coefficient, one third, highest first
| Chain | Counted as | Validators | Active set limit | Nakamoto coefficient, one third | Nakamoto coefficient, half | Top 10 share | How validators join | Change, 30 days | Receipt |
|---|---|---|---|---|---|---|---|---|---|
- Chain chain Chain
- The proof-of-stake chain the row describes.
- Counted as counted_as Text
- 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 Number
- Active validators in the consensus set at the latest epoch boundary.
- Active set limit set_limit Number
- 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 Number
- The fewest validators whose combined stake exceeds one third of active stake.
- Nakamoto coefficient, half nakamoto_half Number
- The fewest validators whose combined stake exceeds half of active stake.
- Top 10 share top10_share Percent
- The share of active stake held by the ten largest validators or groups.
- How validators join entry Text
- 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 Number
- The net change in active validators against the epoch closest to thirty days earlier.
- Receipt receipt Link
- The epoch, block and staking calls behind the row.
Filter by How validators join, Counted as.
About
What it answers, and for whom.
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.
Method
How it will be measured.
Every figure will be read at a block, kept with its source and its exact read, and open a receipt anyone can re-check.
How receipts work →- 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.
The data it needs
Chain data, with some off-chain sources
- staking_networks_dailyTo buildProof-of-stake networksStaked supply, staking ratio, validators and nominal rewards per proof-of-stake network per day.
- eth_staking_dailyTo buildEthereum staking and validatorsActive 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_labelsTo buildAddress labelsLabels for known addresses: exchanges, bridges, protocols, funds, treasuries, sanctioned addresses and known attackers.
- Solana getVoteAccounts, the Sui system state, the Aptos validator set and Avalanche P-Chain getCurrentValidators at epoch boundaries
- Cardano stake distribution per pool, NEAR validators, TON config param 34 and Tron witnesses with their votes
- BNB Chain StakeHub validators, the Polygon PoS StakeManager on Ethereum and Hyperliquid validator stakes
- Monad, Sonic and Berachain staking contracts and consensus validator sets at epoch boundaries
- Ethereum beacon chain validators with balances and withdrawal credentials, grouped by staking entity labels
- Protocol parameters that cap the active set, where a chain has one
Questions
Questions people ask.
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.
- 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
More apps like this.
Staking Yield and Staking Ratio by Chain
Gross staking yield, yield after supply growth and the share of supply staked on each proof-of-stake chain, from on-chain rewards.
Multi-chainEthereumSolana+12Layer 1 Blockchain List: Activity, Fees and Staking
Major layer 1 chains in one sortable table: transactions, active addresses, fees, block time, validators, staked share and mainnet date.
Multi-chainBitcoinEthereum+13Total ETH Staked and Ethereum Staking Ratio
ETH staked on the beacon chain, its share of total supply, active validators and the deposits and exits that move it, epoch by epoch.
EthereumBitcoin Mining Pools: Hashrate Share by Pool
Which pools found Bitcoin's blocks over the last day, week and month, the hashrate share each implies and how concentrated mining is.
BitcoinEigenLayer Restaking: TVL, Operators, AVSs and Slashing
Assets restaked on EigenLayer by strategy, the operators they are delegated to, the AVSs those operators secure and each slashing event.
EthereumBuild Validator Count and Nakamoto Coefficient by Chain on verified data.
Start free in Voltfin Studio: boards, tables and reports where every number opens its receipt. Tell us which data you need first and we will build it next.