Three exchange listings sit side by side on your screen. One coin runs on “Proof of Staked Authority”, the next on “Delegated Proof of Stake”, the third on plain proof of stake. Which one is safer? The labels will not tell you. What tells you is who can stop the chain, who can rewrite it and what a cheater loses, and on those three questions two chains with the same label can give very different answers.
That is why a comparison has to go further than proof of work vs proof of stake. The short version, work spent against coins locked, is where every comparison starts, and it is the first section below. Then come the designs that rarely fit in a two-column chart: elected producers, approved signers, enterprise orderers, trust lists, random sampling and the chains that changed their engine while the textbooks were still in print.
Several of the textbook examples are out of date. VeChain, the classic proof-of-authority example, moved to delegated proof of stake in December 2025. Polkadot stopped slashing its nominators on 6 July 2026. Solana’s proof of history left consensus on 21 October 2026. Hyperledger Fabric, often filed under PBFT, dropped that engine after its 2016 previews and now offers Raft or a newer BFT orderer. Any answer to “which consensus does this chain use?” needs a date, and every table in this lesson carries one.
Six questions that separate one consensus mechanism from another
If the vocabulary is new, two earlier lessons set it up: what a consensus mechanism is and its five main families, including safety and liveness, and the Byzantine generals problem and the one-third limit behind voting protocols. This lesson assumes both and puts real chains next to each other.
The comparison uses six axes. None of them produces a ranking, because each design buys one property by giving up another.
- The price of a vote: electricity, locked coins, the backing of other holders, a legal identity or a place on someone’s trust list.
- The security assumption: the share of hashrate, stake or validators that must stay honest for the history to hold.
- Finality: whether a payment becomes harder to reverse over time, final after a vote, or final as soon as an orderer places it.
- The failure mode: what happens when the assumption breaks. Some chains keep producing blocks that could later be rewritten; others stop.
- Energy: the electricity the design needs by construction, which is not the same thing as the electricity per payment.
- Concentration: how many independent parties would have to cooperate to halt or rewrite the chain, measured by the Nakamoto coefficient and by client software shares.
The fourth axis is the one most comparisons leave out, and for a holder it is often the most practical. A chain that halts loses no money but stops your withdrawals; a chain that keeps running while a majority misbehaves keeps your withdrawals open but may reorder recent history.
The comparison table: thirteen chains on the same axes
The table reads each chain’s own documentation, as of 8 November 2026. The last column gives the Nakamoto coefficient published by the analytics site Chainspect, which defines it as the minimum number of validators or miners that must collude to disrupt a network. Chainspect’s page carries no date, so those figures are a snapshot read on 8 November 2026, and other trackers count differently (more on that further down).
| Chain | Mechanism | Who produces and votes | When a block is final | What breaks it | Energy by design | Nakamoto coefficient (Chainspect, read 8 Nov 2026) |
|---|---|---|---|---|---|---|
| Bitcoin | Proof of work (SHA-256) | Miners, grouped in pools | Never absolutely: harder to reverse with each block | A majority of hashrate can rewrite recent blocks; the chain keeps running | About 138 TWh a year (Cambridge, April 2025) | 3 (175 miners counted) |
| Ethereum | Proof of stake (Gasper) | Validators with 32 ETH or more | Checkpoint finality, about two epochs | More than a third offline stalls finality; blocks continue | About 0.0026 TWh a year (CCRI via ethereum.org) | 5 |
| Solana | Stake-weighted voting, Alpenglow’s Votor since 21 Oct 2026 | Validators, a scheduled leader per slot | After one round at 80% of stake or two at 60% | Designed for 20% malicious plus 20% offline stake | No mining | 17 (664 validators) |
| BNB Smart Chain | Proof of Staked Authority | 45 active validators (21 Cabinet, 24 Candidates) | Within two blocks if two-thirds vote normally | Coordination among a few dozen operators | No mining | 7 (45) |
| TRON | Delegated proof of stake | 27 Super Representatives | Solidified once 19 of the 27 have built on it, usually about a minute | Coordination among elected producers | No mining | 14 (27) |
| Vaulta (formerly EOS) | Delegated proof of stake with a BFT layer | 21 elected block producers | Irreversible at 15 of 21 confirmations, about 1-2 s | Coordination among elected producers | No mining | Not listed |
| Polkadot | Nominated proof of stake (BABE, GRANDPA) | Validators backed by nominators | GRANDPA finality votes | Validators slashable; nominators no longer, since 6 Jul 2026 | No mining | 182 (600) |
| Cardano | Proof of stake (Ouroboros Praos) | Stake pools, picked as slot leaders by stake | Probabilistic: immutable once buried deep enough | An attacker with a majority of stake | No mining | 15 (2,069 pools) |
| Avalanche | Snowman, repeated random sampling | Validators with at least 2,000 AVAX | Within a few seconds, per the docs | Parameters trade safety against liveness; no slashing | No mining | 24 (555) |
| XRP Ledger | Federated consensus on trust lists | Validators on each server’s UNL | Three to six seconds per ledger | Stops between 20% and 80% faulty trusted validators | No mining | Not listed |
| Stellar | Stellar Consensus Protocol | Validators choosing their own quorum sets | Once a ballot is confirmed | Can get stuck rather than fork | No mining | Not listed |
| Hyperledger Fabric | Raft or SmartBFT ordering | Known, permissioned orderers | Once ordered and committed | Raft: crashes only; BFT: up to but not including a third | No mining | Permissioned |
| Ethereum Sepolia testnet | Proof of stake with a permissioned validator set | Validators controlled by client and testing teams | As on Ethereum | The operating teams | No mining | Permissioned |
Two rows deserve an explanation before anyone compares them. The Bitcoin coefficient of 3 counts mining pools, which are coordinators of thousands of machines owned by others, not single owners. And Sepolia appears because ethereum.org’s networks page describes its validator set as “controlled by client & testing teams”: a test network is where permissioned validation is most openly accepted.
Proof of work vs proof of stake: what each one makes an attacker pay
The two biggest chains settle the same question with two kinds of money. Proof of work, taken apart in its own lesson, makes block producers burn electricity on hashing hardware. Proof of stake, also taken apart in its own lesson, makes them lock coins the protocol can destroy. Everything else in the proof of work vs proof of stake debate follows from that difference.
Spent money against money at risk
In proof of work the cost of attacking is paid every day, by everyone. As of 8 November 2026 at about 09:45 UTC, mempool.space estimated Bitcoin’s three-day average hashrate at about 1,001 exahashes per second, with difficulty near 148.36 trillion. An attacker would need to match a large share of that computing power with machines and power contracts of their own. The money is spent whether the attack works or not, and the hardware keeps its value only if Bitcoin does.
The power to rewrite is concentrated in fewer hands than the miner count suggests. Over the week to 8 November 2026 (936 blocks, read at 09:55 UTC), mempool.space’s pool data credited Foundry USA with 24.1% of blocks, AntPool with 19.0% and F2Pool with 18.2%. Three pools together found 61.3%; two found 43.2%. That is the arithmetic behind Chainspect’s coefficient of 3. The miners inside those pools can switch smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool in minutes, which is the main check on them.
Staking moves the cost from the electricity meter to the balance sheet. A validator who signs two conflicting blocks loses part of the deposit, and the penalty grows when many validators misbehave at once; our lesson on validators, slashing and rewards gives the numbers. On Ethereum, reverting a block that has been finalised would cost the attacker at least a third of all staked ether, according to ethereum.org. Nothing has to be burned day after day, but the attacker must first buy, borrow or control a large share of the coin being attacked, and would destroy much of it in the process.
Each design has a weak spot the other does not. Proof of work lets a rented or outside source of hashrate attack a small coin that shares its hashing algorithm with a bigger one. Proof of stake has to defend against old keys signing an alternative past, which is why new Ethereum nodes start from a recent trusted checkpoint, a point covered in the proof of stake lesson.
Three meanings of “final”
A Bitcoin payment never becomes absolutely final; each block on top makes undoing it more expensive, and the receiver decides how many to wait for. An Ethereum payment becomes final when two-thirds of staked ether has voted for the checkpoint above it. A Fabric transaction or a CometBFT block is final the moment it is ordered and committed, because the protocol forbids any conflicting block after that. The finality and reorganisations lesson compares the waiting times chain by chain.
Energy per transaction is a misleading number
The electricity gap is real and large: about 138 terawatt-hours a year for Bitcoin in the Cambridge Centre for Alternative Finance study of April 2025, against about 2,601 megawatt-hours for Ethereum since the Merge in the estimate the ethereum.org energy page cites. The introductory lesson sets out where those figures come from; other estimators publish other numbers for Bitcoin, sometimes tens of terawatt-hours apart. The question here is what such totals can and cannot be compared with.
Dividing those totals by the number of transactions gives a striking figure, and a weak one. Bitcoin’s electricity buys hashrate, not throughput: adding machines raises consumption without adding a single transaction, and a quiet day uses about as much power as a busy one. Cambridge’s own index measures hardware efficiency in joules per terahash, not per payment. One transaction can also settle many payments at once, as batched exchange withdrawals and Lightning channel closures do. A guest post in Bitcoin Magazine from January 2022, an openly pro-Bitcoin outlet, built its case against the metric on these points.
The opposite point stands as well. That throughput is fixed does not make the energy free: the total is the price of the security model, and it rises with hashrate. The useful figures are the annual total, the share of global electricity and the cost an attacker would face, not a per-transaction number.
European law nevertheless asks for it. Commission Delegated Regulation (EU) 2025/422, published in the Official Journal on 31 March 2025, sets the sustainability indicators that MiCA white papers and service providers must publish about a crypto-asset’s consensus mechanism. Total annual energy in kilowatt-hours is mandatory. Above 500,000 kWh a year, extra indicators include the renewable share, energy per validated transaction and greenhouse gas emissions per validated transaction. What counts as one validated transaction, a rollup batch or the thousands of payments inside it, is left to whoever fills in the form.
Delegated proof of stake: speed bought with a short list of producers
Delegated systems keep stake as the source of power but let holders elect a small group to do the work. The delegated proof of stake lesson tells the history, from BitShares to EOS, and the vote-buying critiques. For a comparison, three numbers say most of it: 21, 27 and 45.
EOS, renamed Vaulta in 2025, has 21 active block producers. Token holders vote for up to 30 candidates with weight proportional to the tokens they stake, and a block becomes irreversible once 15 of the 21 have confirmed it, typically within one to two seconds, according to the Vaulta guides. TRON elects 27 Super Representatives, and its developer documentation counts a transaction as solidified once at least 19 distinct active Super Representatives have produced blocks on top of it. BNB Smart Chain’s Proof of Staked Authority runs 45 active validators.
Those numbers explain both the speed and the risk. Fifteen Vaulta producers can make a block irreversible in a second or two; TRON’s documentation says its 19-producer rule usually takes about a minute. Either way the operators are known companies, reachable by a court or a regulator. In the DPoS designs, a holder’s protection is the vote: an operator who misbehaves can be voted out at the next election, as long as enough holders pay attention.
Polkadot’s nominated proof of stake changed its rules in 2026
Polkadot looks similar on paper and behaves differently. Holders, called nominators, back validators they trust, and an election run with the Phragmén method spreads their stake to give the elected set as even a backing as possible. The Polkadot wiki says up to 22,500 nominators can take part in that election. Chainspect counted 600 validators and gave Polkadot a coefficient of 182, by far the highest in its table.
The risk-sharing changed this year. Referendum 1910, passed on chain and announced as enacted on 6 July 2026, removed slashing for nominators and cut their unbonding period from 28 days to about two days, according to the referendum page on Polkassembly and the Polkadot forum announcement. Validators remain slashable, and a companion referendum, 1909, made them keep a slashable stake of their own, set at 10,000 DOT in the plan the Polkadot team published on the forum in February 2026. Unbonding requests opened before 6 July keep the old 28 days. Older guides that warn Polkadot nominators about slashing are now out of date.
Proof of authority: when knowing who signs is the point
In proof of authority, a vote costs neither electricity nor coins. It costs a reputation: the signers are named in advance, and an outsider cannot join without the existing group’s approval. That makes it unsuitable for an open currency and well suited to two uses, test networks and business consortia.
Clique, Goerli and the testnets
Ethereum’s own proof-of-authority engine is Clique, specified in EIP-225 by Péter Szilágyi on 6 March 2017. The signer list sits in the genesis block and changes by a vote of the current signers; each signer may sign at most one block in any run of floor(N/2)+1 consecutive blocks, so a single rogue signer cannot fill the chain alone. The Rinkeby testnet ran Clique from April 2017.
Goerli followed. Its repository describes it as “the first proof-of-authority cross-client testnet”, born in September 2018 at ETHBerlin and run on Clique, before it merged with the Prater proof-of-stake beacon chain, which opened validation to everyone, according to the Goerli testnet repository. Goerli is now deprecated. Ethereum’s current testnets use proof of stake: Sepolia with a permissioned validator set, Hoodi with an open one.
VeChain left proof of authority; BNB Smart Chain mixes it with stake
VeChain was for years the standard proof-of-authority example in comparison charts. That ended in December 2025, when its Hayabusa upgrade moved VeChainThor to delegated proof of stake. VeChain’s own announcement page credits the old design with 100% uptime since launch; under the new one, a validator must self-bond 25 million VET, and Decrypt reported on 9 December 2025 that validation had become public and permissionless.
BNB Smart Chain kept the authority idea and attached stake to it, hence the name Proof of Staked Authority. Validators are elected by staked BNB, then take turns as known operators. That puts it between delegated stake and authority, which is why charts file it under either.
Enterprise ledgers: from PBFT to Raft and SmartBFT
Comparison charts often list “PBFT (Hyperledger)”. The algorithm is Practical Byzantine Fault Tolerance, published by Miguel Castro and Barbara Liskov at OSDI 1999: with 3f+1 replicas it tolerates f arbitrary faults, and the authors’ replicated file service ran only 3% slower than an unreplicated one. Hyperledger Fabric did ship it, in its early preview code: the v0.6.1 release of October 2016 has a PBFT package whose default configuration tolerates one Byzantine node out of four, per the Fabric repository.
Today’s Fabric is built differently. Transactions are executed by peers, then put in order by a separate ordering service, and that service runs Raft or SmartBFT, according to the Fabric documentation. Raft, added in version 1.4.1, survives crashed nodes but not lying ones; it needs 2F+1 nodes, at least three and five recommended. SmartBFT, added in version 3.0 in September 2024, needs 3F+1, at least four and seven recommended, and tolerates up to but not including a third of orderers acting maliciously, per the LF Decentralized Trust blog. Kafka ordering is no longer supported in 3.x. The BFT lesson on Tendermint and HotStuff explains the voting rounds these protocols share.
None of this is about Sybil resistance. A permissioned ledger knows every member by contract, so the consensus only has to cope with crashes or with a minority of misbehaving members, not with strangers.
XRP Ledger and Stellar: agreement through trust lists
Two payment networks from the 2010s neither mine nor stake. On the XRP Ledger, each server picks a Unique Node List of validators it expects not to collude. The documentation sets the thresholds: the network keeps working with fewer than 20% of trusted validators faulty, would need more than 80% colluding to confirm an invalid transaction, and stops making progress in between. A ledger usually settles in three to six seconds. No block reward exists, so running a validator brings no income, and the question “who is on the list” replaces the question “who has the most hashrate”.
Stellar generalises the idea. In the Stellar Consensus Protocol, designed by David Mazières, every validator chooses its own quorum set, the validators it listens to and how many of them must agree. Overlapping choices link those sets into network-wide agreement, built in two stages: a nomination protocol proposes candidate values, then a ballot protocol votes on them. Stellar’s documentation is explicit about the trade-off: the protocol puts safety ahead of liveness, so the network can stall rather than fork.
Avalanche consensus: reaching agreement by polling twenty validators
Avalanche gets to agreement by sampling rather than by everyone voting. A validator asks a small random sample of others, weighted by stake, which block they prefer. If enough answer the same way, it leans that way; once it has seen the same result enough times in a row, it decides. The Avalanche documentation gives the default parameters: samples of k = 20 validators, a quorum of alpha = 15 matching answers, and beta = 20 consecutive successful polls to decide.
The family was introduced in an anonymous May 2018 paper signed Team Rocket, later revised on arXiv in June 2019 as “Scalable and Probabilistic Leaderless BFT Consensus through Metastability”, with Maofan Yin, Kevin Sekniqi, Robbert van Renesse and Emin Gün Sirer named alongside Team Rocket. Its steps go from Slush to Snowflake to Snowball, and the chains of Avalanche’s primary network run Snowman, the version for a linear chain, where a vote for a block also counts for its ancestors.
Three features stand apart in the big table. The message load per poll stays constant as the validator set grows, which lets Avalanche accept many validators. There is no slashing: the staking documentation says poor performance costs rewards, not stake. And the entry ticket is fixed in tokens, at least 2,000 AVAX for a validator and 25 AVAX for a delegator. The consensus page says acceptance is final and irreversible and takes only a few seconds, while also calling Snowman probabilistically safe up to a threshold: final in practice, with a failure probability set by the parameters.
Solana: proof of history was a clock, and Votor now does the voting
Comparison charts still list Solana under “proof of history”. The previous lesson on Solana’s proof of history explains why that label was always partial: the hash chain served as a clock to order events, while a stake-weighted vote, Tower BFT, did the consensus.
Since 21 October 2026, Solana’s consensus is Alpenglow’s voting part, Votor. Alpenglow’s feature gate activated at slot 459,648,000, the first slot of epoch 1064, at 13:36 UTC that day, as the feature account on Solana mainnet shows. The hand-off itself came later: the migration proposal, SIMD-0384, sets the switch point 5,000 slots after the gate and lets validators move over once 82% of stake has signed a common starting block. The Alpenglow proposal replaces both proof of history and Tower BFT in consensus, using locally measured timeouts in place of the clock. What remains of the hash chain is a vestige: SIMD-0384 switches the tick producer to one hash per tick and keeps a single tick at the end of each block, for the software that packs and broadcasts it. Slots had already been cut to a 200-millisecond target in October 2026 under SIMD-0525, activated through its own feature accounts; since Alpenglow, each validator’s local timeouts, not the hash chain, decide when a silent leader is skipped.
Not all of Alpenglow is live. SIMD-0326 covers Votor, which finalises a block after one round of voting at 80% of stake or two rounds at 60%, and keeps Turbine for spreading blocks across the network: “Rotor will be introduced later and will get its own SIMD.” As of 8 November 2026 Rotor was not live on mainnet, and the finality of about 150 milliseconds that Anza announced remains a design target rather than a published measurement. For the comparison table, Solana belongs with the stake-weighted BFT designs, with the unusual 20% malicious plus 20% offline tolerance its proposal chose over the classic one-third.
Proof of space and time, and proof of burn: the minor families
Chia replaces computing with disk space. Farmers fill drives with precomputed data and win blocks in proportion to the space they hold, so 500 GiB has five times the chance of 100 GiB, while a verifiable delay function proves that real time has passed between blocks, according to the Chia documentation. The scarce resource is storage hardware rather than electricity.
Burning is the other minor route: proof of burn makes participants destroy coins of another chain. Counterparty used it in its simplest form, to distribute its XCP token: from 2 January to 3 February 2014, anyone could send bitcoin to a provably unspendable address and receive between 1,000 and 1,500 XCP per BTC, with at most 1 BTC per address, per the Counterparty documentation. No founder pre-mine was needed. Few chains have used burning as an ongoing consensus mechanism.
Measuring decentralisation: Nakamoto coefficient, client diversity and validator counts
A validator count is the easiest number to publish and the least informative. One company can run thousands of validators; ten thousand small holders can delegate to the same three operators. The Nakamoto coefficient answers a better question: how many independent parties would it take to stop or rewrite the chain?
| Chain | Nakamoto coefficient | Validators or miners counted |
|---|---|---|
| Polkadot | 182 | 600 |
| TON | 63 | 285 |
| Avalanche | 24 | 555 |
| Solana | 17 | 664 |
| Sui | 17 | 125 |
| Cardano | 15 | 2,069 pools |
| TRON | 14 | 27 |
| BNB Chain | 7 | 45 |
| Ethereum | 5 | 814,011 (validator entries, not operators) |
| Bitcoin | 3 | 175 miners |
Treat these numbers as one method, not as truths. The coefficient depends on how a site groups entities: pools or miners on Bitcoin, staking providers or individual keys on Ethereum, voting power or stake elsewhere. Other trackers publish different values for the same chains, sometimes double or half. A high Polkadot figure partly reflects the Phragmén election, designed to spread backing evenly; a low Bitcoin figure reflects pools that miners can leave at any moment. The ranking says where coordination would be easiest, not which chain is safest.
Ethereum adds a second measure: client diversity. Validators run different software clients, and a bug in one with a large share can do damage proportional to that share. The ethereum.org client diversity page says ideally no consensus client should reach a third of nodes, because a bug in a client above two-thirds could make a faulty chain final. Its own snapshot, dated October 2025, put Lighthouse at 42.7% of consensus clients, while the community dashboard clientdiversity.org showed conflicting datasets on 8 November 2026 and warned that several were stale. No single current number is reliable; the thresholds are.
Bitcoin has a version of the same issue, since most nodes run Bitcoin Core, but a bug there would show up as a split between node versions rather than as a finality failure. Proof-of-work and federated chains have no slashing to amplify a client bug; proof-of-stake chains do.
Choosing without a ranking: what to check before trusting a chain
No consensus mechanism wins every column, and the label on a listing tells you less than five plain checks.
- Find the project’s own consensus page and its date. VeChain, Polkadot and Solana all changed rules within the last twelve months.
- Count who produces blocks and who could halt the chain: 21, 27 or 45 known operators carry a different risk from thousands of anonymous ones.
- Note when the network treats a payment as final, and how long your exchange waits before crediting a deposit.
- Read how the chain behaved on its worst day: did it stop, lose finality or reorganise?
- If you stake, check who can be slashed and how long unbonding takes. Since July 2026 the answer for a Polkadot nominator is nobody and about two days.
The mechanism also decides how a holder earns from a network, through mining or staking, and the legal side of that, from the SEC staff statements of 2025 to the IRS treatment of rewards as income, is covered in the introductory consensus lesson. In the European Union, the MiCA sustainability indicators described above appear in white papers and on the websites of licensed providers; our guide to MiCA covers the rest of the regulation. None of this says whether any coin is worth buying.
The next lesson of this path, on MEV, looks at the power that every design on this page hands to whoever orders transactions in a block, and how that power is sold.
