Retry a Cross-Chain Swap Only After Its First Route Resolves

To retry a stalled cross-chain swap without paying twice, first determine whether the original inbound transaction is still processing, has completed, or has been refunded. A slow interface does not establish that the swap failed. The source chain, THORChain’s transaction record, and the destination chain each show a different part of the route.

On THORChain, a swap starts when the source-chain transaction sends an asset to an inbound vault with a memo describing the intended swap. Validators observe that inbound, the state machine processes it, and a vault broadcasts the output on the destination chain. A swap between two non-RUNE assets uses two pool swaps internally, routed through RUNE; the user does not submit a second deposit for that step. For a closer walkthrough of thor swap, see the fuller guide to interpreting a stalled route.

How can you tell whether a swap is still processing?

Follow the original source-chain transaction hash first. If it is unconfirmed or absent from THORChain’s transaction status, the inbound has not reached a completed protocol state. Do not send the amount again just because a wallet or swap interface has not updated. A second transfer would be a new inbound and could create a second swap.

Once THORChain has observed the inbound, check its transaction status and action record. The status endpoint exposes stages such as inbound_observed, inbound_confirmation_counted, swap_status, and swap_finalised, along with planned and broadcast outbound transactions. The action record can classify the result as a swap or refund. These records help distinguish protocol processing from a front end that has stopped polling or failed to display an update.

For a streaming swap, an observed inbound may still be executing in sub-swaps. The memo’s interval and quantity determine how those attempts are scheduled; a quantity of zero lets the network choose the number of attempts. THORChain tracks successful and unsuccessful portions. At the end, it can send the successful output and refund the remaining source asset. If the first sub-swap fails, the documented behavior is to refund the entire streaming swap.

When is it safe to submit the swap again?

Submit a new swap only after the first route has resolved and the funds you intend to use are back in a wallet you control and available to spend. A refund is itself an outbound transaction on the source chain. Until that transaction is broadcast and confirmed, the returned amount may not be spendable. Check the refund’s destination, asset, amount, and transaction hash rather than treating an interface label as proof of recovery.

A refund can be smaller than the original deposit because the source-chain transaction already paid its network fee and the refund outbound can incur a fee too. THORChain’s swap memo can also specify a refund address; without one, the default is the original sender address. If a refund is routed to an address you do not control, or the refund transaction has not appeared, sending a replacement swap does not fix that problem.

Use this sequence before retrying:

• Find the original inbound hash in the source-chain explorer and confirm its status.
• Look up that hash in THORChain transaction status or the transaction’s action record.
• Check whether THORChain has a pending outbound, a completed destination-chain transfer, or a refund.
• If refunded, wait for the source-chain refund to confirm and verify the returned balance before quoting and signing a new swap.

If the outbound is planned but not yet broadcast, the swap has not necessarily failed. If it has been broadcast, inspect its destination-chain hash and status. A pending destination-chain transaction is a different failure point from an inbound that THORChain never observed. Resubmitting while either outbound is still in flight can leave you with two swaps if the first eventually completes.

What fees can a retry add?

A retry is a new on-chain operation, so it requires a new source-chain transaction and its network fee. It may also incur the normal swap costs, including liquidity and destination outbound fees. A failed attempt can still cost money: THORChain’s refund uses an outbound fee for the source chain. The original transaction does not become free when its intended destination transfer is replaced by a refund.

Before signing again, request a fresh quote and verify the source asset, destination asset, destination address, minimum output or price limit, and refund address. A price limit that cannot be met can cause a refund; for a streaming swap, unsuccessful sub-swaps can leave a partial source-asset refund. Reusing the same settings without checking the reason for the first refund may simply reproduce it.

The practical rule is to retry the funds, not the pending request. Match the original inbound to THORChain’s action and outbound records, then wait for either destination delivery or a confirmed refund. Only a resolved refund puts the original amount back into a position where a deliberate second swap can be made.