A Confirmed Source Transaction Does Not Complete a Cross-Chain Swap

A confirmed source transaction proves that the origin chain accepted the transaction; it does not prove that the destination chain completed the swap. A cross-chain swap has at least two distinct outcomes: moving value between chains and exchanging that value for the requested asset. The first can succeed while the second is delayed, rejected or left pending.

This distinction matters because interfaces often present a single action as “swap” or “bridge and swap.” Underneath, a source transaction triggers a process that may involve a bridge, a relayer or proof system, and a destination-chain transaction. Each component has its own state. A source-chain explorer can confirm the transaction that started the process, but it cannot establish that destination funds arrived or that an exchange executed.

What does source-chain confirmation prove?

Source-chain confirmation proves that the transaction was included under that chain’s consensus rules and reached the confirmation threshold used by the application. It is evidence for the origin step, not a receipt for the destination step. The threshold and the meaning of “confirmed” depend on the chain and the protocol’s assumptions about reorganization risk.

After inclusion, the bridge mechanism must make the source event available to the destination. A relayer may submit a message or proof. A verifier or set of validators may attest to the event. The destination contract then checks the required evidence and applies the message. These are different designs, but they share the same boundary: source-chain confirmation supplies input to the cross-chain process; destination-side verification and execution determine whether that process advances.

A bridge-and-swap interface can hide this sequence behind one request. The Biswap cross-chain move-and-swap flow is a useful reference for the combined-action model, where transfer and exchange are presented as parts of one route. The key diagnostic remains the same: identify which transaction the status refers to. “Confirmed” may describe the source deposit or message, while the destination swap still awaits execution.

Why can the swap remain pending after confirmation?

The swap can remain pending because source inclusion is only an early state in a multi-step route. A relayer may not yet have submitted the destination transaction. The destination chain may be congested, or the transaction may need a proof, challenge period or other protocol-specific condition before it can execute. A visible pause does not by itself show whether the process is progressing or has failed.

Even after the bridge releases or credits value on the destination, the exchange can fail independently. A destination contract may enforce a minimum output, often called minAmountOut, to bound the effect of price movement and execution conditions. If available liquidity or the quoted price no longer satisfies that limit, the swap can revert rather than deliver less than the user accepted. Other route constraints, such as expired parameters or a paused contract, can also prevent execution. The exact conditions depend on the contracts used by that route.

Some systems separate delivery and exchange into separate destination transactions. In that design, the bridged asset may be available even though the swap has not completed. Other systems make delivery and exchange part of one destination execution, so a swap failure may revert that execution or leave recovery to a protocol-specific path. A status page that compresses these states into “pending” or “failed” can obscure the difference. The useful question is whether the destination contract has received the message, whether the asset was credited, and whether the swap call ran.

Read the status as a sequence of checkpoints:

• Source transaction: Was the origin transaction included, and does its event identify the intended route?
• Cross-chain message: Has the protocol relayed or verified that event on the destination?
• Destination delivery: Was the bridged asset released or credited to the expected address?
• Swap execution: Did the destination exchange produce the requested asset and satisfy the route’s output condition?

How should you diagnose a confirmed but unfinished route?

Diagnose the route by matching evidence to each checkpoint, rather than treating one confirmation as proof of end-to-end completion. Start with the source transaction hash and confirm its status on the source chain. Then use the route’s own status view or message identifier to find the destination transaction. A source-chain explorer cannot show a destination contract call that has not yet been submitted.

If the destination transaction exists, inspect its receipt and events. A successful receipt may show that the bridge message executed, but check whether the swap also ran and which asset was delivered. A reverted receipt points to destination execution failure; the revert reason or protocol status may distinguish a failed output condition from an unrelated contract error. If there is no destination transaction, the route may still be waiting for relay, verification or another protocol step.

Do not resubmit the same route simply because the source transaction is confirmed. A retry can create a second transfer if the first route is still active, and some protocols require a specific recovery or claim method after a failed destination call. Check whether the route provides a retry, claim or refund state, and whether it requires user action. The right next step depends on the message’s current state and the bridge’s recovery rules.

The practical rule is simple: source confirmation means the route started successfully at its origin. Completion requires destination evidence. Treat bridge delivery and the requested swap as separate checks, and use the destination receipt or protocol status to establish which one has actually finished.