When a destination swap fails, where does the refund go?

If a swap fails after a bridge transfer, the refund usually follows the route’s fallback rules: it may arrive on the destination chain in a different token, or be sent back on the source chain. The key change from a regular on-chain swap is that the bridge leg may already have completed when the failure occurs. That means “refund” does not necessarily mean the original transaction is undone or the original asset is returned to the same wallet.

A cross-chain swap combines at least two operations: moving value between networks and exchanging one token for another. Some routes also bundle a source-chain swap before bridging or a contract call after the destination swap. Each leg can have its own failure conditions, and the route’s terms determine what happens to the funds at each point. For a fuller explanation of how routes connect these steps, see this guide to super bridge transfers and cross-chain routing.

What happens when the destination swap fails?

When the bridge delivers funds but the destination exchange cannot complete, the route may send the bridged token to a fallback address on that destination chain. The user then has an asset in hand, but it may be the token that arrived over the bridge rather than the token originally requested. This is different from a source-chain refund: the bridge transfer has happened, so the fallback can be to keep the value on the destination network instead of reversing the journey.

A destination swap can fail because market conditions move beyond the accepted slippage, the required pool has insufficient liquidity, or the destination call cannot execute. Some routes make the swap and fallback behavior part of a single destination transaction; others treat the bridge delivery and swap as separate steps. In the latter case, a bridge may succeed while a later wallet or application swap fails, leaving the user responsible for deciding what to do with the delivered token.

Before signing, check the route details for the fallback token, the chain where it will be delivered, and the address that receives it. The requested output token is not automatically the refund token.

Can the funds return to the source chain?

Yes, if the route supports a source-chain refund for that failure state and the transaction was configured to use it. But a return transfer is another operation, not a universal reversal button. The system may need to identify the failed route, recover or account for the bridged value, and submit a separate transaction or settlement step to send funds back.

This is where routes differ. A route that keeps fallback funds on the destination chain can avoid the extra time and execution risk of bridging back, but the user must handle an unfamiliar token or network. A route that attempts to return funds to the source can be more convenient when the user wants the original network, but the return path can take longer and may have its own costs and conditions. Neither choice guarantees the exact original amount: fees, exchange execution and the route’s refund rules affect what is ultimately received.

Also distinguish an on-chain transaction that fails before funds move from a route that fails after the source transaction has been accepted. In the first case, the source-chain transaction may revert and leave the tokens in the wallet, though gas can still be spent. In the second, the bridge may already hold or have delivered the value, so a route-specific refund or fallback is needed. A pending status alone does not show that a refund is due.

How can you tell where the refund is?

Start with the route’s status and transaction records rather than submitting the same transfer again. A bridge can be pending, completed, expired or refunded, and each status points to a different next step. Check the source transaction to confirm whether the initial transfer succeeded, then look for the bridge or destination transaction and the token and address involved in any fallback.

• Confirm the source transaction succeeded or reverted, and note the chain and token.
• Check the bridge provider’s status using the transaction hash or route identifier.
• Inspect the destination wallet for the fallback token, including the correct network and token contract.
• Read the route’s stated refund address and refund chain; these may differ from the swap recipient.

If the bridge reports completion but the expected output is missing, verify that the wallet is displaying the destination chain and the token contract shown by the route. If the status says expired or refunded, look for the refund transaction and its recipient; a refund can be recorded separately from the original transfer. Avoid initiating another swap until you know whether the first route is still pending, since a delayed completion could leave you with two active transactions.

The useful question is not simply “did the swap fail?” but “which leg failed, and what fallback did this route promise for that leg?” Before approving a cross-chain swap, record the expected output, the fallback asset, the refund chain and the recipient address. Afterward, watch the route status and the specific on-chain transaction that should deliver either the requested token or the fallback. Those details show whether funds are still moving, already available on the destination chain, or eligible for a return.