A field guide to cross-chain finality models

If you read three cross-chain whitepapers, you will encounter the word “finality” used in five different senses. Sometimes the senses contradict each other. This post tries to draw the map, then explains how Switchboard picks a finality model per route — which is where most of the practical decisions actually happen.

The five senses

1. Probabilistic finality. A transaction is considered final after enough blocks have been built on top of it that reorging would cost an attacker more than the attack is worth. This is the Bitcoin / Ethereum-pre-PoS sense. It is well-defined and easy to reason about; the cost is that you have to pick a confirmation depth, and the depth is a function of the value at risk and the current hash rate.

2. Economic finality. A transaction is final once reorging would require destroying so much staked capital that no rational actor would do it. Ethereum post-PoS uses this — the “supermajority finality” achieved by 2/3 of validators within roughly 12.8 minutes. Different from probabilistic finality because the bound is economic rather than computational.

3. Deterministic finality. A transaction is final once the consensus protocol commits to it, full stop, with no further rollback possible. Tendermint-family chains have this: once a block is committed by a 2/3 quorum, it cannot be reverted. Solana also has a strong form of this after a slot is “rooted.”

4. Sequenced finality. A transaction is final because a single trusted sequencer says so. Almost all current Ethereum L2s have this as their fast-path. The sequencer’s word is good enough for most product flows; users wait for L1 confirmation only when bridging out of the L2.

5. Light-client finality. A transaction is final on chain A because chain B can verify a light-client proof that the transaction was included and confirmed on chain A. This is the model IBC uses, and the model Switchboard prefers when the destination chain supports it.

Most cross-chain bugs come from confusing two of these for each other.

What “final” means for cross-chain messaging

A cross-chain message has to make a finality choice at three points:

1. Source-side: at what confirmation depth on the source chain do we commit to the coordinator? Too shallow and you risk reorging your own messages; too deep and you eat latency you did not need to eat.
2. Coordinator-side: how do we verify the coordinator’s own finality? This is where the coordinator chain choice matters.
3. Destination-side: how does the destination chain verify the coordinator state? Light-client proof, threshold signature, zk-proof — depends on the chain.

Different bridges pick different defaults. We will walk through ours.

Switchboard’s defaults

Source confirmation. We pick per-chain depth based on the source chain’s finality model:

• Ethereum: 2 blocks for non-financial routes, 32 blocks (epoch finality) for routes flagged high-value.
• Solana: 1 confirmed slot, 32 rooted slots for high-value.
• L2s (Arbitrum, Base, Optimism): 1 block sequencer confirmation for non-financial, wait for L1 inclusion proof for high-value.
• BSC, Polygon: 12 blocks for safety, 36 for high-value.

These are policy choices, not consensus claims. You can override them per route. We will tell you if you have picked something dangerous.

Coordinator finality. We use Solana’s “confirmed” commitment level for the coordinator commit, and “rooted” for the destination verification. The gap between confirmed and rooted is the window where a Solana reorg could in principle invalidate a message — but the coordinator program is designed to reject conflicting commits, so the worst case is a delayed message, not a duplicated one.

Destination verification. We pick the strongest available model per chain:

• EVM chains with deployed Solana light clients: native verification of the Solana slot proof.
• EVM chains without light clients: BLS threshold signature from the Switchboard relayer pool (7 of 11 signers).
• Solana destinations: direct read of the coordinator program state.
• Move chains (Sui, Aptos): BLS threshold signature; light clients are roadmap.
• Cosmos chains: IBC connection where available, BLS otherwise.

The BLS threshold pool is its own trust assumption. We are explicit about it in the docs. Customers with strict trust requirements can configure routes to require light-client verification only, falling back to “route unavailable” rather than the threshold path.

The fail-* policies, in detail

When something goes wrong — a coordinator chain halt, a destination chain reorg, a verifier rejection — Switchboard does not get to make the call for you. The route declares its policy at registration time.

fail-closed is the default. If the coordinator state cannot be confirmed within the timeout, the destination chain rejects the message. The source chain’s state remains as if the message was never sent. Suitable for: financial transfers, governance messages, anything where consistency is more important than liveness.

fail-open uses the most recent confirmed coordinator state and continues. The risk: if the coordinator was about to reorg, you may apply a state that gets retracted, and you are responsible for handling the rollback. Suitable for: real-time game state, analytics, anything where stale-but-available beats unavailable-and-correct.

fallback switches to a secondary verifier. For most routes that means falling back from light-client to BLS threshold, which is a slight degradation of trust but maintains liveness. Suitable for: high-availability routes where degraded security is acceptable but downtime is not.

The choice is per-route, per-direction. You can set eth → arbitrum to fail-closed and eth → arbitrum-game-server to fail-open and they will behave independently.

What we will not do

We will not silently change a route’s finality policy. If a chain operator deploys a new light client and we would prefer to use it, we propose the change, customers approve, and we cut over with an audit trail.

We will not pretend the verifier choices are equivalent. A light-client proof and a BLS threshold signature are different trust models. We document the differences. We do not let marketing collapse them into one.

We will not claim “deterministic finality” on a chain that only offers probabilistic or economic finality, even if the marketing department would like us to. Finality is a property of the underlying chain. We can verify what is there; we cannot create finality that the chain does not have.

A practical example

Suppose you are running a perp DEX with the orderbook on Arbitrum, collateral on Ethereum, and a satellite UI on Base. You probably want:

• Liquidation flow (Eth → Arb): fail-closed. If we cannot confirm coordinator state, do not seize collateral; user can be liquidated on the next attempt.
• Position update propagation (Arb → Base): fail-open. Slightly stale state on the UI is fine; downtime on the UI is bad.
• Withdrawal (Eth → user): fail-closed with the high-value flag, so we wait for 32-block finality on Ethereum.

That is three different finality contracts, all on top of one Switchboard integration. The flexibility is the entire point. The defaults are good, the overrides are honest, and the failure modes are written down.

The takeaway

Finality is not a single number you put on a chart. It is a contract between you, the bridge, and the chains involved, and the right contract depends on what your application can tolerate. Switchboard’s job is to expose the choices honestly and let you pick — not to ship a single “best” answer and call it done.

If you are about to deploy something cross-chain and you are not sure which finality model you actually need, the SDK has a simulate-finality command that walks through the worst-case scenarios for your route configuration. We added it because customers asked for it. It catches bad assumptions before they cost real money.