Finality by Chain

Different blockchains use different consensus mechanisms, which leads to different models of finality. Even once a transaction is onchain, users may need to wait for it to be considered final, and how long varies by chain.

Blockchain finality falls into two broad categories:

• Probabilistic finality — commonly used by Proof-of-Work chains (e.g., Bitcoin). A transaction becomes more difficult to revert as more blocks are built on top of it. Exchanges and cross-chain systems typically handle this type of finality with N-confirmation heuristics. Probabilistic finality is not the focus of this article.
• Deterministic finality — commonly used by Proof-of-Stake chains (e.g., Ethereum) and most smart-contract chains integrated with Chainlink CCIP today. The rest of this article covers the different variants of deterministic finality.

A useful framing for layer 2 chains (L2s) in particular is soft finality vs. hard finality: soft finality is what an offchain observer can reasonably trust through self-observation before the chain itself guarantees it; hard finality is the protocol-level guarantee itself.

Numbers at a Glance

Deterministic Finality on L1 PoA/PoS Chains

Proof of Stake (PoS) and Proof of Authority (PoA) chains typically use Byzantine Fault Tolerant (BFT) consensus. Under the assumption that a sufficient share (usually 67%) of validators or stake is honest, finality guarantees hold.

Ethereum (Casper FFG). The first block of each epoch (~6.4 min) is a checkpoint. Validators vote on (source → target) checkpoint pairs. When ≥2/3 of staked ETH votes for a pair, the target becomes justified; the source becomes finalized once it has a justified descendant. Under normal conditions, a block is finalized roughly two epochs (~12.8 min) after inclusion. Reverting a finalized checkpoint requires conflicting votes that get slashed, costing attackers at least one-third of total staked ETH.

CometBFT (Cosmos Hub and others). A BFT consensus algorithm (the renamed Tendermint Core) providing instant single-slot finality. As long as more than two-thirds of validators are honest, a block is final the moment it is committed.

Avalanche. Validators are repeatedly sampled at random and vote on transactions until a confidence threshold is reached. Finality is typically achieved in ~1–2 seconds.

BNB Chain (post-BEP-126 Fast Finality). Combines Proof of Staked Authority with a Casper-FFG-style vote mechanism. Validators sign blocks with BLS keys; once a block accumulates ≥2/3 votes it becomes justified, and once two consecutive blocks are justified the earlier one is finalized. In practice this takes ~2.5 blocks, or about 0.65 seconds.

Solana. Uses TowerBFT on top of Proof of History. Blocks reach optimistic confirmation within a couple of slots and are considered finalized once a supermajority root is reached, typically within ~12.8 seconds.

Deterministic Finality on L2s

L2s post periodic checkpoints to an underlying L1 settlement chain, inheriting (with some lag) the L1's finality guarantees. An L2 transaction therefore has two layers of finality: soft finality once the sequencer's commitment is posted and finalized on L1, and hard finality after any rollup-specific delay (e.g., challenge window or proof safety delay).

Optimistic Rollups

Most commonly used optimistic rollups (Arbitrum One, Base, OP Mainnet, etc.) currently rely on a centralized sequencer that orders L2 transactions, batches them, and posts them to the L1 (commonly Ethereum). A commitment is valid by default and can be challenged during a challenge window — typically 7 days — if it asserts an invalid state root.

Lifecycle:

1. Transaction is included in an L2 block by the sequencer.
2. The block is included in a batch posted to L1.
3. The challenge window begins (~7 days).
4. After the window, the transaction is finalized on L1 — hard finality.

In current implementations, only invalid state roots can be challenged; valid commitments cannot, assuming no implementation bugs. So an offchain observer who has independently verified the L2 state can have high confidence in a commitment as soon as it is posted to L1 and that L1 block is finalized. This is the soft finality most exchanges and cross-chain systems rely on in practice — strictly weaker than the post-challenge-window guarantee, but typically sufficient for non-adversarial flows.

ZK Rollups

ZK rollups (Starknet, zkSync Era, Linea, etc.) likewise rely on a centralized sequencer today, but accompany each batch with a validity proof that is verified onchain by the L1 (commonly Ethereum). This removes the need for a challenge window.

Lifecycle:

1. Transaction is included in an L2 block by the sequencer.
2. The block is included in a batch posted to L1.
3. A validity proof for the batch is posted and verified on L1.
4. Transaction is finalized on L1, often after an additional rollup-specific safety delay.

The safety delay varies by rollup — historically on the order of hours — and is expected to reduce over time as proof systems mature.

How CCIP Determines Finality

By default, CCIP v2 waits for full source chain finality before validating messages, producing attestations, and performing execution on the destination chain. Faster-Than-Finality is an opt-in capability that is only available when explicitly chosen. As a result, CCIP message latency depends largely on the source chain's time to finality. CCIP uses one of two methods to determine when a source-chain transaction is final.

Finality Tag

Many chains with deterministic finality expose a finality tag — a standardized signal in JSON-RPC calls that indicates which blocks are finalized.

Block Depth

When a finality tag isn't usable, CCIP instead waits for a sufficient number of successive blocks before treating a transaction as final. This applies to:

• Chains with probabilistic finality.
• Chains with deterministic finality that don't expose a finality tag.
• Chains with deterministic finality slow enough that waiting for it materially harms UX.

Risks. Block depth is a heuristic, not a guarantee. Reorgs remain possible, and anyone relying on CCIP (or any cross-chain bridge) on these chains should weigh that risk accordingly.