Common in Proof-of-Work chains like Bitcoin and Ethereum (pre-Merge). Finality is not absolute but probabilistic, increasing with each subsequent block confirmation. A transaction is considered 'final' after a sufficient number of confirmations (e.g., 6 blocks for Bitcoin), as the probability of a reorganization excluding it becomes astronomically low. The trade-off is a delay for high-value settlement.

Used by Proof-of-Stake chains like Algorand and some BFT-based networks. Once a block is finalized by the consensus protocol, it is immediately and irreversibly added to the chain. There is no waiting period for confirmations. This is achieved through mechanisms where validators explicitly vote to finalize a block, making reorganization computationally impossible barring a catastrophic failure of the consensus set.

A concept central to Ethereum's current Proof-of-Stake (Gasper). Validators stake ETH as collateral. Finality is achieved in two stages: a block becomes 'justified' then 'finalized' through attestations. If validators attempt to revert a finalized block, their entire stake can be slashed (destroyed). Finality is therefore secured by massive economic penalties, making attacks prohibitively expensive.

Used by Bitcoin and Ethereum (pre-PoS), this model provides economic finality. A transaction is considered final after a sufficient number of confirmations (blocks built on top).

• Security: High, as reversing a transaction requires a 51% attack, which becomes exponentially expensive.
• Liveness: Slower, as users must wait for multiple confirmations for high-value transactions (e.g., 6 blocks for Bitcoin, ~12 for Ethereum).
• Trade-off: Maximizes censorship resistance and decentralization at the cost of slower, probabilistic finality.

Used by Cosmos (Tendermint) and Binance Smart Chain, this model provides instant, deterministic finality. Once a block is finalized by a supermajority of validators, it cannot be reverted.

• Security: High against block reversions, but the validator set is smaller and permissioned, creating a different trust model.
• Liveness: Fast, with finality times of 1-6 seconds.
• Trade-off: Sacrifices some decentralization (limited validator count) for speed and immediate finality. The chain can halt if >1/3 of validators are offline.

Modern chains like Ethereum 2.0 use hybrid models. Ethereum combines a LMD-GHOST fork-choice rule (for liveness) with Casper FFG checkpoints (for finality).

• Security: Checkpoints are finalized every two epochs (~12.8 minutes) by a 2/3 supermajority of staked ETH, making reversion astronomically expensive.
• Liveness: Transactions are considered 'safe' within one slot (12 seconds) but are only absolutely final after checkpoint finalization.
• Trade-off: Balances fast, responsive chain growth with periodic, cryptoeconomically secured finality.

Layer 2 solutions like Optimism and Arbitrum post transaction data to a base layer (e.g., Ethereum) and assume it's valid unless challenged.

• Security: Inherits from the base layer but with a fraud proof window (typically 7 days). Users must wait this period for full withdrawal security.
• Liveness: Very high for on-chain activity, with near-instant confirmations.
• Trade-off: Provides high throughput and low fees but introduces a withdrawal delay for the highest security guarantee, creating a trust-minimized but not trustless bridge.

Finality determines when a transaction's outcome is irreversible. Developers must design contracts to handle probabilistic finality (e.g., on Ethereum, waiting for 12-15 confirmations) versus instant finality (e.g., on Cosmos or Avalanche C-Chain).

• Re-org protection: On chains with probabilistic finality, critical logic should reference block hashes that are sufficiently old.
• Front-running: Faster finality reduces the window for MEV extraction and front-running attacks.
• Example: A high-value NFT mint on Ethereum requires more confirmations than a simple token transfer on Solana.

Bridges and interoperability protocols are highly sensitive to finality assumptions. A chain re-org on one network can break the security model of a cross-chain message.

• Challenge periods: Optimistic bridges like those using fraud proofs require long waiting periods (e.g., 7 days on Arbitrum) to ensure source chain finality.
• Light client verification: Bridges using light clients (e.g., IBC) require the connected chains to have fast finality for secure header verification.
• Risk: Assuming a transaction is final too early is a common vulnerability in bridge design, leading to exploits.

Ethereum uses economic finality via Casper FFG layered on top of continuous block production.

Key concepts covered in the official documentation:

• Justification and finalization: epochs become final after 2 consecutive justified checkpoints
• Slot and epoch timing: 12-second slots, 32-slot epochs
• Finalization latency: typically ~12–15 minutes under normal network conditions
• Reorg depth: finalized blocks are irreversible without validator slashing

This resource explains how Ethereum transitioned from probabilistic PoW finality to PoS economic finality after the Merge, including:

• Validator voting mechanics
• Slashing thresholds (≥33% fault tolerance)
• Impact of missed attestations on finality delay

Use this to model settlement guarantees for L2s, bridges, and DeFi protocols that rely on Ethereum finality rather than simple block confirmations.

Bitcoin does not have explicit finality. Instead, it relies on probabilistic finality based on accumulated proof-of-work.

This reference explains:

• Why the 6 confirmation rule emerged historically
• How reorg probability decreases exponentially with each additional block
• Trade-offs between confirmation depth and settlement latency

Important technical points:

• Average block time: ~10 minutes
• Reorgs deeper than 2 blocks are rare but possible
• Finality is social and economic, not cryptographic

For high-value transfers, exchanges and custodians often require:

• 6–12 confirmations for deposits
• More confirmations for low-hashrate periods or reorg-prone conditions

This is essential reading for understanding risk models in Bitcoin custody, payment processors, and wrapped BTC bridges.

Tendermint BFT provides deterministic finality as soon as a block is committed by ≥2/3 of validators.

This documentation covers:

• Byzantine Fault Tolerance assumptions
• Voting rounds: propose, prevote, precommit
• Immediate finality once a block is committed

Critical properties:

• No chain reorgs once a block is committed
• Safety holds unless >33% validators are Byzantine
• Finality time often <5 seconds depending on block time

Used by Cosmos SDK chains such as:

• Cosmos Hub
• Osmosis
• dYdX Chain

This resource is valuable for developers designing:

• Cross-chain IBC relayers
• Fast-settlement trading applications
• UX-sensitive consumer applications where reorgs are unacceptable

Solana distinguishes between processed, confirmed, and finalized states.

This resource explains:

• Optimistic confirmation through Tower BFT
• Vote lockouts and fork choice rules
• Difference between local confirmation and cluster-wide finality

Key technical details:

• Slot time ~400ms
• Finalization occurs when supermajority votes lock out alternative forks
• Applications must explicitly wait for finalized commitment for safety

Developers should understand:

• Why "confirmed" is not final
• How RPC commitment levels affect application correctness
• Common causes of short-lived forks

Essential reading for anyone building wallets, exchanges, or trading bots on Solana where premature confirmation can lead to double-spend risk.

This paper-style documentation explores finality gadgets as a design pattern layered on Nakamoto-style consensus.

Topics include:

• Separation of liveness and safety
• Why probabilistic chains add finality gadgets
• Comparison of GRANDPA, Casper FFG, and HotStuff

Covered systems:

• Ethereum Casper FFG
• Polkadot GRANDPA
• BFT-style finality overlays

This resource is useful for:

• Protocol researchers
• Consensus engineers
• Teams designing new L1s or rollup settlement layers

It helps answer questions such as:

• When probabilistic finality is acceptable
• How finality affects MEV, bridges, and governance
• Trade-offs between finality speed, complexity, and validator requirements