Nakamoto Coefficient Calculator

The Nakamoto coefficient answers one question about any blockchain: how many entities would have to collude to compromise it? This calculator takes the share distribution of miners, validators or stakeholders, an adjustable control threshold, and returns that number, with a cumulative breakdown showing exactly which entities cross the line and a plain-English reading of what the result means.

Quick Answer

How to use the Nakamoto coefficient calculator

Three inputs, one click, one headline number plus the cumulative arithmetic behind it. The results stay hidden until you calculate.

1. Enter the number of entities: how many miners, validators or stakeholders hold a share. The calculator checks this count against your list, so a mismatch gets a specific error instead of a wrong answer. 5 is pre-filled.
2. Set the control threshold: 51% is the default and the classic majority line. Drop it to 33.4% for proof-of-stake liveness analysis or raise it to 66.7% for BFT safety analysis.
3. List each entity’s shares, comma-separated: hash rate, stake or voting power. Raw numbers are fine (the tool converts them to percentages); the worked example uses “30, 25, 20, 15, 10”.
4. Read the breakdown table: entities sorted largest-first, each row’s share and the running cumulative total, with the row that crosses your threshold marked. Copy or Share buttons save the results.

Blank fields, non-numeric inputs or a share count that does not match the entity count all produce an explanatory message rather than a number. Reset restores the worked example.

The Nakamoto coefficient formula

Sort every entity by share of control from largest to smallest, add shares until the running total reaches or exceeds the threshold, and count how many entities that took. That count is the coefficient.

The concept comes from Balaji Srinivasan and Leland Lee’s 2017 essay Quantifying Decentralization, which proposed the minimum Nakamoto coefficient, the lowest value across a system’s essential subsystems, as a quantitative measure of decentralization. The name honors Satoshi Nakamoto; the metric itself was not created by Satoshi. Note the essay’s nuance that most dashboards skip: a chain can look decentralized at the validator layer and centralized at the client or exchange layer, and the honest number is the weakest of them.

Worked example: five mining pools, checked by hand

The pre-filled example uses five pools with hash rates of 30, 25, 20, 15 and 10 at the 51% threshold. Running it gives a coefficient of 2, and the breakdown table shows why.

A flatter distribution, six entities with shares “20, 20, 15, 15, 15, 15” at 51%, gives a coefficient of 3: the cumulative totals run 20%, 40%, 55%. And the threshold matters as much as the distribution: run the original five pools at the 33.4% BFT liveness threshold and the coefficient is still 2 (30% then 55%), while at 66.7% it becomes 3 (30%, 55%, 75%). Try all three in the calculator and watch the “Counts” column move.

Which threshold should you use?

The right threshold depends on what failure you are modeling. The calculator accepts any value, but these three cover nearly every real analysis.

Proof of work vs proof of stake

The arithmetic is identical; the resource being measured is not. In proof-of-work systems like Bitcoin, entities are mining pools and shares are hash rate, usually taken from pool statistics or block explorers. In proof-of-stake systems, entities are validators or staking operators and shares are staked tokens. A real-time view of the proof-of-stake side is available from trackers such as Nakaflow, which publishes live coefficients across chains. One subtlety the raw number hides: staking pools can look decentralized by validator count while a few operators run most of the validators, which is why operator-level shares are the honest input, not raw validator counts.

What competing calculators miss

Most Nakamoto coefficient tools compute the number and stop. That leaves the interesting questions unanswered:

• Fixed-threshold tools: the best-known competing calculator hardcodes a 50% threshold and takes only a share list. It cannot answer the 33.4% liveness question or the 66.7% finality question, which are the thresholds proof-of-stake analysts actually argue about.
• No input validation: several tools accept a share list with no entity count to check it against, so a mistyped list silently produces a wrong coefficient. This calculator cross-checks the count and tells you when it does not match.
• No breakdown: a bare number does not show which entities crossed the line or how close the next entity was. The cumulative table here shows the running total at every step, which is where the insight lives.
• Live dashboards: trackers publish real coefficients for real chains but do not let you test your own hypotheticals, model a merger of two pools, or try a different threshold. That is the gap this page fills: your numbers, your threshold, the full arithmetic.

What the coefficient does not tell you

A single number is a simplification, and honest use means knowing its edges. The metric is gameable: one operator can split into shell entities that look independent, so a coefficient computed from pool labels overstates decentralization when operators hide. It says nothing about governance, client diversity, geographic concentration or node hardware requirements. And it is only as honest as the subsystem you feed it: per the original definition, a chain with 50 independent validators but one dominant client implementation has an effective coefficient of 1, not 50. For a related concentration measure from economics, the market concentration ratio calculator applies the same largest-first logic to industry market shares, and the bitcoin premium calculator covers Bitcoin pricing from a different angle. For blockchain-asset returns rather than network concentration, the NFT profit calculator works through NFT buy-and-sell math.

Frequently asked questions

Add This Calculator to Your Website

References