A failed cross-chain swap can resolve in seconds if the source transaction never landed, or take minutes to hours if a bridge needs to finish or unwind a transfer. The deciding factor is the last confirmed on-chain step: follow the assets from that point before retrying.
- A wallet error does not prove that funds left your wallet; check the source-chain transaction.
- If the source transaction succeeded, do not resend the same swap while its bridge leg is unresolved.
- A “failed” route can still leave you holding an intermediate token that you can recover or swap separately.
Think of the transfer as a relay race: each chain hands an asset or a message to the next leg, and a delay can happen between handoffs. Rango bridge aggregates routes across chains; the Rango bridge service is one way to arrange a cross-chain swap, while the recovery decision depends on what the explorers show for each leg.
Did the source transaction actually land?
If the source transaction is absent, rejected, or expired, the bridge may never have received anything. Check the source-chain explorer using the transaction hash from your wallet, and inspect the actual status and error rather than relying on a wallet spinner.
Solana is a useful edge case: a transaction can be processed, then fail to reach confirmed or finalized. A recent blockhash is typically usable for roughly 60–90 seconds; after it expires, a transaction that never landed cannot later be revived with that same blockhash. Check the signature status and error, and wait for expiry if its status is still uncertain before creating a fresh transaction. Solana’s confirmation documentation explains the blockhash and commitment checks.
If the source transaction reverted on-chain, the input usually remains in the source wallet, though network fees may still have been charged. If it succeeded, treat the funds as committed to the route until you establish whether the bridge delivered, refunded, or is still processing them.
Did the bridge receive the source funds?
When the source transaction succeeded but no destination transaction appears yet, the likely issue is between source confirmation and destination execution. Bridges may need source-chain finality, validator or relayer observation, and then a destination transaction; delays can stretch from minutes to longer during congestion, security delays, or a paused chain.
Check the route’s transaction status and its explorer records for both inbound and outbound hashes. In Rango’s documented status model, running or a missing status means keep checking; success and failed are terminal results. A route can contain multiple transactions, so a successful inbound hash does not establish that the destination leg completed. Rango’s status documentation describes the possible output states and explorer records.
Some protocols require a user-initiated claim or refund when a transfer gets stuck. Follow the route’s diagnosis instructions for the underlying bridge, if provided; a generic retry cannot substitute for a protocol-specific claim. Never submit a second transfer just because the first one is taking longer than the quote estimate.
Did the route fail after moving part of the swap?
A multi-leg route can fail after its first swap or bridge has already completed, leaving a middle asset instead of the requested destination token. For example, the bridge can deliver a token on the destination chain, then a final DEX swap can fail because the available liquidity or price no longer meets its minimum-output condition.
Check the final status and output token, not just the word “failed.” Rango’s documented output types distinguish a return to the input token from a middle asset remaining on the source or destination chain. If you hold a middle asset, identify its exact chain and token contract, then decide whether to swap it locally or use the route’s stated recovery path; a second cross-chain transfer adds another set of execution risks and fees.
THORChain illustrates why the final leg matters: a swap can be observed and processed internally, but the destination transaction still has to be signed and broadcast. Its documentation describes typical swap processing around 5–10 seconds, while outbound-chain conditions and security delays can extend the wait. A slow outbound is not by itself proof of loss or a reason to repeat the inbound deposit.
When should you retry, claim, or stop?
Retry only when the source transaction definitively did not execute or the route explicitly reports that the input was returned. If funds reached a bridge, use its documented claim or refund mechanism; if the route completed with an intermediate asset, recover that asset from the chain where it now sits.
Before any recovery transaction, verify the chain, token contract, destination address, and transaction hash against the explorer. A bridge refund may return a different asset or amount after fees, and some claims require gas on the chain where the asset is held. Ignore unsolicited messages asking for seed phrases or remote access; recovery never requires sharing wallet secrets.
Use this short checklist: source status, last confirmed leg, current asset and chain, route-specific claim or refund. Once those four facts agree, choose the next transaction; if they do not, wait or seek help through a channel you independently verified.