The Nakamoto Coefficient measures how decentralized a network actually is: the minimum number of independent entities that must collude to break the network — the smallest set that controls more than half of some critical resource. A higher value means the network resists more colluding actors before it falls. How it works The statistic is calculated by sorting participants by share and counting how many of the largest you must take before their combined share passes the threshold: Choose the resource: for a proof-of-stake chain it is stake (or block production); for proof-of-work it is hash power; for a validator or sequencer set it is the entities weighting block production or ordering. Sort and sum: list participants largest-first; keep adding their shares until the cumulative total crosses the threshold — classically 50%, and 33% where the network is BFT. Interpret: the count is the number of colluders needed to cross the line — a threshold past which finality, ordering, or censorship resistance breaks. The limitation is intentional: the Nakamoto Coefficient reports number of actors, not share of control. A network with 100 equally-sized validators scores 51; one with three validators holding 34%/33%/33% also hovers near 3. It compares apples to apples only when you also read the Gini-like share distributions underneath. It also ignores non-stake vectors of control — governance tokens, infrastructure layers, or key holders — which is why the W3D methodology pairs it with pillar scores that capture governance, software, and capital layers separately. Why it matters for decentralization The metric and the methodology that empowers it turn "decentralized" from a marketing claim into a falsifiable number. Instead of arguing about vibes, you can say: "on this chain, fewer than ten entities can correlate a majority of blocks" — a statement anyone can verify by reading the same dataset. That is exactly what our chain audits do; on the Nakamoto Coefficient tool you can compute the value for any live chain yourself, and the Ethereum, Solana, and Arbitrum audits surface the underlying actor sets in tables. Example: comparing two networks Two networks can both claim "51% safety" in different currencies. Chain A has 2,000 validators each holding 0.05% of stake plus a cloud provider hosting 40% of nodes: stake-based NC might be high, but infrastructure-based NC is roughly 3 — hardware vendor lock-in quietly determines the real threshold. Chain B has 96 validators and a sequencer that wins 99% of blocks: its NC is effectively 1 despite a diffuse validator set, because block ordering is what binds. The takeaway keeps recurring in our research: always compute the coefficient on the resource that actually binds (consensus, ordering, or settlement), or the number is a vanity metric. How to compute it yourself Pull the shares: fetch the validator roster (stake per validator) from the chain's public state or a staking explorer. Correlate entities: group addresses controlled by the same operator (exchange, pool, custodian) so pooled operators count once. Sort descending: list entities from highest to lowest stake share. Sum to 50%: add shares one at a time until the running total first reaches 50%; the number of entities used is your coefficient for consensus weight. Repeat per binding resource: block production share, sequencer share, infrastructure share — a chain's honest NC is the minimum across the resources that actually bind (finality, ordering, or liquidity). Reference values across major networks NetworkResource measuredApproximate NC BitcoinHashrate concentrated across ~2–3 pools~2–3 EthereumStake pools (Lido + exchanges)~2 SolanaValidators weighted by stake~2–4 ArbitrumSequencer / fraud-proof availability~1 (sequencer) Values in the single digits are the norm across every major network — which is precisely why a metric you can compute per-resource is worth more than a headline logo; the W3D tool applies exactly this per-resource logic live. Why the threshold is 50%: the "BFT vs Nakamoto" gap The classic Nakamoto threshold is 50% of hashpower/stake, inherited from the original "attacker with majority control double-spends" model. Many modern networks are actually Byzantine fault-tolerant systems, where the honest-security breaks at one-third (33%) byzantine fault; so a conscientious NC for those networks should be computed against 33% as well. The difference is not academic: a network with NC(50%)=8 may already have crossed its BFT 33% line at entity number 3. Our methodology reports both columns and defaults the headline number to the stricter (33%) bound unless the network's consensus is truly majority-honest. If you compute NC by hand, always state which threshold you used — 50% or 33% — and why. The metric's entire value is precision, and a number without its threshold and its resource is a slogan. When in doubt, re-read the original definition: it exists to make "decentralized" testable. Compute it per resource, name the threshold and the dataset, and let the disagreements become precise instead of loud — that precision is the metric's only job, and it does it well. Limitations & advanced considerations Unknown identities: addresses are not necessarily distinct actors; correlation across addresses requires additional data (client diversity, geographical co-location). Time variance: the 50% line shifts with reward curves and slashes; a snapshot is a point-in-time truth, not a permanent grade. Layer error: a strong NC on consensus does not neutralize a weak NC on sequencer or key infrastructure — compute each binding resource. Assuming intent: high NC assumes collusion is possible, not that it occurs; adversarial incentives (loss of deposits or reputation) act as brakes the raw number does not price in. Frequently asked questions Is a higher Nakamoto Coefficient always better? Generally yes for resistance to collusion, but it is one lens. Two networks with the same coefficient can differ wildly in where control actually sits; read the distribution, not just the number. What is a good Nakamoto Coefficient? There is no universal threshold; Bitcoin's is ~2–3 majors on mining pools, and Ethereum hovers around 2 on staking pools. Values in the single digits are the norm across every major proof-of-work and proof-of-stake network today. Where can I compute it for a specific chain? Use our Nakamoto Coefficient tool, which pulls live validator and stake data and explains exactly which resource it measured. Sources & methodology Balaji S. Srinivasan — Quantifying Decentralization — the original definition of the metric. W3D methodology + academy dataset — our entity-collapsing and share-weighting algorithm. Related terms Nakamoto Coefficient (definition) · Validator · Staking · MEV-Boost Chain audits: Ethereum · Solana · tool: Nakamoto Coefficient tool
The Nakamoto Coefficient measures how decentralized a network actually is: the minimum number of independent entities that must collude to break the network — the smallest set that controls more than half of some critical resource. A higher value means the network resists more colluding actors before it falls.
How it works
The statistic is calculated by sorting participants by share and counting how many of the largest you must take before their combined share passes the threshold:
- Choose the resource: for a proof-of-stake chain it is stake (or block production); for proof-of-work it is hash power; for a validator or sequencer set it is the entities weighting block production or ordering.
- Sort and sum: list participants largest-first; keep adding their shares until the cumulative total crosses the threshold — classically 50%, and 33% where the network is BFT.
- Interpret: the count is the number of colluders needed to cross the line — a threshold past which finality, ordering, or censorship resistance breaks.
The limitation is intentional: the Nakamoto Coefficient reports number of actors, not share of control. A network with 100 equally-sized validators scores 51; one with three validators holding 34%/33%/33% also hovers near 3. It compares apples to apples only when you also read the Gini-like share distributions underneath. It also ignores non-stake vectors of control — governance tokens, infrastructure layers, or key holders — which is why the W3D methodology pairs it with pillar scores that capture governance, software, and capital layers separately.
Why it matters for decentralization
The metric and the methodology that empowers it turn “decentralized” from a marketing claim into a falsifiable number. Instead of arguing about vibes, you can say: “on this chain, fewer than ten entities can correlate a majority of blocks” — a statement anyone can verify by reading the same dataset. That is exactly what our chain audits do; on the Nakamoto Coefficient tool you can compute the value for any live chain yourself, and the Ethereum, Solana, and Arbitrum audits surface the underlying actor sets in tables.
Example: comparing two networks
Two networks can both claim “51% safety” in different currencies. Chain A has 2,000 validators each holding 0.05% of stake plus a cloud provider hosting 40% of nodes: stake-based NC might be high, but infrastructure-based NC is roughly 3 — hardware vendor lock-in quietly determines the real threshold. Chain B has 96 validators and a sequencer that wins 99% of blocks: its NC is effectively 1 despite a diffuse validator set, because block ordering is what binds. The takeaway keeps recurring in our research: always compute the coefficient on the resource that actually binds (consensus, ordering, or settlement), or the number is a vanity metric.
How to compute it yourself
- Pull the shares: fetch the validator roster (stake per validator) from the chain’s public state or a staking explorer.
- Correlate entities: group addresses controlled by the same operator (exchange, pool, custodian) so pooled operators count once.
- Sort descending: list entities from highest to lowest stake share.
- Sum to 50%: add shares one at a time until the running total first reaches 50%; the number of entities used is your coefficient for consensus weight.
- Repeat per binding resource: block production share, sequencer share, infrastructure share — a chain’s honest NC is the minimum across the resources that actually bind (finality, ordering, or liquidity).
Reference values across major networks
| Network | Resource measured | Approximate NC |
|---|---|---|
| Bitcoin | Hashrate concentrated across ~2–3 pools | ~2–3 |
| Ethereum | Stake pools (Lido + exchanges) | ~2 |
| Solana | Validators weighted by stake | ~2–4 |
| Arbitrum | Sequencer / fraud-proof availability | ~1 (sequencer) |
Values in the single digits are the norm across every major network — which is precisely why a metric you can compute per-resource is worth more than a headline logo; the W3D tool applies exactly this per-resource logic live.
Why the threshold is 50%: the “BFT vs Nakamoto” gap
The classic Nakamoto threshold is 50% of hashpower/stake, inherited from the original “attacker with majority control double-spends” model. Many modern networks are actually Byzantine fault-tolerant systems, where the honest-security breaks at one-third (33%) byzantine fault; so a conscientious NC for those networks should be computed against 33% as well. The difference is not academic: a network with NC(50%)=8 may already have crossed its BFT 33% line at entity number 3. Our methodology reports both columns and defaults the headline number to the stricter (33%) bound unless the network’s consensus is truly majority-honest. If you compute NC by hand, always state which threshold you used — 50% or 33% — and why. The metric’s entire value is precision, and a number without its threshold and its resource is a slogan.
When in doubt, re-read the original definition: it exists to make “decentralized” testable. Compute it per resource, name the threshold and the dataset, and let the disagreements become precise instead of loud — that precision is the metric’s only job, and it does it well.
Limitations & advanced considerations
- Unknown identities: addresses are not necessarily distinct actors; correlation across addresses requires additional data (client diversity, geographical co-location).
- Time variance: the 50% line shifts with reward curves and slashes; a snapshot is a point-in-time truth, not a permanent grade.
- Layer error: a strong NC on consensus does not neutralize a weak NC on sequencer or key infrastructure — compute each binding resource.
- Assuming intent: high NC assumes collusion is possible, not that it occurs; adversarial incentives (loss of deposits or reputation) act as brakes the raw number does not price in.
Frequently asked questions
Is a higher Nakamoto Coefficient always better?
Generally yes for resistance to collusion, but it is one lens. Two networks with the same coefficient can differ wildly in where control actually sits; read the distribution, not just the number.
What is a good Nakamoto Coefficient?
There is no universal threshold; Bitcoin’s is ~2–3 majors on mining pools, and Ethereum hovers around 2 on staking pools. Values in the single digits are the norm across every major proof-of-work and proof-of-stake network today.
Where can I compute it for a specific chain?
Use our Nakamoto Coefficient tool, which pulls live validator and stake data and explains exactly which resource it measured.
Sources & methodology
- Balaji S. Srinivasan — Quantifying Decentralization — the original definition of the metric.
- W3D methodology + academy dataset — our entity-collapsing and share-weighting algorithm.
Related terms
Nakamoto Coefficient (definition) · Validator · Staking · MEV-Boost
Chain audits: Ethereum · Solana · tool: Nakamoto Coefficient tool