Blockchain finality is the point after which a transaction can no longer be reversed under a network’s own rules, or can be reversed only at a cost the protocol defines. A wallet that shows “confirmed” may still be describing an earlier stage. Before you ship goods against an on-chain payment or move funds onward, check which kind of finality the network offers and which stage the transaction has reached.

Probabilistic finality: Bitcoin’s growing margin

Bitcoin never declares a block final. Each new block on top of a transaction adds work that an attacker would have to redo to replace it. Section 11 of the Bitcoin whitepaper models this as a race: an attacker with a share of mining power must catch up from a number of blocks behind, and the probability of ever catching up “drops exponentially” as that gap grows.

The paper’s own table makes the idea concrete. For an attacker with 10% of the hashing power, the chance of catching up from six blocks behind is about 0.024%. For an attacker with 30%, the whitepaper calculates that a recipient would need to wait 24 blocks to push that chance below 0.1%. The answer depends on the attacker’s assumed share, which nobody observes directly.

That is why Bitcoin finality is a business decision. A service chooses how many confirmations to wait for based on the value at stake and the risk it accepts. Our guide to proof of work and proof of stake explains where that mining work comes from.

Economic finality: Ethereum’s checkpoints

Proof-of-stake Ethereum adds an explicit finality step. According to ethereum.org’s proof-of-stake documentation, time is divided into 12-second slots and 32-slot epochs, and the first block of each epoch is a checkpoint. Validators vote on pairs of checkpoints. When a pair attracts votes representing at least two-thirds of all staked ETH, the newer checkpoint becomes “justified” and the older one becomes “finalized”.

An epoch of 32 twelve-second slots lasts 6.4 minutes, and a checkpoint is finalized only once the following one is justified. A transaction therefore usually waits more than one epoch between inclusion in a block and finality.

The guarantee is economic. The same documentation says an attacker trying to revert a finalized block would commit to losing at least one-third of all staked ETH. An attacker voting with one-third of the stake could instead stop the chain from finalizing. The defense is the “inactivity leak”: when the chain fails to finalize for more than four epochs, it bleeds away stake from validators voting against the majority until the majority regains two-thirds.

Commitment levels: what Solana’s RPC reports

Solana exposes the stages directly. Its RPC documentation defines three commitment levels that an application can request:

  • processed: the node’s most recent block, which “can still be rolled back”;
  • confirmed: a block voted on by a supermajority of more than two-thirds of active stake;
  • finalized: a block the cluster treats as finalized with maximum lockout.

Methods that accept a commitment parameter typically default to finalized. An application that asks for processed data gets a faster answer and a weaker one; a payment screen built on it can show success for a block that later disappears.

Solana’s mechanism is changing. Anza’s Alpenglow page describes a new consensus protocol that replaces TowerBFT, the protocol Solana has used since genesis, and lists testnet and devnet migrations as completed, with mainnet-beta set for October 21. Anza states a finality target of 150 milliseconds. In its Votor component, a block finalizes in one round if 80% of stake responds, or at 60% after two rounds. Those are the developer’s design figures; how the network performs after the switch is a separate question.

How to use finality in practice

Match the wait to what happens next. A small in-app purchase can tolerate a different risk from a large exchange deposit that is about to be withdrawn elsewhere.

  • Read the stage your wallet, explorer or API reports, and find out what that label means on that network.
  • Wait for the network’s final stage, or a confirmation depth you have chosen deliberately, before releasing goods or funds.
  • Expect longer waits when a network has trouble finalizing, and treat an unusually long wait as a reason to hold off.

Exchanges and custodians apply their own waiting rules on top of the protocol. Our comparison of self-custody and exchange accounts covers what changes when someone else holds the keys.