Cross-chain swaps need a defined release point

Cross-chain swaps should release destination assets only after the source leg meets the route’s stated finality rule. The rule should specify what evidence counts as final, who verifies it and what happens if the source chain reorganizes before settlement.

That release point determines whether the swap’s recipient can spend funds against a source transfer that might still be reversed.

When is the source leg final enough to release?

The source leg is final enough when the settlement system has observed the chain’s defined finality signal, or the required confirmation depth where no usable finality signal exists. A transaction appearing in a block proves inclusion, not irreversibility. On probabilistic-finality chains, additional blocks lower reorganization risk but do not make it zero; on chains with deterministic finality, the protocol’s finalized status is a stronger release condition.

This distinction matters in routes that lock tokens on one chain and mint or transfer the corresponding value on another. If destination funds become spendable before the source lock is final, a source reorganization can leave the route short. A route may instead wait for finality, delaying settlement, or accept a defined residual risk to reduce latency. For a fuller account of wallet-based routing and swaps, see this Biswap bridge and wallet-swap explainer; the same question applies to its source-side settlement evidence.

How do confirmations and finality differ?

Confirmations count blocks built after the transaction’s block; finality describes the chain’s rule for when that transaction can no longer be reverted under normal consensus operation. A configured block depth is a risk threshold, not a guarantee. Its meaning depends on the source chain’s consensus and reorganization profile, so a single confirmation count cannot safely be copied across networks.

Cross-chain messaging systems expose this trade-off in their settlement settings. Chainlink’s CCIP documentation, for example, describes waiting for full source-chain finality by default, while also supporting configurable confirmation depth in some paths. That illustrates the choice: a shorter threshold improves latency while accepting more reorganization exposure. The application should also check whether the route’s verifier and destination contract enforce the same threshold the interface displays.

What should a safe release rule include?

A release rule should tie destination execution to verifiable source evidence and define a failure path for delays, reorgs and expired orders. In a hash-time-locked swap, the recipient claims with a secret that enables the counterparty to claim on the other chain; timelocks provide a refund path if the claim does not happen. The lock periods must leave time for the claim and refund sequence to complete across both chains.

• Identify the source transaction and the exact event or state proof that authorizes release.
• Use the source chain’s finality signal where available; otherwise set a chain-specific confirmation threshold.
• Keep destination execution and any refund path bound to the same order and expiry conditions.
• For faster-than-final settlement, define who absorbs a reorg loss and cap exposure by value or duration.

For most users, the safer default is to wait for the route’s documented finality condition before treating destination funds as settled. Faster release can be reasonable when a route explicitly prices and limits the remaining risk, but a fast interface update alone is not evidence that the source transfer is irreversible.