A confirmation is not the same as cross-chain finality

A confirmation shows that a transaction has been included in a block; finality means the network has made that block difficult or, under its rules, exceptionally costly to reverse. For a cross-chain swap integrator, the difference determines when a deposit can safely trigger an outbound payment. Treating both states as “done” hides the central risk: the source transaction can still be reorganised, delayed, or rejected while the destination leg is already being prepared.

What does a transaction confirmation tell an integrator?

A confirmation is evidence of inclusion, not a universal guarantee of permanence. On a chain where forks can replace recent blocks, each block built on top of the transaction raises confidence that it will remain in the canonical history. A service that waits for more confirmations is buying down reorganisation risk, but it is not crossing a protocol-defined line from reversible to irreversible.

Networks with explicit finality rules offer a different signal. On proof-of-stake Ethereum, validators vote on checkpoints; once the required supermajority links checkpoints, earlier blocks become finalized. Reversing a finalized block would require a severe consensus failure and substantial economic penalties. That is a stronger settlement signal than simply counting blocks, though it still describes the source chain’s consensus, not the safety of every system that observes it.

These models create a practical trade-off. A short confirmation threshold gives faster quotes and less waiting, but exposes the integrator to more risk from a source-chain reorganisation. A deeper threshold reduces that exposure at the cost of slower service and more time in which a user’s funds are committed without the swap completing. Explicit finality can give a clearer trigger, but may take longer than a service’s target response time. The right threshold depends on the chain, transaction value, and what the route does after observing the deposit.

Why does a cross-chain swap need two settlement checks?

A cross-chain swap is a sequence of events across separate networks, not one atomic transaction with a single shared confirmation count. A source-chain deposit may be observed by a vault, validator set, or other route component; a later action then releases or sends the destination asset. The source can be settled while the destination transaction is still pending, and a successful source transfer does not itself prove that the user received the output.

This is why an integrator should track at least two state machines: whether the source deposit is accepted under the route’s rules, and whether the destination payment has reached the required state. A route may also rely on operators or signers to recognize the deposit. That introduces a separate trust and availability question: consensus finality protects the chain’s history, while route design determines who can act on that history and what happens if they fail to act.

For a fuller look at the route-level checks that sit around these settlement states, see thor swap. The key point for integrators is to avoid presenting “deposit seen,” “deposit accepted,” and “swap completed” as interchangeable user-facing statuses. Each marks a different event, with different recovery options if the route stalls.

Alternative designs shift rather than erase the trade-off. A service can wait for stronger source-chain confidence before authorizing the destination leg, improving safety but adding latency. It can provide liquidity before final settlement to make delivery feel faster, but then someone bears the cost if the source deposit disappears or proves invalid. A route with a longer challenge or dispute window can provide another verification period, while delaying the point at which funds are fully settled. Integrators should describe which party carries each risk instead of collapsing the route into one “confirmed” badge.

How should an integrator choose a release threshold?

Set the release rule from the route’s failure costs and trust assumptions, then make the rule visible in the system’s state transitions. A fixed block count may be a useful policy on a chain without deterministic finality, but it should be calibrated to that chain’s reorganisation behavior and the value at risk. On a chain with explicit finality, use the finalized status where the route can tolerate its timing; if the route acts earlier, label that decision as an earlier acceptance policy, not finality.

In practical terms, a robust integration separates four questions:

• Has the deposit appeared in a block the integrator recognizes?
• Has it met the route’s confirmation or finality threshold?
• Has the route authorized or submitted the destination transfer?
• Has the destination transfer reached its own required settlement state?

These states also make retries safer. If a client times out after a destination transaction is broadcast, it should query the transaction and route state before submitting another payment. Otherwise, a delay that looks like failure can become a duplicate payout. The interface can stay concise, but its internal records should retain the source transaction, threshold decision, route action, and destination transaction as separate events.

What signals should swap teams watch next?

Watch for changes in how each chain exposes its consensus status, and how route operators translate that status into an action. A rise in reorganisation depth, delayed finalization, or a backlog in destination execution can turn a previously acceptable threshold into a poor fit. Monitor the age of deposits awaiting release, the time between source acceptance and destination submission, and the frequency of manual recovery. These measures show whether the bottleneck is chain settlement or the route between chains.

For most integrators, the sound default is to wait for the strongest practical source signal the route supports, then separately verify destination settlement before marking a swap complete. Faster acceptance can be justified where the route explicitly absorbs the extra risk and communicates that policy. The signals worth watching are not just confirmation counts, but finality status, route authorization, destination execution, and the gap between them.