A delayed cross-chain swap calls for three checks

When a cross-chain swap is delayed, trace the transaction before deciding whether to wait, recover funds or contact support. A swap can involve a confirmed deposit on one chain, processing by a protocol or intermediary, and a separate payout on another chain. “Pending” may describe any of those stages, so the status in an app is only a starting point. The useful comparison is between the last confirmed event and the next one expected on this route.

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

“Pending” means the service has not recorded a completed swap, but it does not identify where the transaction stopped. A wallet may show that the deposit was submitted while the source chain still waits to include it in a block. After confirmation, a protocol may need to observe and process it. The destination transfer can then wait for signing, a queue, or confirmation on the destination chain.

Routes also work differently. Some systems use liquidity providers or a coordinator to deliver an asset on the destination chain; others process an inbound transfer through protocol stages before issuing a separate outbound transaction. These designs have different failure and recovery paths. A transaction waiting for source-chain confirmation is not the same as a confirmed deposit with no visible payout. For THORChain, for example, the inbound and outbound transactions are distinct, and protocol tracking can show stages between them. A fuller set of checks before sending assets is covered in thor swap. The point here is to locate the stage first.

How do I trace a delayed swap?

Start with the transaction hash from the wallet or swap interface, then check it on the source-chain explorer. Confirm that it is included in a block, and compare the destination address and amount with the details shown when the swap was initiated. If the source transaction is absent or unconfirmed, the delay remains on the sending chain; a protocol tracker cannot show progress it has not yet observed.

If the source transfer is confirmed, use the route’s official tracker or status page to find whether it has been detected and processed. Then look for a destination-chain transaction hash. Once one exists, the destination explorer can show whether that payout is awaiting confirmation, has succeeded, or has failed. Not every route exposes every intermediate step, so an app that says “processing” may give less detail than the explorers and protocol tracker together.

Keep the source hash, destination address, route name, and any status or error message in one place. Check the same route’s documented status again after a reasonable interval instead of refreshing several unrelated services. Different sites can index the same chain at different speeds. For reference:

• Source hash: Was the deposit included in a block?
• Protocol status: Was the deposit observed, accepted, or routed onward?
• Destination hash: Has a payout been broadcast, and what does its chain show?
• Route instructions: Does the service describe a refund, claim, or support process for this status?

This sequence is more informative than the wallet’s pending label alone. It also helps distinguish a slow chain from a route that has stopped advancing.

When should I wait, recover, or contact support?

Wait when the source transaction is still confirming or the route reports an active stage with no error. Chain timing varies, and a cross-chain route must account for more than one chain’s block production. A bridge or swap service may also apply its own observation, liquidity, or signing steps. The fastest route is not always the easiest to diagnose: a service with clearer status reporting can be more useful during a delay than one that only displays a spinner.

Act when the tracker reports failure, a refund or claim is available, or the service’s stated processing window has passed without a new status. Follow the recovery instructions for that specific route. A refund may return the original asset, while a claim process may require the user to submit a transaction; neither is universal. If support is needed, provide the hashes and route details through the service’s official channel. Never share a seed phrase or private key, and do not send a second deposit just because the first swap is taking longer than expected.

Resending can create a second swap while the first is still progressing. A replacement transaction is appropriate only when the route explicitly says the original failed or explains how to restart safely. Before taking that step, check whether the service records a refund, a destination payout, or another pending action against the original deposit.

What signals should I watch next?

Watch for a change in the on-chain record, not only a change in the app’s wording: source confirmation, protocol observation, a destination hash, or a documented refund status. Those signals separate ordinary waiting from a transaction that needs recovery. A route with visible stages offers more evidence than a generic pending label, while a route with fewer steps may be simpler when it works but harder to diagnose mid-transfer.

The practical rule is straightforward: identify the last confirmed stage, check the next expected stage, and act only on the route’s recovery instructions. That turns “delayed” from a vague warning into a specific question: which chain or service still has work to do, and what evidence will show that it has moved on?