A Cross-Chain Swap Failed. What Should You Check Before Retrying?

A failed cross-chain swap can leave funds pending, refundable or already delivered, so check each on-chain step before retrying. A swap usually spans separate transactions: one sends assets on the source chain, a bridge or protocol observes that deposit, and another transaction delivers the output on the destination chain. Those steps do not share one atomic rollback. A wallet or aggregator may label the whole route “failed” even when the source transfer is final and the destination action is still queued. Start with the source transaction hash and follow the route’s message or deposit record; the interface status alone does not establish where the assets are.

For a route using THORChain, the inbound transfer is observed by Bifrost, and the network processes the swap through its state machine before signing an outbound transaction. The linked thor swap walkthrough covers a specific route; the useful general point is to inspect the inbound and outbound legs separately. A confirmed deposit can be waiting for protocol processing or destination-chain confirmation. It is not, by itself, proof that the swap failed.

What does a failed swap status actually mean?

A failed status describes a route or transaction state, not necessarily the final disposition of the funds. On an EVM chain, a transaction receipt with status `0` means that transaction reverted: its state changes, including token transfers made inside that transaction, are rolled back. The gas charge is still paid. But a successful source-chain receipt only confirms the source transaction; it does not prove that a bridge message was relayed or that a destination transaction succeeded.

Cross-chain systems differ in how they represent progress. A lock-and-mint bridge may record a source deposit, wait for its finality rule, then authorize a destination mint. A liquidity network may fulfill the destination transfer from its own inventory and settle the source leg separately. An intent route may rely on a solver to execute the destination leg and claim settlement later. Each design has different recovery rules, so the same “failed” label can mean waiting, refund eligibility, or a completed source leg with a failed payout.

Use the source-chain explorer to check whether the transaction is pending, reverted or confirmed. If confirmed, find the protocol’s deposit, message, swap or claim record using the transaction hash and recipient address. Then inspect the destination chain for the corresponding transaction. A relayer delay, confirmation threshold, congestion or an outbound queue can leave a valid swap looking stalled. If a destination transaction exists, its receipt and logs show whether it succeeded, reverted or delivered a different token than the interface expected.

When is it safe to retry the swap?

Retry only after you know what happened to the first deposit. If the source transaction is still pending, broadcasting a second transfer can create two live deposits; replacing an EVM transaction with the same sender and nonce may instead replace the first transaction, depending on what the wallet submits. If the source transaction is confirmed, a second deposit is a new swap and can spend the asset again. First establish whether the protocol has already credited, routed, refunded or made the original amount claimable.

Check the protocol’s own status or recovery instructions against the transaction hash. A refund may require a separate claim, a destination address, or a supported recovery flow. Some systems automatically retry a failed destination action; others hold funds for manual recovery. Do not send a “rescue” transaction to an address found in a chat, search result or unsolicited message. Use only the official interface or contract addresses you already trust, and confirm that the recovery path matches the route and token involved.

Before making a fresh attempt, verify these details:

• The source transaction reached the required confirmation or finality state.
• The destination chain, recipient address and token contract match the intended route.
• The protocol shows the original deposit as completed, refunded or eligible for a defined recovery action.
• The quoted minimum output and fees still make sense; a new swap is subject to current liquidity, price impact and network costs.

A minimum-output setting can also explain a refund. If execution cannot meet the user’s limit, a protocol may reject the swap or return the unspent input under its own rules. That is different from a bridge message failing after deposit. Check the route’s quoted output, slippage limit and refund record rather than assuming that raising slippage will fix a stalled transfer. A looser limit can allow execution at a worse price; it does not repair a missing message or a failed payout.

How should you diagnose a stuck destination transfer?

Match the source deposit to the protocol’s observed event, then match that event to any destination transaction. If the source transfer is confirmed but no protocol record appears, check that the token, chain, amount and memo or calldata met the route’s requirements. A wrong destination address, unsupported asset, or malformed memo can prevent automatic processing even when the source transaction itself succeeded. The protocol’s documented recovery path determines whether such a deposit can be returned.

If the destination transaction reverted, inspect its revert reason and the route’s recovery state. The problem may be insufficient destination gas, a contract-level condition, a token transfer restriction or a payout that must be retried by the protocol. A revert does not mean the source deposit was reversed. If no destination transaction has been submitted, the route may still be awaiting finality, a relayer or a queued outbound action. Keep the original hash and use the protocol’s support or recovery process with that evidence.

The practical rule is simple: trace the deposit, protocol record and payout as separate events. Retry only when the first deposit is conclusively refunded or the protocol confirms that a new deposit is required. That avoids turning a delayed cross-chain message into a second, independent swap.