A Cross-Chain Swap Is Slow? Check Each Stage

A cross-chain swap can take longer than expected because it must pass through several stages, and each stage has its own confirmation rules and possible delays. First, your source-chain transaction must be included in a block. Then the swap protocol must observe and process it. Finally, the destination chain must accept the outgoing transaction before the asset appears in your wallet.

These stages are separate even when a wallet or swap page presents them as one progress bar. A useful way to think about the route is as a parcel with several handoffs: a delay at one handoff does not mean the next one has started. For a route using THORChain, the protocol can exchange the source asset through one liquidity pool and the destination asset through another, with RUNE connecting the pools internally. A fuller explanation of the route choices and trade-offs is in this thor swap guide.

Has the source transaction confirmed?

The first stage is complete when the source network has included your transaction and the swap protocol has enough confirmation to treat the deposit as valid. A wallet showing “sent” usually means it broadcast the transaction; it does not prove the protocol has received or accepted it. Open the source transaction in that chain’s block explorer and check whether it is pending, confirmed, or failed.

Confirmation can take time if the source chain is busy or the transaction fee was too low for current demand. Some networks also wait for multiple blocks before treating a deposit as final. The swap service may display a deposit address or a memo alongside the transaction. If the transaction confirmed but the service does not recognize it, check that the asset, destination details and any required memo match the instructions for that specific swap. Do not send a second deposit just because the first one has not advanced.

Has the swap protocol processed the deposit?

After the source transaction is confirmed, the protocol must observe it, validate its details and execute the swap. In a cross-chain pool route, the protocol may first exchange the incoming asset into an intermediate asset, then use that value to obtain the requested asset. Those internal steps happen within the protocol; they are not additional transfers you need to make.

This stage can wait on observation, protocol rules, available liquidity or an execution queue. The swap page may show an inbound transaction separately from the swap itself, so compare its status with the source-chain explorer. If the deposit is confirmed but the protocol still shows it as waiting, use the service’s transaction lookup or status page. Check the route and minimum-output setting too: a price move can leave a swap below its stated minimum and cause a refund under the protocol’s rules.

Why has the destination asset not arrived?

The final stage is the protocol’s outgoing transaction on the destination chain. The protocol must authorize and broadcast that transaction, then the destination network must confirm it. A swap can therefore be processed internally while the output is still waiting to be sent or confirmed.

Look for a destination transaction hash in the swap details. If one exists, open it in the destination chain’s explorer. A pending transaction points to destination-network activity, such as congestion or fee conditions. A confirmed transaction with no visible balance may mean the wallet needs to refresh or display the correct network and token. If there is no outgoing hash and the swap page says the protocol is still processing, the delay is earlier in the route.

Use the status at each handoff to decide what to do:

• Source transaction pending: check its explorer status and fee details.
• Source confirmed, protocol waiting: check the swap’s deposit, memo and service status.
• Protocol processed, no outgoing hash: check the swap status for a queue or refund update.
• Outgoing transaction pending or confirmed: follow it on the destination chain and refresh the wallet after confirmation.

Keep the swap record and both transaction hashes. Use the official support route for the service you used if the status stops changing or a confirmed deposit is not recognized. Never share a recovery phrase or private key to “unstick” a swap. The practical rule is simple: identify the last confirmed stage, then investigate the handoff immediately after it.