On 23 March 2026, at 15:49 UTC, Bitcoin block 941,881, mined by AntPool, reached monitoring nodes; two minutes later ViaBTC’s block 941,882 landed on top of it. Wallets showed their transactions as confirmed, once and then twice. Around 15:55 Foundry published a branch three blocks long, every node switched to it, and both blocks dropped out of the chain. Nothing was stolen and no rule was broken, yet two confirmations had vanished, which is what blockchain finality is about. According to the Bitcoin Network Operations Collective thread on the event, the previous known two-block reorganisation dated from May 2023.
A transaction can be seen, included in a block, buried under other blocks, voted final by validators, or treated as final by a law, and each network stops on a different step of that ladder. Bitcoin never reaches absolute finality: a payment only becomes more expensive to undo with every block. Ethereum finalizes by a vote of its stakers, at least 12.8 minutes after a transaction lands and about 15 minutes in practice. Solana switched on a new voting system on 21 October 2026 that its developers expect to finalize in a fraction of a second, a target not yet measured on mainnet. Cosmos chains stop producing blocks rather than fork.
This advanced lesson gives you the tools to judge any chain with three questions. How can a block I see today disappear? How deep has that ever happened? What would it cost to make it happen on purpose? It follows our lesson on the double-spending problem, which showed how an attacker uses a reorganisation to spend the same coins twice; here we look at the reorganisations themselves and at the finality rules built to stop them.
Blockchain finality means three different things
The word “final” hides three guarantees of very different strength. Engineers group them into families, and every chain you use belongs to one of them, sometimes to two at once.
Probabilistic finality belongs to proof-of-work chains such as Bitcoin, Litecoin or Monero. A block is never final by rule. It becomes harder to replace as more blocks are stacked on top, because a rival branch would need to redo all that work and then overtake the honest chain. The odds of a reversal fall roughly exponentially with depth but never reach zero. The Bank for International Settlements put it plainly in a 2017 report of its payments committee (CPMI): “In arrangements that use a proof-of-work model, settlement is probabilistic.”
Economic finality is what Ethereum offers. Validators who have locked ether as a deposit vote on checkpoints. Once two thirds of the stake has voted a checkpoint final, reverting it would require at least a third of all staked ether to break the voting rules in a way the protocol can prove and punish. A reversal is still possible, but the attackers would lose their deposits, which is the point.
Deterministic finality, sometimes sold as “instant finality”, comes from classical Byzantine fault tolerant voting, as in CometBFT (formerly Tendermint), Polygon PoS milestones and Solana’s new Alpenglow consensus. A block is final as soon as a large quorum of stake has signed it, usually within one block. There is no gradual hardening: before the quorum the block is not final, after it the rules forbid any conflicting block.
Two words help to compare them. Safety means two honest nodes never accept conflicting histories. Liveness means the chain keeps adding blocks. Bitcoin favours liveness: it always produces blocks, and safety is a matter of probability. BFT chains favour safety: if too many validators go silent, they stop. Ethereum tries to keep both, with a fork-choice rule that keeps blocks coming and a separate finality gadget that can pause while the chain moves on, as May 2023 showed.
If you need a refresher on why two valid blocks can appear at the same height in the first place, our guide to how a blockchain works covers the basic rule for agreeing on one chain. For the cost of rewriting old history and the basics of 51 percent attacks, see why a blockchain is considered immutable.
How a chain reorg happens on Bitcoin
Two valid blocks, one surviving chain
A Bitcoin block takes time to cross the network. If two miners find a valid block at almost the same moment, part of the network hears about one first and part about the other. Both are valid. Each node keeps building on the first one it saw and remembers the other. The tie breaks when the next block arrives: nodes follow the branch with the most accumulated work, which in practice is usually the longer one. The losing block becomes a stale block. Many people call it an “orphan”, a looser use of the word that the next lesson of this path, on forks, sorts out.
The switch is called a chain reorganisation, or reorg. A node disconnects the losing block or blocks, undoes their effect on its record of unspent coins, connects the winning blocks and returns to its mempool every transaction that was in the lost blocks but not in the new ones. Most of those transactions are mined again within minutes, because the winning miner usually had them too. A transaction that conflicts with one in the new chain is dropped for good: that is exactly what a double spender hopes for.
Latency is the main cause of accidental stale blocks, which is why miners invest in fast block relay. Our lesson on peer-to-peer networks explains how blocks travel and why slow propagation makes stale blocks more likely.
How often and how deep: the Bitcoin record
Nobody can see every stale block, because a node only learns about the competing blocks that reach it. The best public record is the crowd-sourced bitcoin-data/stale-blocks dataset on GitHub, fed by node operators who keep the blocks their nodes saw and discarded. As read on 7 November 2026 it held 4,194 entries. Counting them by the timestamp in each block header gives this picture.
| Year | Stale blocks recorded | Year | Stale blocks recorded |
|---|---|---|---|
| 2015 | 572 | 2021 | 83 |
| 2016 | 175 | 2022 | 28 |
| 2017 | 195 | 2023 | 70 |
| 2018 | 89 | 2024 | 49 |
| 2019 | 68 | 2025 | 93 |
| 2020 | 123 | 2026 (to 3 November) | 61 |
Two caveats. The dataset under-counts, since it depends on who contributes and when, so comparing one year with another is rough at best. Anthony Towns, a Bitcoin Core developer, noted in the BNOC thread that his own node never saw Foundry’s racing blocks before the reorg, which might mean one-block stale blocks are more common than the record shows. Bitcoin produces about 52,500 blocks a year, so the 93 entries for 2025 suggest that something on the order of one block in five hundred ends up stale: an estimate from this dataset, not a measured rate. The latest entry, at height 974,400, dates from 3 November 2026.
Almost all of these are one-block reorgs. Two blocks deep is rare. In the BNOC thread on the March 2026 event, the developer Anthony Towns listed the earlier two-block stale chains in the dataset: October 2013, June 2015, November 2020 and May 2023. His rough rate was “every ~3 years or 150k blocks?”, question mark included. Foundry went on to mine seven blocks in a row that afternoon. When a public stratum-monitoring site showed no Foundry work on the racing blocks, the thread’s opener, b10c, floated a regional setup, a monitoring bug or selfish mining; the site’s operator then explained that he had never been able to collect Foundry’s templates. No cause was established in the thread.
Deeper reorganisations on Bitcoin came from bugs, not from races. In August 2010 a value overflow bug let block 74,638 create about 184 billion bitcoin; a patched client was released within hours and the corrected chain overtook the bad one at height 74,691, replacing about 53 blocks by our count from the two heights the Bitcoin wiki gives, the deepest reorg in Bitcoin’s history (the full story is in our guide to whether a blockchain can be hacked). In March 2013 a block with more transaction inputs than older software could handle was accepted by version 0.8 nodes and rejected by many 0.7 nodes, as Gavin Andresen’s post-mortem, BIP 50, explains. Two large pools, BTCGuild and Slush, downgraded to 0.7 so that most of the hash power would back the old chain. The 0.8 branch, which Bitcoin Magazine reported as 13 blocks ahead at one point, was abandoned: the split lasted 24 blocks from height 225,430, about six hours.
Why depth makes a payment safer but never certain
Each additional block multiplies the work a rival branch must redo. For an attacker with a minority of the hash power, the chance of catching up shrinks very quickly with depth, which is the reasoning behind the six-confirmation convention; our lesson on the mempool and transaction fees goes through the white paper’s own probability table. What depth cannot do is turn probability into certainty. An attacker with more than half the hash power can, in principle, outpace the honest chain at any depth, for as long as they pay for the energy and hardware.
That is not theory on smaller proof-of-work chains, where renting enough hash power is cheaper. Ethereum Classic suffered reorganisations thousands of blocks deep in August 2020, and Bitcoin Gold was hit in 2018; those 51 percent attacks are told in our guide to blockchain hacks linked above. A more recent case comes from Monero. On 14 September 2025 the Monero Research Lab, an unofficial research group, raised the alarm over an 18-block reorganisation starting at height 3,499,659, according to The Block, which counted roughly 117 to 118 transactions left on the abandoned branch for almost 40 minutes. Community accounts pointed at the Qubic mining project, whose founder rejected some of those claims; The Block wrote that responsibility had not been established.
The lesson for a receiver is that depth has to match the value at stake and the cost of attacking that particular chain. Six blocks on Bitcoin, which has the largest hash power of any proof-of-work network, buy far more security than six blocks on a small chain that shares its mining algorithm with a larger one.
Ethereum finality: a vote backed by a third of all stake
Slots, epochs and checkpoints
Ethereum’s proof-of-stake consensus, called Gasper, has two parts. A fork-choice rule, LMD-GHOST, picks the head of the chain every slot by following the branch that has the most recent validator votes. A finality gadget, Casper FFG, works on a slower rhythm. The consensus specifications set a slot at 12 seconds and an epoch at 32 slots, so one epoch lasts 6.4 minutes.
The first block of each epoch is a checkpoint. During the epoch every active validator casts one attestation, which also votes for a pair of checkpoints: a source and a target. When validators holding two thirds of the staked ether vote for the same target, that checkpoint is justified. When a justified checkpoint is followed by a justified checkpoint in the next epoch, the first one becomes finalized, with every block before it.
In the normal case a transaction is therefore final at the end of the epoch after the one in which it was included, so the wait depends on where in the epoch it landed. The floor is two epochs, at least 12.8 minutes; in practice it is about 15 minutes, the figure ethereum.org gives, and Circle’s documentation allows for 15 to 19 minutes. A live read of the beacon chain at 09:53 UTC on 7 November 2026 showed the usual pattern: head in epoch 487,555, last justified epoch 487,554, last finalized epoch 487,553.
Applications see these stages through the block tags of Ethereum’s JSON-RPC interface. The execution-apis specification says the latest block “may be re-orged out of the canonical chain even under healthy/normal conditions”. The safe block is protected from reorgs under an honest majority and some network timing assumptions. The finalized block is the most recent one that “cannot be re-orged outside of manual intervention driven by community coordination”. A wallet that shows a green tick after one block is showing you “latest”, the weakest of the three.
What it would cost to undo a finalized block
Two conflicting checkpoints cannot both be finalized unless at least a third of the stake has signed contradictory votes. Such votes are evidence: anyone can submit them, and the protocol slashes the validators involved, burning part of their deposit and forcing them out. Ethereum’s design accepts that a large enough attacker could still finalize a conflicting history, but it guarantees that the attacker loses at least a third of all staked ether. Our glossary entry on proof of stake covers the deposit-and-penalty model in general.
The execution-apis wording quoted above, “manual intervention driven by community coordination”, is the honest footnote. If a supermajority ever did finalize a bad chain, the way out would be a social decision by node operators to reject it, not an automatic rule. This has never happened on Ethereum mainnet.
When the head moves: the seven-block reorg of May 2022
Finality protects old blocks; the head of the chain can still move. On 25 May 2022, between 08:55 and 08:57 UTC, the beacon chain reorganised seven blocks, slots 3,887,075 to 3,887,081. This was before the Merge, so the beacon chain carried no user transactions yet. In his analysis of the event, Ethereum Foundation researcher Barnabé Monnot traced it to a late block and a partial roll-out of a fork-choice change called proposer boost: some clients ran it and others did not, so they disagreed on the head for a few slots. Finality was not delayed.
When finality stops: May 2023 and the inactivity leak
The opposite failure happened twice in May 2023. Blocks kept coming, but the chain could not finalize. According to the Prysm client’s postmortem and an analysis by Thomas Thiery on ethresear.ch, some consensus clients, Prysm and Teku among them, handled valid attestations pointing to old checkpoints badly: each one made them rebuild an old state, and when such attestations arrived in large numbers Prysm nodes ran out of resources. Lighthouse dropped those attestations and kept going.
On 11 May, from about 20:07 UTC, finality stopped for about four epochs, roughly 25 minutes, with participation falling to about 40 percent and around 47 blocks missed. On 12 May, from 17:20 UTC, it stopped for about nine epochs, a little over an hour. Participation fell to 30.7 percent, which the Prysm postmortem called the lowest of any mainnet epoch, and about 149 blocks were missed. Both times the chain recovered without manual intervention, and Prysm v4.0.4 shipped the fixes. The postmortem says end-user transactions were minimally impacted: blocks kept coming, and the services that wait for finalized blocks were the ones left waiting.
The second incident triggered the inactivity leak. When the chain has gone more than four epochs without finality, the protocol starts draining the balances of validators that are not voting, faster the longer the outage lasts. The aim is to shrink the offline share until the validators still online hold two thirds of the remaining stake again, so finality can resume even if a third of the network vanished for good. By the postmortem’s estimate, validators paid about 28 ETH in penalties and missed 55 ETH or more of potential revenue.
A near miss came a few hours after the Fusaka upgrade, which activated late on 3 December 2025. From about 02:45 UTC on 4 December, nearly all Prysm nodes ran out of resources while checking certain attestations, the same postmortem page reports. Over the 42 epochs it counts as affected, 248 of 1,344 slots had no block, participation fell as low as 75 percent and validators missed about 382 ETH of attestation rewards; the incident was considered mitigated at 07:12 UTC. The Prysm team credits client diversity for the limited damage and spells out what was at stake: a client with more than a third of the network “would have caused a temporary loss in finality”, and one with more than two thirds “could finalize an invalid chain”.
The same document adds a warning of its own. Citing Miga Labs data of 12 December 2025, it says Lighthouse may have run more than 56 percent of the network, which it calls dangerously close to the level at which one client’s bug could finalize an invalid chain.
Faster finality is still research
Fifteen minutes is long for a payment, and Ethereum researchers have worked for years on single-slot finality, which would finalize every block within its own slot. As of 7 November 2026, ethereum.org still says single-slot finality is in the research phase and not expected to ship for several years. Researchers have also proposed designs that finalize within a few slots, such as the 3-slot finality protocol published by D’Amato, Saltini, Tran and Zanolini in November 2024. None of this is scheduled: the next planned upgrade, Glamsterdam, still had no mainnet activation epoch in the consensus specification on 7 November 2026.
Deterministic finality: chains that halt rather than fork
CometBFT and the Cosmos chains
Most Cosmos chains run CometBFT, the engine formerly known as Tendermint. Validators go through rounds of proposal and voting for each height, and a block is committed only when more than two thirds of the voting power has signed it. The CometBFT documentation promises that, with fewer than a third of validators faulty, “validators will never commit conflicting blocks at the same height.” There is no reorg to wait out: a committed block is final in one block, usually a few seconds.
The price is liveness. Validators only move forward after hearing from more than two thirds of the set, so if more than a third is offline or split by a network fault, no block is produced at all. The chain halts until enough validators return. For an exchange or a bridge this is the friendlier failure: a frozen chain loses time, while a chain that forks can lose money.
Solana: from 32 slots to Alpenglow
Solana exposes finality as three commitment levels that wallets and applications request from their node. Under the Tower BFT consensus it ran until October 2026, the Anza documentation defines them this way: processed means a node received the block on the majority fork; confirmed means 66 percent or more of the stake voted on it; finalized means at least 31 confirmed blocks were built on top. At the nominal 400-millisecond slot, those 32 blocks add up to about 12.8 seconds.
On 21 October 2026 at 13:36 UTC, at slot 459,648,000, the first slot of epoch 1064, Solana’s mainnet activated the Alpenglow feature gate, as the feature account on the chain shows. Anza calls the voting and finality part of Alpenglow Votor; a separate part, Rotor, changes how blocks are spread across the network. Under the new rules the same documentation merges confirmed and finalized: both require 60 percent of stake voting to finalize, or 80 percent voting to notarize a block, and both mean the transaction can no longer be rolled back. In its May 2025 announcement, Anza wrote that it expects Alpenglow “can achieve actual finality in about 150 ms (median)”, sometimes as fast as 100 ms. Read those numbers as the developers’ target, written more than a year before activation, not as a measured mainnet result.
The same announcement says Votor finalizes in a single round of voting when 80 percent of the stake takes part, and in two rounds when only 60 percent responds.
Polygon PoS: from a 157-block reorg to milestones
Polygon PoS shows why a fast chain without hard finality makes bridges nervous. On 22 February 2023, at block 39,599,624, the chain reorganised 157 blocks, about five minutes of history. A post on the Polygon forum tied the long reorg to a partial outage of the network. For anyone who had credited deposits after a few dozen blocks, five minutes of reversed history was a real exposure.
Polygon later added milestones: validators vote on recent blocks, and once two thirds of the voting power agrees, the Polygon documentation says every transaction up to that milestone is final, even before the periodic checkpoint is written to Ethereum. Milestones can fail too. In September 2025 they lagged by 10 to 15 minutes because of a node bug, and the network shipped an emergency hard fork on 10 September at 15:00 UTC, according to The Block; no reorg was reported, only slower finality.
Layer 2: three kinds of confirmed
Rollups add their own ladder on top of Ethereum’s. If the difference between a base chain and a rollup is new to you, our comparison of layer 1 and layer 2 explains it. The point here is what “confirmed” means at each step.
The OP Stack documentation describes three stages for chains such as OP Mainnet and Base. A transaction is unsafe after about two seconds, when the sequencer has put it in a block that is not yet posted to Ethereum. It becomes safe within a few minutes, once its data sits in an Ethereum block. It is finalized after about 15 to 30 minutes, when Ethereum has finalized that block. Arbitrum’s documentation describes the sequencer feed the same way: “a sub-second provisional confirmation that depends on the Sequencer behaving honestly”, followed by hard finality once the batch is final on Ethereum.
A common mistake is to confuse finality with the challenge window. On optimistic rollups, withdrawals to Ethereum through the official bridge wait about a week so that fraud can be challenged; the OP Stack documentation gives a minimum of seven days for its Standard Bridge. That delay applies to the withdrawal, not to the transaction itself: the OP Stack documentation says the challenge period “does not impact transaction finality on the OP Stack chain”. A transfer on a rollup is final as soon as the Ethereum block carrying its data is finalized.
What exchanges, bridges and merchants actually wait for
Every service that accepts crypto picks a rung on the ladder and accepts the risk below it. The table sums up where each chain’s finality comes from, as of 7 November 2026.
| Chain | Type of finality | What makes a block final | Typical time |
|---|---|---|---|
| Bitcoin | probabilistic | more work stacked on top; never absolute | about 10 minutes per block; the receiver chooses the depth |
| Ethereum | economic (Gasper) | checkpoint finalized by two thirds of staked ether | at least 12.8 minutes, about 15 in practice |
| Solana (Alpenglow Votor, since 21 October 2026) | deterministic vote | 60% of stake voting finalize or 80% voting notarize | about 150 ms median, Anza’s target; not a mainnet measurement |
| Cosmos chains (CometBFT) | deterministic (BFT) | more than two thirds of voting power signs the block | one block, a few seconds; halts if more than a third is offline |
| Polygon PoS | milestones plus Ethereum checkpoints | two thirds of voting power on a milestone | Circle waits 2-3 blocks, about 8 seconds |
| OP Mainnet, Base, Arbitrum One | inherited from Ethereum | Ethereum finalizes the block carrying the rollup’s data | soft in about 2 seconds or less; final in about 15-30 minutes |
Exchanges: a depth per asset
Centralised exchanges publish how many confirmations they wait for before crediting a deposit, and the counts vary by asset and over time. Kraken’s support page on deposit times, read on 7 November 2026, gives Bitcoin as its example: deposits are credited after three confirmations, which it says take about 45 minutes. The exchange takes the risk of a deeper reorg on itself: if the deposit disappears after you have sold the coins, it is the exchange that is short. Always check the exchange’s own deposit page for the asset and network you use rather than a figure from a forum; our guide to how centralised exchanges work explains the deposit flow.
Bridges: paying out before the source chain is final
Bridges carry the most reorg risk, because they release funds on one chain against an event on another. If the source chain reorganises after the destination has paid, the bridge has given money for a deposit that no longer exists. Circle’s Cross-Chain Transfer Protocol documentation, read on 7 November 2026, shows the trade-off between its two modes.
| Source chain | Fast Transfer | Standard Transfer (hard finality) |
|---|---|---|
| Ethereum | 2 blocks, about 20 seconds | about 65 blocks, about 15-19 minutes |
| Arbitrum, Base, OP Mainnet | 1 block, about 8 seconds | about 65 Ethereum blocks, about 15-19 minutes |
| Solana | 2-3 blocks, about 0.4-0.6 seconds | 32 blocks, about 17 seconds |
| Polygon PoS | not offered | 2-3 blocks, about 8 seconds |
| Avalanche | not offered | 1 block, about 8 seconds |
A fast transfer pays out before the source chain is final, so the operator takes on the risk of a reorganisation, and usually charges for it. Where no fast mode exists, Circle’s explanation is that the standard wait on those chains is already short. The Solana row still lists 32 blocks, the Tower BFT rule, two weeks after Alpenglow went live: services do not all update their waits on the day a chain changes its consensus. Our guide to bridges and cross-chain intents covers the designs and their risks in detail.
Merchants and individuals: match the wait to the amount
For a coffee paid in bitcoin, an unconfirmed or one-confirmation payment is a small risk. For a car, it is not. The race, Finney and reorg attacks described in our lesson on double spending all exploit a receiver who treats a shallow block as final. Rules of thumb follow from the sections above: on Bitcoin, wait for more blocks as the amount grows; on Ethereum and rollups, treat “finalized” as the line for large sums and “latest” as provisional; on BFT chains, one committed block is final, but check that the chain is producing blocks at all. Above all, find out which level your wallet or service is actually showing you.
Settlement finality in law is not finality on chain
Banks and market infrastructures use the same word with a legal meaning. In the European Union, Directive 98/26/EC on settlement finality makes transfer orders entered into a designated payment or securities settlement system legally enforceable and binding on third parties, even if a participant becomes insolvent. The United Kingdom has its own counterpart, the Financial Markets and Insolvency (Settlement Finality) Regulations 1999. That finality is a rule a court enforces.
The directive was written for designated systems run by identifiable operators, and nothing on a public chain is final by statute. Bitcoin’s finality is a probability, Ethereum’s a penalty, and a BFT chain’s a voting rule. The BIS report quoted earlier draws the practical consequence for proof of work: “the more times the transaction is confirmed in the ledger, the less likely it will be revoked.” Each model has had its bad day: Bitcoin a 53-block reorg in 2010, Ethereum an hour without finality in 2023, Polygon, before its milestones, a 157-block reorg the same year.
The table below gathers the dated incidents covered in this lesson.
| Date (UTC) | Chain | Event | Depth or duration |
|---|---|---|---|
| 15-16 August 2010 | Bitcoin | value overflow bug, block 74,638 | about 53 blocks |
| 11-12 March 2013 | Bitcoin | 0.7 / 0.8 database split, from block 225,430 | 24 blocks, about 6 hours |
| 25 May 2022 | Ethereum beacon chain (before the Merge) | partial roll-out of proposer boost | 7 blocks; finality not delayed |
| 22 February 2023 | Polygon PoS | reorg at block 39,599,624 after a partial outage | 157 blocks, about 5 minutes |
| 8 May 2023 | Bitcoin | two-block stale chain | 2 blocks |
| 11 May 2023 | Ethereum | loss of finality, Prysm bug | about 4 epochs, about 25 minutes |
| 12 May 2023 | Ethereum | loss of finality, participation 30.7% | about 9 epochs, a little over an hour |
| 10 September 2025 | Polygon PoS | milestones lag, emergency hard fork | finality delayed 10-15 minutes, no reorg |
| 14 September 2025 | Monero | alternate chain from block 3,499,659, source not established | 18 blocks |
| 4 December 2025 | Ethereum | Prysm bug after Fusaka, participation as low as 75% | 42 epochs degraded, 248 slots without a block |
| 23 March 2026 | Bitcoin | Foundry branch replaces AntPool and ViaBTC blocks | 2 blocks, a few minutes |
The next lesson of this path looks at forks: the planned rule changes, soft and hard, that split a chain on purpose, and the stale-versus-orphan vocabulary this lesson borrowed. Before then, the quickest check you can make is to open your wallet or exchange and find out whether it is showing you latest, safe or finalized.
