Set Cross-Chain Finality Thresholds by Chain and Risk

Set a cross-chain transfer’s finality threshold by matching the source chain’s settlement signal to the value and reversibility of the transfer. A fixed number of confirmations is easy to operate, but it treats a chain with probabilistic finality like one that publishes an explicit finalized state. The better rule is chain-specific: accept a protocol finality signal where the bridge can verify it, and use block depth only when that signal is unavailable or too slow for the service.

That distinction separates a transaction being included from being safe to act on. A wallet can show a source transaction as confirmed while the bridge is still waiting for enough evidence to release funds on the destination. In an acrossbridge transfer, this wait is part of the security design, not just interface lag. For a pending deposit, the Across bridge path for a pending transfer explains how the transfer type affects what its status means.

What should a finality threshold measure?

A threshold should measure the source chain’s resistance to reversing the deposit, not simply the time since it was broadcast. On chains with probabilistic finality, each new block makes a reorganization less likely, but does not create a binary finality event. A bridge can therefore require a chosen block depth: it waits for a specified number of blocks after the deposit before treating it as settled.

On chains with deterministic or protocol-defined finality, the chain may expose a finalized block or equivalent consensus signal. Ethereum proof of stake, for example, finalizes checkpoints through validator votes; a finalized block has a stronger status than a recent block that is merely part of the current head. A bridge that can verify this signal can use it directly instead of translating it into an arbitrary confirmation count.

These measures are not interchangeable. “Six confirmations” means little without knowing the chain’s block cadence, consensus rules, and reorganization history. A finalized tag also says only what the underlying chain’s protocol guarantees; it does not prove the bridge’s verifier, message handling, or destination contract is correct. Thresholds must fit the entire transfer path.

How should the threshold differ by chain and transfer?

Use the strongest verifiable source-chain signal that meets the transfer’s acceptable delay. Where an explicit finality signal is available and practical to verify, wait for it. Where it is not, choose block depth according to the chain’s reorganization risk and the consequence of acting on a deposit that is later removed.

That consequence varies. A small, reversible action may justify a shorter wait than releasing a large amount into a destination contract that cannot claw it back. A bridge that fronts liquidity before source finality has a different exposure again: the relayer or liquidity provider is advancing funds against a deposit that might not settle. Faster delivery shifts risk onto that intermediary; it does not make the source transaction more final.

A practical policy can set tiers rather than one universal number:

• Routine transfers: wait for the chain’s finalized signal, or the bridge’s established block-depth threshold where no usable signal exists.
• High-value transfers: require the strongest available finality evidence and consider additional operational checks before releasing funds.
• Fast, liquidity-fronted transfers: distinguish the early destination delivery from final settlement and define who bears loss if the source deposit is reversed.
• Congested or unstable periods: raise the threshold or pause transfers if reorganization signals or finality delays exceed policy limits.

The tiers should be based on exposure, not token price alone. Consider the amount, how quickly the destination funds can be spent, whether the transfer can be reversed, and who absorbs a failure. A fixed block count can remain the operational default, but it should be calibrated per chain and reviewed when consensus or bridge verification changes.

What is the trade-off between block depth and protocol finality?

Block depth is portable and simple to explain, but it is a heuristic: more blocks generally reduce reorganization risk while increasing latency, and no single depth means the same thing on every network. Protocol finality provides a chain-native settlement signal, but it may take longer, may stop progressing during a consensus fault, and still depends on correct verification by the bridge.

Using a short depth can improve user experience and reduce the time capital sits idle. It also leaves more room for a reorganization to invalidate the deposit after the destination side has acted. Waiting for full finality reduces that exposure, but delays delivery and can make the bridge less useful for time-sensitive activity. Across products, the fastest route may be an early fill backed by a relayer, while a direct message flow may wait for source finality before execution. The user sees similar destination outcomes, but the timing and risk allocation differ.

Make the policy explicit in the transfer state. “Submitted,” “included,” “source finalized,” and “destination settled” describe different milestones. A single “confirmed” label hides whether the bridge is still waiting, has relied on a depth heuristic, or has already released funds against an unsettled deposit.

Which signals should operators watch next?

Operators should track finality delay, reorganization depth, verifier health, and the gap between source settlement and destination execution. A rising finality delay may be a reason to slow transfers even if blocks continue arriving. A reorganization that exceeds the configured depth is evidence to reassess the threshold, not an edge case to ignore.

Review thresholds when a chain changes consensus behavior, adds a usable finality signal, or shows a different reorganization pattern. Also watch how often liquidity providers front transfers before settlement and how long they remain exposed. The sound default is to wait for protocol finality where it is verifiable and workable, use calibrated block depth where it is not, and make any faster path’s risk owner clear.