Send bitcoin to a friend and no bank stamps the payment. Within about ten minutes on average, thousands of independent computers on several continents accept that your payment came before any other attempt to spend the same coins. Nobody chairs a meeting and nobody counts hands. The set of rules that makes those machines end up with the same answer is called a consensus mechanism. Every public blockchain has one, and they do not all work the same way.
Satoshi Nakamoto summed up Bitcoin’s choice in one short sentence in the 2008 white paper: “Proof-of-work is essentially one-CPU-one-vote.” Other networks made other choices. Ethereum replaced its computing race with votes weighted by staked ether on 15 September 2022. Solana swapped its whole voting engine for a new protocol, Alpenglow, on 21 October 2026, seventeen days before this lesson was written. Consensus is not a finished invention that every chain copies once. Chains keep revisiting it, because the choice decides how fast a payment becomes final, how much electricity a network burns and what happens on a bad day.
Strangers keeping one ledger: the problem a consensus mechanism solves
In the previous lesson, how a blockchain works, we followed transactions from the waiting 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 into a block, saw each block point to the one before it through a hash, and looked at what happens when two valid blocks appear at the same moment. That last question, which chain everyone keeps, is where consensus starts. The rules behind that answer are the subject of this first lesson of the consensus and mining path.
The reason the question matters is money that can be copied. A digital coin is only data, and data can be sent twice. Without a single agreed history, the same coins could pay two people. That is the double-spending problem, and consensus is the answer public blockchains give to it without a bank in the middle.
In plain words: a consensus mechanism is the method by which the computers of a network, which do not know or trust each other, agree on one list of transactions in one order. European law has its own wording. The Markets in Crypto-Assets Regulation (MiCA, Regulation (EU) 2023/1114) defines it in Article 3 as “the rules and procedures by which an agreement is reached, among DLT network nodes, that a transaction is validated”. The wording matters to readers in Europe, because MiCA ties climate disclosures to the consensus mechanism of every crypto-asset an exchange lists.
Developers tend to use a wider frame. The ethereum.org documentation says the term covers “the entire stack of protocols, incentives and ideas” that lets nodes agree on the state of a blockchain, and it treats proof of work or proof of stake as only one part of that stack. In this wider view, economic rewards and penalties count, and so does what the page calls “out-of-band social coordination”, people agreeing outside the software when something goes badly wrong.
What a consensus mechanism decides, and what it leaves to governance
Beginners often imagine miners or validators voting on everything. They do not. Consensus settles two narrow questions, and a third, larger question belongs to people.
Two decisions: the order of transactions and who writes the next block
The first decision is order. If Alice signs two transactions that spend the same coins, the network needs to know which came first, because only that one counts. Bitcoin’s white paper answers with a rule for choosing between competing histories: “The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.” Longest here means the chain with the most accumulated work, not the one with the most blocks, and Bitcoin Core follows that most-work rule today. Our walk through the Bitcoin white paper, section by section covers the rest of the text.
Ethereum uses a different rule. Its fork choice, part of a design called Gasper, picks the branch that has the heaviest weight of validator votes behind it, each vote weighted by the ether its author has staked. The two rules answer the same question, which chain is the right one, with different evidence: work spent in one case, money at stake in the other.
The second decision is the writer. Someone has to propose the next block. In proof of work, the writer is whoever first finds a valid hash, so the choice is a lottery weighted by computing power. In proof of stake, the protocol picks a validator for each time slot, pseudo-randomly and in proportion to stake. In voting-based designs, a leader proposes and the others sign or refuse.
Miners and validators do not vote on the rules
What counts as a valid transaction is not decided by consensus at all. Every full node checks every block against the same consensus rules: signatures must be valid, coins must exist and not be spent already, the block reward must not exceed what the protocol allows. A miner who spends a fortune of electricity on a block that breaks one of those rules gets nothing, because every node rejects the block. Our guide to what a node does shows that checking job in detail.
So the power of block producers is real but limited. They choose which valid transactions go in and in what order. They can delay a transaction or leave it out. They cannot make an invalid transaction valid, and they cannot create coins beyond the issuance schedule.
Changing the rules is a matter of governance, and on most large chains it happens off-chain. Bitcoin changes go through improvement proposals (BIPs) and client releases. Ethereum changes go through EIPs, public developer calls and testnet rehearsals; the ethereum.org governance page notes that node operators can choose not to run the latest client. Some other chains put rule changes to on-chain votes of token holders. When a rule change is not accepted by everyone, the chain can split, which is the subject of our lesson on soft forks, hard forks and chain splits.
Sybil resistance: why a vote has to cost something
On the open internet, creating a fake identity is free. If each computer, or each IP address, got one vote, an attacker could spin up a million identities and outvote everyone. Computer scientists call this a Sybil attack. Nakamoto saw it: “If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs.”
Every public consensus mechanism therefore attaches a price to a vote. In proof of work the price is electricity and hardware, spent and gone. In proof of stake it is coins locked as collateral that the protocol can destroy if their owner cheats. In delegated systems it is the backing of token holders, and in proof of authority it is a real-world identity and reputation. Most differences between chains come down to which price they chose.
Safety and liveness: the trade-off behind every design
Two words from distributed-systems research explain most of the differences between designs. Safety means the network never gives two different answers: two honest nodes never end up with conflicting histories. Liveness means the network keeps giving answers: new transactions keep being added. Under ideal conditions a chain has both. When many nodes go offline or misbehave, or the internet splits in two, a design has to lean one way.
Bitcoin leans towards liveness. Blocks keep coming whatever happens, and safety is probabilistic: a recent block could in theory be replaced by a longer competing chain, but the odds fall quickly with each block added on top. That is why exchanges wait for several confirmations.
Ethereum mixes the two. Blocks keep arriving every 12 seconds even in trouble, but a block becomes final only when validators holding at least two-thirds of the staked ether have voted for it, according to the ethereum.org proof-of-stake page. If more than a third go silent, finality pauses while blocks continue. If the pause lasts more than four epochs, an inactivity leak slowly drains the stake of the absent validators until the active ones are back above two-thirds.
Classic voting protocols lean towards safety. The CometBFT documentation, the engine of many Cosmos chains, says validators will never commit conflicting blocks as long as fewer than a third of them are faulty or malicious, and that progress needs more than two-thirds of them to respond. If too many are offline, the chain stops rather than risk two histories. The XRP Ledger documentation sets out a similar logic with its own thresholds: the network keeps working with fewer than 20 percent of trusted validators faulty, stops making progress somewhere between 20 and 80 percent, and would need more than 80 percent colluding to confirm an invalid transaction.
Solana’s new protocol states its own balance. The Alpenglow proposal, SIMD-0326, says the design “features a distinctive 20+20 security model”: it is meant to cope with up to 20 percent of stake acting maliciously plus another 20 percent simply offline. The proposal admits the price: it gives up the one-third Byzantine tolerance of two-round voting protocols in exchange for single-round finality and 40 percent resilience to crashed validators.
Why can’t a design have perfect safety and perfect liveness at once? The theory behind that limit goes back to the Byzantine generals problem and to a 1985 impossibility result known as FLP, both covered in the next lesson of this path. For now, the practical point is enough: when you read that a chain “halted”, it probably chose safety; when you read that it “lost finality but kept producing blocks”, it chose liveness for a while.
The main families of consensus, from mining to voting
Hundreds of variants exist, but most public chains fit one of five families, plus a few special cases. The labels overlap in places: many modern proof-of-stake chains use BFT-style voting inside, and delegated proof of stake is a branch of proof of stake.
Proof of work: votes paid in electricity
Under proof of work, miners repeatedly hash a candidate block header until the result falls below a target set by the protocol. Finding such a hash takes an enormous number of attempts; checking it takes one. Bitcoin adjusts the target every 2,016 blocks so that blocks keep arriving about every ten minutes whatever the total computing power.
That computing power is large. As of 7 November 2026 (read at about 09:47 UTC), mempool.space estimated Bitcoin’s three-day average hashrate at about 1,014 exahashes per second, just over one zettahash, with difficulty near 148.36 trillion at block height 974,916. Over the previous week, two pools, Foundry USA (23.1 percent) and AntPool (19.7 percent), found about 43 percent of blocks, according to mempool.space mining data. A pool is not a single miner: it coordinates thousands of machines owned by others, and the Bitcoin mining guide later in this path explains how they split the reward.
The security argument is economic. Rewriting recent history means out-computing the rest of the network, which costs real electricity and hardware. Our lesson on why a blockchain is hard to rewrite puts a price on that. Bitcoin hashes with SHA-256. Litecoin and Dogecoin use a memory-hungry function called Scrypt, and Monero has used RandomX, which its developers describe as optimised for ordinary processors, since a network upgrade in November 2019. The lesson proof of work in depth, two steps further in this path, takes the mechanism apart.
Proof of stake: votes paid in locked coins
With proof of stake, the right to propose and vote on blocks comes from coins deposited as collateral. On Ethereum, a validator deposits at least 32 ETH. Time is cut into 12-second slots grouped in epochs of 32 slots; in each slot one validator proposes a block and a committee attests to it. A checkpoint at the start of each epoch becomes final once validators holding two-thirds of the staked ether back it, which in normal conditions takes about two epochs, roughly 13 minutes.
Cheating is punished by slashing. Signing two conflicting blocks, for example, destroys part of the validator’s deposit: less than 0.1 percent for a single isolated case and up to the whole stake when many validators misbehave together, according to ethereum.org. Reverting a finalized block would require an attacker to lose at least a third of all staked ether. Ordinary holders take part through staking, directly or through a service, which is why the share held by large staking providers is watched closely.
Cardano, Polkadot and many others also use proof of stake under different names. Cardano runs Ouroboros, which Cardano’s own documentation calls “the first provably secure proof-of-stake protocol”, a claim based on the project’s peer-reviewed security proofs. Polkadot uses nominated proof of stake, with one mechanism (BABE) producing blocks and another (GRANDPA) finalising them, per its official wiki. The later lesson proof of stake in depth covers validators, rewards and penalties step by step.
BFT-style voting: rounds of signed votes and immediate finality
Byzantine fault tolerant (BFT) protocols come from decades of research on keeping a group of machines in agreement when some of them lie. A leader proposes a block, validators exchange signed votes in one or more rounds, and once enough votes are collected the block is final at once: there is no “wait six blocks”. In public chains the votes are weighted by stake, so BFT voting usually sits inside a proof-of-stake system. CometBFT, for example, commits a block when more than two-thirds of validators pre-commit to it in the same round.
Solana’s Alpenglow, live on mainnet since 21 October 2026, belongs here. Its voting component, Votor, finalises a block in a single round when 80 percent of stake votes for it, or in two rounds of 60 percent otherwise, according to SIMD-0326. The developer firm Anza says on its Alpenglow documentation page that the protocol targets finality in roughly 150 milliseconds under normal conditions; independent measurements since the switch had not been published as of 7 November 2026.
Avalanche is a cousin rather than a classic BFT design. Instead of every validator hearing from every other, each one repeatedly polls a small sample of validators, 20 by default, picked at random and weighted by stake, and adjusts its preference until the network settles, according to the Avalanche documentation. The family is called Snowball, and Avalanche’s main chains run its linear version, Snowman.
Delegated proof of stake: holders elect a small set of block producers
Delegated proof of stake keeps stake as the source of power but hands block production to a short list of elected operators. On TRON, holders stake TRX to obtain voting power, called TRON Power, and the 27 candidates with the most votes become Super Representatives; the network re-ranks candidates at each maintenance period, every six hours, according to the TRON developer documentation. BNB Smart Chain calls its variant Proof of Staked Authority. Its documentation describes an active set of 45 validators, 21 in a “Cabinet” and 24 “Candidates” that produce blocks less often, with a block every 0.45 seconds and finality within two blocks when at least two-thirds of validators vote normally.
The appeal is speed: a few dozen known operators can agree much faster than thousands of anonymous ones. The cost is concentration. When 27 or 45 entities produce every block, a handful of them coordinating, or a single regulator reaching them, matters far more than on a network with thousands of validators.
Proof of authority: known, approved signers
Here block production goes to a fixed list of approved signers who take turns, and their real-world identity is the stake. ethereum.org notes that the method is mostly used by private chains, testnets and local development networks; Clique, defined in EIP-225, and IBFT 2.0 are two implementations it names. A business consortium sharing a ledger, or a test network that must not be disrupted, can live with that trust in a few named parties. A public currency usually cannot. Our comparison of public and private blockchains shows where that trade-off is accepted.
Two special cases: the XRP Ledger’s trusted lists and Solana’s former clock
The XRP Ledger is neither proof of work nor proof of stake. Each server keeps a Unique Node List, a list of validators it trusts not to collude, and the ledger closes when enough overlapping trusted validators agree on the same set of transactions. No mining reward and no staking deposit is involved, which is why the answer to “is XRP proof of work or proof of stake?” is neither.
Solana long appeared in textbooks with “proof of history”. From its launch in 2020 until October 2026, Solana used proof of history as a cryptographic clock: a continuous chain of SHA-256 hashes that proved time had passed between events, so that leaders could order transactions without waiting for messages from everyone. It was never the consensus itself; a voting layer called Tower BFT did that job on top. Since 21 October 2026 the network runs Alpenglow’s Votor instead, which drops proof of history from consensus. In its place, SIMD-0326 uses local timeouts whose “purpose is akin to Proof-of-History, but without any notion of synchronized time.”
The table below sums up the families. It describes typical behaviour; individual chains tune the details.
| Family | What a vote costs | Who writes the next block | When a block is final | Typical failure |
|---|---|---|---|---|
| Proof of work | Electricity and hardware | Whoever first finds a valid hash | Probabilistic: safer with each block on top | A majority of hashrate could rewrite recent blocks; the chain keeps running |
| Proof of stake (Ethereum style) | Locked coins that can be slashed | A validator picked for each slot | Checkpoint finality with two-thirds of stake, about two epochs | Finality pauses if more than a third is offline; blocks continue |
| BFT voting (CometBFT, Alpenglow) | Stake, signed votes in rounds | A rotating leader | Immediately once the vote threshold is reached | Halts if too many validators are offline |
| Delegated proof of stake | Votes of token holders | A small elected set (27 on TRON, 45 on BNB Smart Chain) | Fast | Concentration among a few operators |
| Proof of authority | Identity and reputation | Approved signers | Fast | Everything rests on trust in a few known parties |
Which consensus mechanism each major chain uses
The table lists the mechanism of some of the largest networks as of 7 November 2026, from each project’s own documentation. Names change over time, as Solana’s switch shows, so check the date of any comparison you read.
| Chain | Family | Name and detail (as of 7 November 2026) |
|---|---|---|
| Bitcoin | Proof of work | SHA-256, most-work chain rule, difficulty retarget every 2,016 blocks |
| Ethereum | Proof of stake | Gasper (Casper FFG finality and a GHOST-based fork choice), since 15 September 2022 |
| Solana | Proof of stake with BFT voting | Alpenglow (Votor) since 21 October 2026; before that, Tower BFT with the proof-of-history clock |
| BNB Smart Chain | Delegated proof of stake and authority | Proof of Staked Authority, 45 validators in the active set (21 Cabinet, 24 Candidates) |
| XRP Ledger | Federated voting | Unique Node Lists of trusted validators; neither PoW nor PoS |
| Cardano | Proof of stake | Ouroboros, stake pools chosen as slot leaders |
| TRON | Delegated proof of stake | 27 Super Representatives elected with staked TRX |
| Avalanche | Proof of stake with subsampled voting | Snowman, from the Snowball family |
| Polkadot | Nominated proof of stake | BABE for block production, GRANDPA for finality |
| Cosmos chains | BFT voting weighted by stake | CometBFT, commit at more than two-thirds of pre-commits |
| Litecoin and Dogecoin | Proof of work | Scrypt; Dogecoin merge-mined with Litecoin since September 2014 |
| Monero | Proof of work | RandomX, optimised for ordinary processors, since 30 November 2019 |
Layer 2 networks such as rollups add a twist. A sequencer, often run by a single company, orders transactions on the rollup, but final settlement relies on Ethereum’s own consensus. A rollup payment can feel instant while its true finality depends on the chain underneath, as our guide to layer 1 and layer 2 networks explains.
Energy: what each kind of vote costs in electricity
The cost of a vote shows most clearly on the power bill. Proof of work turns electricity into security by design: the more energy miners spend, the more an attacker would have to spend. Proof of stake replaces that spending with capital at risk, so validators run on ordinary servers.
The Cambridge Centre for Alternative Finance (CCAF) put Bitcoin’s annual electricity use at 138 terawatt-hours, about 0.5 percent of global electricity consumption, in its Digital Mining Industry Report published on 28 April 2025, according to the Cambridge Judge Business School. The same study found that 52.4 percent of the electricity used by surveyed miners came from sustainable sources, 9.8 percent nuclear and 42.6 percent renewables. That share comes from a survey of 49 mining firms, not from a measurement of the whole network.
Ethereum’s switch gives the clearest before-and-after. The ethereum.org energy page puts proof-of-work Ethereum at 21 TWh a year in its comparison table, and cites the Crypto Carbon Ratings Institute (CCRI) estimate that the Merge cut annualised electricity consumption by more than 99.988 percent, to about 2,601 megawatt-hours a year. Another ethereum.org page, on the Merge itself, rounds the drop to about 99.95 percent. Either way, the reduction is above 99.9 percent.
| Item | Figure | Date | Source |
|---|---|---|---|
| Bitcoin, annual electricity use | 138 TWh, about 0.5 percent of global electricity | Report of 28 April 2025 | CCAF, Cambridge Digital Mining Industry Report |
| Sustainable share among surveyed miners | 52.4 percent (9.8 nuclear, 42.6 renewables) | 28 April 2025 | CCAF survey of 49 firms |
| Ethereum before the Merge (proof of work) | 21 TWh a year | Before 15 September 2022 | ethereum.org comparison table |
| Ethereum after the Merge (proof of stake) | About 2,601 MWh (0.0026 TWh) a year | Page updated 28 July 2026 | ethereum.org, citing CCRI |
| Reduction from the Merge | More than 99.988 percent | Page updated 28 July 2026 | ethereum.org, citing CCRI |
Watts are not the whole story. Defenders of proof of work argue that its energy use is the cost of a security model that does not depend on who already holds coins, and point to miners using surplus or stranded power. Critics answer with the emissions. The figures above do not settle that argument, which has its own lesson later in this path, the Bitcoin energy debate.
European law has taken a side on disclosure, not on design. MiCA’s recital 7 says the consensus mechanisms used to validate crypto-asset transactions might harm the climate, and Article 66(5) requires crypto-asset service providers to “make publicly available, in a prominent place on their website, information related to the principal adverse impacts on the climate” and on the environment, caused by the consensus mechanism of each crypto-asset they provide services for. If you use a MiCA-licensed exchange, that information sits on its site; our guide to MiCA covers the rest of the regulation.
When consensus fails: halts, lost finality and forks
Consensus failures are rarer than headlines suggest, and they rarely mean stolen money. What usually happens is that a network stops, or slows, or cannot make blocks final for a while. The dated cases below show how differently designs behave.
| Date | Chain | What happened | Source |
|---|---|---|---|
| 14 September 2021 | Solana | The network was offline for nearly 18 hours after a flood of transactions; validators coordinated a restart | Decrypt |
| 11 May 2023 | Ethereum | 4 epochs without finality, participation as low as 40 percent; blocks kept coming | Prysm post-mortem |
| 12 May 2023 | Ethereum | 9 epochs without finality, participation down to 30.7 percent, the lowest of any mainnet epoch; an inactivity penalty applied | Prysm post-mortem |
| 6 February 2024 | Solana | Block production halted for about five hours (09:53 to 14:57 UTC); validators restarted on version 1.17.20 | The Block |
| 4 December 2025 | Ethereum | A bug hit nearly all Prysm nodes after the Fusaka upgrade; participation fell to about 75 percent, 248 of 1,344 slots missed (18.5 percent), finality held | Prysm post-mortem |
The two chains failed in opposite ways. In May 2023 Ethereum chose liveness: users could still transact, but nothing became final until enough validators came back, and on the second day an inactivity penalty began to hit the absent ones. Both times the chain recovered without any intervention, according to the Prysm team’s post-mortem. Solana’s design at the time chose safety: when validators could not agree, the chain stopped and needed a coordinated restart by its operators.
The December 2025 incident shows why client diversity matters. Ethereum validators run several independent software clients. A bug in one used by a minority of stake cost missed slots but left participation at about 75 percent, above the two-thirds threshold, so finality survived. A bug in a client used by more than a third of stake could stop finality; one in a client used by more than two-thirds could, in theory, finalise a faulty chain. The same post-mortem noted that another client, Lighthouse, may have run on more than 56 percent of the network in December 2025, citing Miga Labs data, which it called “dangerously close to the threshold at which a client bug could finalize an invalid chain.”
Forks are the other kind of failure. When nodes disagree on the rules themselves, after a contested upgrade or a software bug, the chain can split into two histories that each look valid to their own side. Our lesson on finality and chain reorganisations explains how deep a history can be rewritten on each type of chain, and the lesson on forks covers splits such as Ethereum Classic and Bitcoin Cash. Deliberate 51 percent attacks, where one party gains a majority of hashrate on a small proof-of-work coin, are covered in the immutability lesson linked above.
How to check which consensus a coin uses, and why it matters to you
You do not need to read source code to know what holds a network together. Four checks cover most of it.
- Read the project’s own documentation, not a comparison site: look for the consensus or architecture page and note its date, since mechanisms change.
- Look at finality on a block explorer. Ethereum explorers mark blocks as finalized; Bitcoin explorers show confirmations; BFT chains usually show blocks as final immediately.
- Count who produces blocks. A chain with 21 producers and one with thousands of validators carry different risks, even if both call themselves proof of stake.
- For a crypto-asset offered to the public or traded on a platform in the European Union, look for its MiCA white paper: it has to describe the consensus mechanism and its impact on the climate.
Consensus also decides how you can earn from a network, through mining or staking, and both have legal and tax consequences. On 20 March 2025, staff of the SEC’s Division of Corporation Finance said in a statement on proof-of-work mining that mining as they described it does not involve the offer and sale of securities. On 29 May 2025 the same division said the same of solo, self-custodial and certain custodial protocol staking activities. Both statements are staff views and state that they have no legal force or effect.
The IRS treats both rewards as income. Rev. Rul. 2023-14 says the fair market value of staking rewards is included in gross income in the year the taxpayer gains “dominion and control” over them (IRS ruling text), and IRS Notice 2014-21 says the fair market value of mined coins on the day they are received is includible in gross income. In the UK, HMRC’s Cryptoassets Manual says mining can be a trade or not, depending on how organised and commercial it is; if it is not a trade, the sterling value of the tokens at receipt is taxed as miscellaneous income, and Capital Gains Tax may apply when they are later sold. Our guides to crypto taxes in the United States and crypto taxes in the United Kingdom set out the details. None of this says whether any coin is a good buy; it only explains why the label on a network has practical consequences.
What comes next in this path: Byzantine generals, work and stake
This lesson drew the map. The next lesson tells the story behind it: the Byzantine generals problem, the 1982 thought experiment about loyal and treacherous generals that gave BFT protocols their name and their two-thirds thresholds. After it comes proof of work in depth, from the hash target to difficulty retargets, then the Bitcoin mining guide, with hardware, pools and the honest arithmetic of mining at home. Proof of stake gets the same treatment later, in proof of stake in depth.
One date to keep in mind: Solana’s Alpenglow was only 17 days old on 7 November 2026, and Anza’s 150-millisecond target has yet to be checked against independent measurements. Rotor, the part of Alpenglow meant to replace Solana’s block-spreading layer, is not live yet and will need its own proposal, according to SIMD-0326.
