Track a Cross-Chain Swap from Deposit to Delivery

Track a cross-chain swap by following its source transaction into the route’s bridge or message status, then verifying the destination transaction and token balance. The source-chain hash identifies the transaction you submitted; it does not, by itself, prove that the destination action ran. A route may lock or burn the input token, relay a message or liquidity claim, and then release, mint or swap tokens on another chain. Each step can have its own transaction, confirmation threshold and failure state.

Before submitting, record the origin and destination chains, input and output tokens, recipient address, quoted minimum output and route name. Save the source transaction hash and, if the interface provides one, the route’s order or message ID. Those identifiers help connect activity across separate ledgers. A comparison of Biswap route types and how they fit different swap paths gives more detail on why a route’s design affects what evidence its tracker can show.

What should you check after submitting the swap?

First, check the source transaction on the explorer for the chain where you signed it. Confirm that the transaction was included and that its execution succeeded. A wallet’s “submitted” message only means it sent the transaction to a node. A pending transaction may still be replaced, dropped or reverted; a reverted transaction did not complete the contract call, even if it appears in a block.

For a successful transaction, inspect the logs or token transfers to confirm that the intended contract interaction occurred. Depending on the route, the input may be transferred to a pool, locked in a bridge contract, burned, or sent to a router that starts several operations. Match the chain, token contract and amount against the quote. A familiar token symbol is not enough: symbols can be reused, and the same asset can have different contract addresses on different chains.

Then open the swap interface’s activity record or the route provider’s tracker, using the source hash or order ID it requests. A bridge or messaging system may index the source event before the destination transaction exists. If the tracker cannot find the transfer immediately, check that you chose the correct source chain and copied the full hash, then allow for indexing delay. An empty result is not proof of a failed transaction.

How do you tell whether the swap has arrived?

Arrival means the destination-side operation has executed for the intended recipient, not merely that the source deposit was accepted. Follow the tracker until it provides a destination transaction hash or an equivalent completed state. Open that hash on the destination-chain explorer and check its execution result, recipient and token transfers. Finally, check the recipient’s balance on that chain, using the correct token contract.

Routes can deliver different assets or amounts from the source input. A bridge may first deliver an intermediate token, with a separate swap converting it to the requested output. Some routes use liquidity providers to send destination funds before the source transaction reaches its final settlement conditions; others wait for a message or proof to be processed. In either case, an early destination transfer is evidence of delivery under that route’s rules, while later settlement can remain pending.

Read status labels as descriptions of a particular route’s state machine, not as universal protocol terms. “Processing” commonly means the source step was detected while destination execution remains outstanding. “Completed” should correspond to a destination-side result, but verify the transaction when funds matter. “Refund pending” means a return path may still need to execute. “Refunded” should have a corresponding refund transaction or balance change. A route may also complete by delivering the bridge asset after a destination swap fails, so compare the received token with the quoted output before treating the requested swap as fulfilled.

What should you do when the tracker stays pending?

Use the last confirmed event to locate the delay. If the source transaction is pending or reverted, the route has not established a successful deposit. If it succeeded but the tracker shows no source event, confirm the hash, chain and route before taking another action. If the source event is recorded and the destination hash is absent, the transfer is between stages; consult the route’s official status page or documentation for that route’s required confirmations, claim step or recovery process.

• Source success, no destination hash: keep the order ID and source hash; check the route’s tracker for a pending relay, message or claim.
• Destination transaction reverted: inspect the route’s status for a fallback delivery or refund. Do not assume the original input is already back.
• Destination hash succeeded, balance missing: verify the recipient address, destination network and token contract. The wallet may not display an unfamiliar token automatically.
• Tracker and explorer disagree: treat the chain’s transaction record as evidence of execution and the tracker as route-level interpretation; check both again before retrying.

Do not submit a second swap just because the interface still spins. The first route may be processing, and a duplicate can create a separate transfer rather than speed up the original. Preserve the source hash, route or order ID, destination chain, recipient and any refund hash if you contact support. The practical rule is simple: source success proves the first on-chain step; destination execution and the resulting asset prove arrival.