A failed destination step does not always reverse a cross-chain swap. The source transfer and destination action happen separately, so a cross-chain service such as omnichain needs a way to retry the action or return the funds. Which outcome applies depends on where the failure happened and how the route was built.

A failed swap can mean three different things.

“Failed” can describe a message that has not arrived, a destination transaction that reverted, or a token swap that finished only in part. A reverted transaction is one the destination chain rejected; it usually does not complete the intended action. The source deposit may still be held by a contract or route provider.

For example, imagine you deposit 100 USDC on Ethereum to receive another token on Arbitrum. If the destination swap fails because its price limit was exceeded, you might receive no target token. The route may still hold the USDC, or it may have already delivered it to an address on Arbitrum.

A retry can complete a verified message.

Some routes separate checking a cross-chain message from running its destination action. A message is the instruction sent between chains; “verified” means the destination has checked that it came through the route correctly. If the action then fails, a retry can run that same instruction again without asking you to make a second source deposit.

This can help when the cause is temporary, such as too little gas— the fee paid to run a transaction—or a short-lived network problem. It will not fix a lasting problem, such as a price limit that can never be met. The key question is whether the route supports a safe retry and whether the cause has changed.

A refund needs a route back to your funds.

If retrying cannot work, the route needs a refund path. A contract may release funds held on the source chain, or a relayer—a service that sends transactions between chains—may arrange a return transfer. When funds have already reached the destination, returning them usually takes another transaction, which needs gas and may take time.

Start by checking the transaction on both chains. Look for whether the source deposit succeeded, whether destination tokens arrived, and whether the destination action is pending, failed, or complete. Keep the transaction record and use the route’s stated recovery process; avoid starting the same swap again until you know whether the first deposit remains active, since a second attempt could spend funds twice.

In practice, I’d judge a refund promise by asking what event triggers it and where the returned tokens go. Cross-chain transfers cannot simply rewind both chains as if one transaction happened. The practical safety net is a defined retry or return path, with a clear recipient and enough funds for any return transaction.