A Pending Cross-Chain Swap Has More Than One Status

To check a pending cross-chain swap, trace its source transaction, message or bridge status, and destination transaction in that order. A single-chain swap usually has one transaction to inspect: it either lands or fails on that network. A cross-chain swap adds steps between networks, so a successful source transaction does not by itself mean the destination tokens have arrived. The useful question is not simply “Is it pending?” but “Which part is pending?”

What does “pending” mean in a cross-chain swap?

It means the swap has not reached a confirmed final outcome, but the funds may already have left the source wallet. First, check the source transaction hash in the explorer for the network where you started the swap. If the transaction is still pending there, the request has not yet been included in a block. If it reverted, the source-chain execution failed; check the wallet balance and transaction details before trying again.

If the source transaction succeeded, look for evidence that the bridge or messaging step has progressed. Some routes transfer assets through a liquidity provider; others send a message that must be verified and executed on the destination chain. That creates statuses such as sent, verified, in flight, or delivered, though the exact labels differ. A status can also jump ahead between checks, so an absent intermediate label does not necessarily mean the transaction skipped required work.

Route choice shapes what happens next. A route using destination-side liquidity may complete differently from one that waits for a message to be verified and executed. For a closer look at how developers choose a Biswap cross-chain route, see the fuller discussion of the trade-offs; for a pending swap, the practical point is to identify which route and provider handled it before interpreting a status.

How do you trace the swap from source to destination?

Start with the transaction hash shown by the swap interface, and confirm that it belongs to the source network and wallet address you used. Then use the swap service’s transaction page or the relevant bridge or messaging explorer to find the cross-chain record. Finally, verify the outcome on the destination network. Each view answers a different question: the source explorer shows whether the transaction landed, a route tracker may show whether the bridge step is progressing, and the destination explorer shows whether a receiving transaction executed.

• Check the source receipt. Confirm whether the transaction is pending, succeeded, or reverted. A submitted transaction is not proof that the route has started.
• Find the route record. Use the swap’s status page or the specific provider’s tracker. Match the source hash, token, destination chain, and recipient where those details are available.
• Inspect destination execution. If a destination hash appears, open it in that chain’s explorer and check its result. A transaction hash can refer to a failed attempt, so the hash alone is not proof of delivery.
• Compare the received amount. Once the destination transaction succeeds, check the wallet balance and the settled amount. It can differ from the quote because prices and route costs may change during execution.

A route-specific tracker is usually more informative than checking only the destination wallet: it can show that the message is still being verified even though no destination transfer exists yet. A general swap page can be easier to use, but it may compress several underlying stages into one label. The chain explorers provide direct transaction evidence, but they do not always connect the source and destination transactions for you. Use the tracker to follow the journey and explorers to confirm each on-chain event.

When should you wait, and when should you act?

Wait while the source transaction is unconfirmed or the route tracker shows active verification, execution, or recovery. The source chain, bridge mechanism, and destination chain have different confirmation and execution requirements, so one fixed wait time does not fit every route. Refresh the tracker after a reasonable interval rather than treating a quiet screen as proof of failure. If the source transaction succeeded but the route record is missing, check that you selected the right network and that you entered the source hash correctly.

Act when a tracker identifies a failed stage, a destination execution error, or a recovery process. Read the route’s instructions before retrying or submitting a manual action. A second swap can create a second transfer while the first is still in flight. If the interface offers a retry, refund, or claim, confirm that the instruction matches the transaction and use the official route interface. Never share a recovery phrase or approve an unrelated wallet request to “release” a pending transfer.

Compared with a single-network swap, the extra visibility of a cross-chain tracker comes with an extra dependency: its status is an interpretation of events across chains and services. The on-chain receipts remain the clearest evidence for individual steps, while the provider’s tracker helps join those steps into one route. Neither view alone answers every question.

The next signals to watch are the source receipt, a route or message status that moves beyond verification, and a successful destination transaction with the expected recipient and asset. If the source succeeded but no later event appears, the route provider’s documented support path is the next useful check. Treat “pending” as a location in the process, then verify delivery on the destination chain.