A Swap Is Not Complete When the First Chain Says Success
Tracking an omnichain swap links source confirmation to destination execution, showing route progress and why one transaction hash alone cannot prove delivery.
By The Coin Wire Editorial3 min read

Omnichain swap tracking follows a trade across its source chain, any message or bridge layer, and its destination chain until the expected tokens arrive or the route reaches another terminal outcome. A normal swap usually leaves one transaction to inspect: the chain records whether the trade executed and what it returned. A cross-chain route can involve several transactions and off-chain coordination, so a successful first transaction means the source leg completed, not necessarily that the destination swap did.
A tracker joins those separate records into one route view. It may begin with the source transaction hash, then use a route ID or message identifier to find the corresponding destination activity. That connection matters because a destination transaction has its own hash; it is not simply a continuation of the source hash. For the practical steps before submission, see planning an omnichain swap from wallet to receipt. The tracking view becomes useful once the wallet has submitted the first leg.
What does a swap tracker actually follow?
A tracker follows evidence from each stage rather than treating a route as one indivisible transaction. It checks whether the source transaction was included and succeeded, whether the cross-chain message was observed or relayed, and whether the destination action ran. Depending on the design, the destination action may swap the delivered asset, release it to the recipient, or require a separate claim.
The interface often compresses these steps into labels such as pending, in progress, completed, or failed. Those labels are summaries, not proof by themselves. A useful record should show the chain and hash for each on-chain leg, the intended recipient, the input and output assets, and enough status detail to distinguish a confirmed source deposit from a completed destination delivery.
Why can the first transaction succeed while the swap remains open?
Because confirmation on one chain does not execute the next step on another. After the source transaction is final enough for the route’s rules, a bridge, relayer, validator set, or other coordinating mechanism must carry or attest to the instruction. The destination chain then processes its own transaction. Congestion, message delays, a failed destination call, or a route-specific recovery process can leave the overall swap unfinished even though the source explorer shows success.
That is the main difference from a single-chain swap, where one receipt usually answers whether the trade ran. It is also why a generic block explorer is only part of the picture: it can verify a transaction on its own chain, but it may not identify which later transaction belongs to the same route. A tracker or protocol status page supplies that cross-chain association, while each chain’s explorer remains the place to verify its local record.
How should a reader interpret the final status?
Look for destination execution and the actual asset delivered to the intended wallet. A completed status should correspond to a destination transaction or other verifiable receipt; the displayed output can still differ from the quote because of fees, slippage, or a fallback path. If a route fails after the source leg, the outcome may be a refund, a claimable asset, or a manual recovery process, depending on its design.
- Save the source transaction hash and route or order identifier shown by the app.
- Check the source-chain receipt first, then follow the linked destination record.
- Confirm the recipient, token contract or asset, and received amount on the destination chain.
- If status stalls, use the route’s stated recovery path and share its identifier with support; do not submit a duplicate swap simply because the tracker has not updated.
For most users, the best measure of completion is the destination receipt and balance, with the tracker serving as the map between them. The signals to watch are whether the source transaction is confirmed, whether its message has been relayed, and whether the destination transaction has executed or entered a defined recovery state. A single green indicator without those links tells less than the route’s chain-by-chain record.