What Is Finality?

In brief

Finality is a claim about how hard it is to replace a block once the network has accepted it.

Probabilistic finality (Bitcoin-style proof of work): each new honest block raises the work an attacker must redo. There is no protocol flag that says “this can never move.” Depth is a policy.

Economic / checkpoint finality (Ethereum Casper-FFG): stake-weighted checkpoint votes justify and then finalize checkpoints. At least two-thirds of active stake is needed for justification, while conflicting finalized histories require slashable behavior implicating at least one-third of stake. An inactivity leak helps the participating side recover finality after an extended stall.

BFT-style commit (many CometBFT-based chains): a block enters Commit after precommits from more than two-thirds of validator voting power. Safety assumes less than one-third of voting power is Byzantine; conflicting commits provide evidence that at least one-third violated the protocol.

Solana: finalized is the strongest standard RPC commitment: the cluster recognizes a block at maximum vote lockout with at least two-thirds of active stake.

Exchanges, bridges, and rollups each pick a finality assumption. Acting too early is how a reorg or a challenge window turns into a double credit.

Why the word exists

Distributed ledgers can fork. Two honest proposers can publish at once. An attacker can try to replace a recent payment. Users and contracts need a rule for “we will treat this as settled.”

That rule is not universal. Calling every chain “instant finality” or every confirmation “final” erases the actual guarantee.

Bitcoin: never quite done, only buried

Bitcoin nodes follow the valid chain with the most accumulated work. The developer guide: modifying an old block means redoing its proof of work and all work after it, then beating the honest network.

There is no finalized=true bit in a Bitcoin block. A payment processor chooses a confirmation count. Six is a habit. A 51 percent attacker can still attempt a deeper reorg. Honest nodes will follow the heavier valid chain if it appears.

Coinbase rewards wait 100 blocks before they can be spent — a protocol-level pause so a miner cannot cash a reward from a block that later loses a fork.

This is probabilistic settlement. It is a feature of Nakamoto consensus, not a defect the designers forgot.

Ethereum: justified, then finalized

Time is sliced into 12-second slots and 32-slot epochs. A checkpoint is the block root associated with an epoch boundary. It is commonly described as the first block of an epoch; if that slot is empty, the checkpoint root can refer to the most recent earlier block.

Validators vote for source/target checkpoint pairs. In the normal consecutive-checkpoint case, if the link gathers votes from at least two-thirds of active stake:

• the newer checkpoint becomes justified;
• the older already-justified checkpoint becomes finalized.

The consensus specification also handles missed epochs through explicit recent-justification patterns, so the two-line summary is not the complete state-transition algorithm.

Casper-FFG is Ethereum’s checkpoint finality gadget. The approachable ethereum.org description says reverting finalized history requires an attacker to lose at least one-third of the total staked ETH; the normative consensus specification encodes the actual justification-bit and finalized-checkpoint transitions.

If one-third of stake refuses to finalize, the chain can stall. After more than four epochs without finality, the inactivity leak bleeds the non-participating side until the majority can finalize again.

A transaction can be:

• in the head block (fork-choice canonical, still reorgable);
• in a justified checkpoint;
• in a finalized checkpoint.

Those are three different strengths. Wallets that only say “Success” after inclusion are simplifying.

Weak subjectivity is a related proof-of-stake sync caveat: a long-offline node needs a sufficiently recent trusted view instead of treating every ancient signature as equally authoritative. It does not mean ordinary recently finalized payments are merely “pending.” The live Proof of stake article owns the fuller explanation.

Solana and BFT-style commits

Solana RPC uses three commitment levels. processed is the node’s newest view and can roll back; confirmed means more than two-thirds of active stake directly voted on the block; finalized means the cluster recognizes it at maximum vote lockout. A validator also exposes a local root slot, but a single validator setting a root should not be confused with cluster-wide finalization.

That is closer to “supermajority voted this into the locked history” than to Bitcoin’s “more work piled on.”

CometBFT runs rounds of propose, prevote, and precommit at each height. More than two-thirds of voting power precommitting a particular block moves a node to Commit. Users often call this “instant finality,” but the precise claim is deterministic commit finality under the stated Byzantine and network assumptions. If one-third or more equivocates, conflicting commits can violate safety; if one-third or more withholds votes, progress can halt.

Do not say every proof-of-stake chain finalizes like Ethereum epochs.

Bridges, rollups, and “final enough”

A bridge that mints on chain B when it sees a lock on chain A must decide how final that lock is.

• Wait for Bitcoin work → slow, matches Bitcoin’s model.
• Wait for Ethereum finality → epoch-scale, not 12 seconds.
• Optimistic rollup official exits wait a challenge window (often about seven days on common designs — conventional, not a law). Acting before that is a different trust assumption.

A bridge can become undercollateralized if it acts on a source-chain deposit that is later reverted after destination assets are released. Its safety therefore depends on both its own verification design and the source chain’s finality assumption.

Finality is not a moral grade

Finality latency alone does not measure decentralization or security. Compare what fraction of hash power or stake can violate safety, what can halt progress, whether misbehavior is attributable and punishable, and what assumptions a new or long-offline node needs to sync.