Skip to content
ChainBrief

News from across Web3

How to Verify a Cross-Chain Swap From Your Wallet

A wallet can show the source transaction as successful while the cross-chain swap is still pending; verify the destination fill, token contract and received amount.

The ChainBrief Editors

How to Verify a Cross-Chain Swap From Your Wallet

A cross-chain swap creates a record on the source chain and a separate outcome on the destination, so checking the first transaction alone does not confirm that the swap is complete. Start with the source transaction hash, then verify that the expected token reached the intended address on the destination network.

This two-chain check separates a successful deposit from a completed swap and helps pinpoint where a transfer is waiting.

What does a successful source transaction confirm?

It confirms only what happened on the source chain. Ethereum.org says a block explorer can show a transaction’s status, block, sender, recipient or contract, and token transfers; use the explorer for the source network to check those fields against the wallet’s transaction details. A successful status means that transaction executed, but it does not by itself establish that a second-chain action has finished.

Cross-chain routes can handle delivery differently. Across’s documentation describes an intent flow in which the source deposit is recorded first, a relayer fills it on the destination chain, and settlement follows afterward. Other bridge designs may validate a deposit and then send or mint the destination asset, as MetaMask’s bridge guide explains. That is why the wallet’s source-side “success” and the route’s final status can differ.

How do you check the destination-side result?

Find the route’s status view or tracker from the wallet or swap interface, and compare its destination transaction hash with the destination chain’s explorer. Across, for example, documents a deposit status endpoint that can return a fill transaction hash when a deposit has been filled. A pending state means the source deposit may be recorded while destination delivery is outstanding; a filled state should correspond to a destination transaction you can inspect.

Check that the destination transaction involves the intended recipient and output token, then compare the amount received with the route quote. Confirm the token by its contract address on that chain, not just its ticker or display name: token symbols can be reused, and a wallet may not display an asset until it has been added. MetaMask’s support guidance also directs users to check transaction activity and use a block explorer to verify balances and transfers.

If you are still comparing routes, this guide to quickswap routes for cross-chain trades answers which route type fits a trade. Once you choose a route, keep its quoted output and destination details available while checking the records; the route’s tracker can explain its own pending and completed states.

What should you compare before calling it complete?

Use the same four checks regardless of whether the route uses a relayer, liquidity pool or another bridge mechanism. The route’s own status terminology may vary, so treat the destination chain’s transaction record and asset transfer as the evidence of delivery.

  • Source explorer: transaction succeeded and the sender, input amount and route contract match the wallet action.
  • Route tracker: status is complete, or its documentation identifies the next action or an expired transfer.
  • Destination explorer: the transaction is confirmed and the recipient is the address you specified.
  • Token and amount: the destination contract is the intended asset, and the received quantity matches the route’s quoted output after its stated fees.

If the destination transfer is absent, do not repeat the swap just because the wallet balance has not changed. Check whether the route reports pending, expired or refunded, and follow that route’s documented recovery process. If the transfer appears on the explorer but not in the wallet, verify the selected network and token contract before concluding that delivery failed.