Where Funds Go After a Cross-Chain Swap Fails

Recovering funds after a failed cross-chain swap starts by locating the last successful on-chain step, because a route may move assets across chains before its final swap executes. A failed wallet prompt or reverted source transaction usually leaves tokens in the wallet, while a confirmed bridge deposit may put them in a contract or relayer’s settlement flow. The destination swap can fail after that transfer succeeds, so “failed” in an app is not enough to establish where the funds are.

Record the source and destination chain, both transaction hashes if available, the input and output token addresses, the recipient address, and the route or order identifier. For route-selection context before retrying, Biswap’s fuller guide to a first cross-chain swap discusses the choices made before execution; recovery depends on what the contracts did after submission.

How do I tell where the swap stopped?

Read the source-chain receipt first: a reverted transaction does not commit its token transfers or contract state changes, while a successful receipt proves only that the source transaction executed. On an EVM chain, a transaction receipt with status zero indicates execution reverted; status one means the transaction completed, not that the destination leg has settled.

Open the successful source transaction in a block explorer and inspect its logs and internal calls. Look for the router or bridge contract that received the tokens and for the emitted deposit, message, or order event. Match the token contract address and amount rather than relying on the token symbol, which can be shared by unrelated assets. If the router sent funds to a bridge contract, the next step is to check that bridge’s destination-side message or fill state.

Keep the route’s stages separate:

• Source swap or deposit reverted: the transaction’s state changes roll back. The original tokens generally remain at the sender, though the network fee for the failed transaction is still charged.
• Source deposit succeeded, destination action pending: funds have left the wallet, but the route may still be waiting for message delivery, a relayer fill, or settlement.
• Destination transfer succeeded, destination swap reverted: the bridge leg may be complete while the output conversion is not. The recoverable asset and available action depend on the destination contract’s design.
• App status disagrees with chain records: the interface may be delayed or may have stopped tracking the route. Verify the hashes and contract events independently.

Can I claim a refund or retry the destination swap?

You can claim or retry only if the route’s contracts expose that action and its conditions have been met. A cross-chain swap is usually a sequence of contract calls and messages, not one atomic transaction spanning both chains. The source-chain transaction cannot roll back merely because a later destination transaction failed.

Some bridge designs hold a deposit until a fill deadline passes; in those designs, an unfilled deposit may become eligible for a refund, subject to the protocol’s rules. Other routes use a relayer that advances destination liquidity and reconciles deposits later. A status such as “pending” or “expired” has meaning only within that route’s state machine. Check the route’s official status tracker or documentation for the exact refund function, deadline, and required chain. Do not send a second deposit just because the first has not appeared in the destination wallet.

If the destination transaction reverted, inspect its receipt and logs as well. The transaction’s failure may mean the swap call rolled back while an earlier bridge delivery remains intact; alternatively, a route contract may have a fallback path that returns or makes the delivered token claimable. Check the documented contract address and function before calling anything. A wallet prompt from an unknown site is not evidence that funds are recoverable.

What should I do before contacting support?

Build a short transaction timeline and share only public identifiers. Include chain names, transaction hashes, the wallet address that submitted the route, token contract addresses, and the route or order ID. State which receipt succeeded or reverted and whether the destination contract emitted a fill, delivery, refund, or failure event. This lets support distinguish a delayed message from funds held in a contract or tokens already delivered to an address.

Use the original route provider’s support channel to confirm any contract-specific recovery path. Never share a seed phrase or private key; support does not need signing authority to inspect public transactions. Be cautious if a supposed recovery process asks you to approve a new contract: an approval grants token-spending permission, and it does not itself return the missing funds. Verify the spender address and the exact function against the provider’s official instructions before signing.

The practical rule is to retry only after the first route’s state is clear. If the source transaction reverted, a fresh swap may be appropriate once the cause is fixed. If the deposit succeeded, first establish whether it is pending, fillable, refundable, or already delivered. That distinction determines whether the next action is to wait, claim, retry a destination step, or ask the route provider to investigate.