Why Is My Cross-Chain Swap Taking So Long?

A cross-chain swap can take longer than a same-chain trade because it depends on separate blockchains and a protocol coordinating between them. The source transaction must be included and accepted, the protocol must process the deposit, and an outbound transaction must be signed and included on the destination chain. A “pending” label does not identify which of those steps is waiting.

For a route-specific walkthrough, the guide to thor swap covers the user-facing flow; the useful diagnostic is the last confirmed transaction, not the swap screen’s overall status. Follow the source-chain transaction first, then check whether the protocol has observed it and whether an outbound transaction exists.

Which stages can hold up a cross-chain swap?

A swap can wait before it reaches the protocol, while the protocol verifies it, or after execution while the output is being sent. Each stage has a different cause and a different on-chain record.

• Source-chain inclusion: The wallet broadcasts the deposit, but it may remain unconfirmed if the chain is congested or the transaction fee is too low for current demand.
• Confirmation counting: A protocol may wait for enough source-chain confirmations before crediting the deposit. This reduces the risk of acting on a transaction that is later reversed. The required count can depend on the chain and the transaction’s value.
• Protocol execution: After observing the deposit, the protocol validates its details and processes the swap. Its queue, swap settings, or a pause affecting the route can add time.
• Destination delivery: The protocol creates an outbound transaction, which must be signed and then included by the destination chain. Congestion, signing delays, or outbound limits can hold it here.

These are separate clocks. Fast source-chain inclusion does not guarantee fast delivery if the destination chain is busy; a quiet destination chain cannot help while the source deposit is still awaiting confirmation. Some routes also execute the exchange through multiple internal pool operations. In THORChain, for example, a swap between two non-RUNE assets passes through RUNE internally, while the user sends one deposit and receives one outbound asset.

How do swap settings and protocol queues affect timing?

Swap settings can trade execution time for price, while protocol queues can delay when a valid swap is processed. A streaming swap divides the trade into smaller sub-swaps executed over time, which can reduce price impact on a large trade but intentionally extends execution compared with a single swap.

On THORChain, a streaming swap does not require the user to submit a fresh source-chain transaction for every sub-swap. The protocol processes the pieces from one inbound deposit, then sends the resulting output. So a swap that appears to be taking a long time may be executing as configured rather than stuck. Check the selected strategy, any displayed streaming progress, and whether the protocol has emitted an outbound transaction.

Queues and safety controls are separate from streaming. A protocol may order swaps for execution, limit the value it sends out in a block, or delay an outbound transaction under its security rules. Those controls can extend settlement after the exchange calculation is complete. They do not mean the source transaction needs to be sent again.

What should I check before deciding the swap is stuck?

Use transaction records to locate the stage, then compare that stage with the route’s stated settings. Start with the source transaction ID in the source-chain explorer: confirm that it was included, check its confirmation status, and verify that the destination address and memo or other route data match the swap instructions.

If the source transaction is confirmed but the protocol has not recognized the deposit, check the protocol’s transaction tracker or explorer for an inbound record. If the inbound is recorded and the swap is streaming, check whether execution is still progressing. If an outbound transaction is listed, follow that transaction on the destination chain; its status separates a protocol-side delay from destination-chain congestion.

Do not submit a second deposit just because an interface still says pending. A duplicate can create a second swap rather than resume the first one. If the source deposit is confirmed but no protocol record appears, or if an outbound transaction remains unresolved beyond the route’s stated window, use the interface’s documented support process and provide the relevant transaction IDs. Never share a seed phrase or private key to get a swap unstuck.

The practical rule is to identify the last completed checkpoint before taking action. Source-chain confirmation, protocol execution, and destination-chain inclusion are distinct events; the transaction trail tells you which one still needs to happen.