A Destination Confirmation Is One Step in a Cross-Chain Transfer

A destination-chain confirmation means the receiving network included a transaction in a block; by itself, it does not prove the whole cross-chain transfer is final or complete. A bridge usually has several stages: the source chain records a deposit or message, a bridge or relayer observes it, and a transaction is submitted to the destination. Each stage has its own status and transaction record. The useful question is therefore not simply “How many confirmations?” but “Which chain, which transaction, and which stage does this status describe?”

That distinction matters when a swap appears stuck. A source transaction can be confirmed while the bridge is still waiting to attest, relay, or execute it. For a separate walkthrough of the recovery steps for a stalled swap, see this guide to using an XMR bridge when a swap stalls. The general rule is to follow the transaction identifiers across both chains rather than treating one explorer’s confirmation count as a receipt for the entire route.

What does a destination-chain confirmation prove?

It proves that a particular transaction was included on the destination chain, subject to that chain’s own rules for reorganization and finality. Check the destination transaction hash in an explorer for that network, then verify its status and the relevant event or balance change. A “success” result generally means the transaction executed without a reported failure; it does not establish that the bridge’s source-side transaction was final, or that the intended asset reached the intended address.

Cross-chain systems connect these records through a message or transfer identifier. Wormhole’s Core Contracts documentation, for example, describes a message using an emitter, sequence number, and consistency level; the destination contract verifies the resulting signed message before accepting it. Other systems use different designs, so the bridge’s own status page may be useful for matching the source and destination records. A destination hash without that match can be hard to interpret: it may belong to a retry, a later step, or a different transfer.

Read the event details as well as the top-line status. Confirm the recipient, token or denomination, and amount, allowing for fees, wrapped representations, or decimal formatting. A destination transaction can succeed while delivering a representation of an asset rather than the original token, depending on how that bridge is built. The transaction record establishes what the destination chain processed; it does not make the asset’s backing or redemption terms identical across bridge designs.

How many destination confirmations should you wait for?

There is no universal count, because confirmation and finality mean different things on different chains. On Bitcoin, the developer guide describes confirmations as blocks built on top of the block containing the transaction: more blocks reduce the chance of a reorganization replacing it, but do not turn the risk into a universal fixed threshold. Ethereum distinguishes a block’s inclusion from consensus finality, which has a stronger protocol guarantee but takes longer. The number shown by an explorer may simply count later blocks, not indicate that the bridge has completed its own checks.

Bridge operators may also choose when to act on a source transaction. Wormhole’s finality documentation describes faster “instant” and “safe” settings alongside “finalized”: faster observation can reduce waiting, while increasing exposure to a source-chain reorganization. That is a design trade-off, not a destination-chain confirmation count. Once the destination transaction is included, its own chain can still have a separate period before the transaction is considered sufficiently settled for the user’s purpose.

For ordinary transfers, the most practical approach is to follow the bridge’s stated completion criteria and inspect the destination transaction after it appears. For a large or time-sensitive transfer, waiting for the destination chain’s stronger finality state may be sensible, especially if the bridge or receiving service distinguishes inclusion from final settlement. A fixed rule such as “wait six confirmations” cannot be carried from one chain to another without checking what that chain and bridge mean by confirmation.

What should you check when the transfer is pending?

Locate the source transaction first and confirm that it succeeded on the expected network. Then use the bridge’s transfer record, if available, to see whether it is awaiting source finality, attestation, relay, or destination execution. The stage names vary, but they describe different work. A delay before a destination hash exists is not the same problem as a destination transaction that failed or succeeded to an unexpected recipient.

• Match the source transaction hash and destination transaction hash to the same transfer record.
• Check the destination network, recipient address, token, amount, and transaction result.
• Look for an event showing the intended release, mint, or application action, not only a generic success label.
• If the bridge shows a timeout, failure, or pending relay, follow its recovery instructions before initiating a duplicate transfer.

This is the point where a short safety check is warranted: verify the network and address independently, and do not share a seed phrase or private key with anyone offering to “release” a pending transfer. A confirmation count cannot reverse a mistaken address or authorize a recovery service to take custody of funds.

The clearest reading is stage by stage: source inclusion, source finality or bridge acceptance, destination execution, then destination settlement. “Confirmed” is useful only when attached to the transaction and chain it describes. Watch next for a destination hash to appear, the bridge status to move beyond relay or attestation, the destination event to match the intended transfer, and the destination chain’s finality indicator to advance.