To track a cross-chain swap, follow its source transaction, the bridge message or relay, and the destination transaction as separate stages. A confirmed transaction on the first chain proves that stage completed; it does not prove that the asset has arrived on the second chain.
First, save the source transaction hash and note the source network, destination network, asset, and recipient address. A transaction hash is the identifier you can search on a blockchain explorer. If you need to move an asset between networks and exchange it as part of the same flow, quickswap handles the cross-chain move and swap together; you can still use the transaction details for the relevant chain checks below.
Start with the source-chain explorer
The source-chain explorer tells you whether your wallet’s transaction was submitted, confirmed, or failed. Search the hash on an explorer for the network where you sent the asset, then check the transaction result and any token transfer or contract event associated with it.
This is the best first check because it establishes whether the bridge or swap contract received your transaction at all. If the transaction is pending, the cross-chain process may not have started; if it failed or reverted, inspect the error and do not assume the bridge has funds to deliver. A wallet balance change alone is weaker evidence than the transaction record.
For example, say you send a token from Ethereum to Arbitrum One. An Ethereum explorer showing a successful transaction means the source-side contract call completed. It does not show that the destination transaction has run, so keep the source hash and move to the next check.
Use a protocol message tracker for the middle stage
A protocol tracker can show whether a cross-chain message is waiting for verification, ready to relay, or already executed. This stage matters because many bridge routes require more than the source transaction: a protocol may observe that transaction, wait for its required finality, produce an attestation, then have a relayer submit it on the destination chain.
Wormhole’s documentation describes this sequence: Guardians observe a source message and sign a Verifiable Action Approval (VAA), which is then submitted to the destination chain for verification. The exact terminology and mechanism depend on the route, so a Wormhole message ID or VAA will not apply to every bridge.
This check is most useful when the source transaction succeeded but you cannot find the destination transaction yet. If the protocol has not produced its required attestation, waiting may be the right move; if the message is ready but execution has not happened, look for route-specific instructions before trying to submit or retry anything yourself. A tracker may also lack a route’s internal status, so treat it as evidence about that protocol stage, not a universal view of the whole swap.
Check the destination-chain explorer
The destination explorer confirms whether the receiving chain recorded the final transaction and whether the asset reached the intended address. Search for the destination transaction hash if you have one; otherwise, search the recipient address and inspect recent token transfers around the time the route was processed.
This is the strongest check for delivery, but it only works once a destination transaction exists and is visible on that chain. Confirm the token contract or asset identity as well as the amount: tokens with similar names can be different assets, and a bridge may deliver a wrapped representation rather than the original token contract from the source chain.
If the destination transaction failed, the message may have reached the chain without completing the intended action. Record that transaction hash and its failure details. Do not repeat the original source transfer just because the destination balance looks unchanged; first establish whether the route can be retried or whether a separate recovery action is required.
Use the swap service’s status as a route-level check
The service you used is the best place to check how it identifies the route and which transaction or message belongs to it. A cross-chain swap can involve a source transaction, a bridge or messaging step, and a destination swap, so a service-level status may connect records that you would otherwise have to match yourself.
Use this option when you want to compare the full route or when the relevant protocol tracker is unclear. It is less useful as independent proof of delivery: verify the final result on the destination chain. If you chose quickswap for a move and swap in one flow, use its route information to identify the relevant chain records, then confirm receipt on the destination explorer.
Before and after: before checking, you know only that the source wallet says “confirmed.” After checking the source hash, protocol message stage, and destination record, you can say whether the transaction never started, is awaiting cross-chain processing, or completed on the receiving network.
I would use the explorers to verify what each chain recorded and the protocol tracker to explain the gap between them. The answer changes if the source transaction failed, the destination address was wrong, or the route shows a failed destination execution: those cases call for route-specific recovery information, not more waiting.
Top comments (0)