When a cross-chain swap stalls, check each chain

2 on-chain legs make up a typical cross-chain swap: a transaction on the source chain and a separate action on the destination chain. If the first completes and the second stalls, your funds may be in transit, awaiting a relayer, or eligible for a refund, depending on the swap design. The source transaction alone does not tell you whether the swap has finished or whether your funds are recoverable.

In a bridge-and-swap route, a contract may lock or transfer your tokens on the source chain while a relayer supplies the destination tokens and later settles with the protocol. In an atomic swap, hashed timelock contracts can instead hold both sides under rules that allow a refund after a deadline if the exchange does not complete. If you are choosing a first route, read more about whether quickswap suits a first swap.

Why can a cross-chain swap get stuck?

A swap can pause because the source transaction has not confirmed, the destination chain is congested, or the bridge’s relayer or message-verification step has not finished. A destination swap can also fail after the bridge transfer succeeds, for example if its minimum-output condition is no longer met.

These are different states. Some routes deliver the original token on the destination chain if the final swap fails; others keep the transfer pending or use a protocol-defined recovery path. “Stuck” describes what you see in the app, not a single technical outcome.

How do you tell whether the funds are pending or lost?

Start with the source-chain transaction hash and check it in that chain’s block explorer. A pending or failed source transaction means the bridge stage may not have begun; a confirmed deposit means you should look for a destination transaction or a transfer status in the route’s official tracker.

• Match the source and destination chains, token, amount, and recipient address.
• Check whether the destination transaction succeeded, failed, or has not appeared.
• Read the route’s stated recovery process and any refund deadline before taking action.
• Keep both transaction hashes and the route or order ID for support.

A missing destination transaction does not prove the funds are gone. Some systems need extra time for confirmations or settlement, and a refund may require a separate transaction or claim rather than happening automatically.

What should you do before retrying?

Do not submit the same swap again until you know the first route’s status. A second attempt can create a second deposit and leave you with two transfers to track.

If the source transaction failed, check whether the wallet released the funds and whether any network fee was charged. If it confirmed but the destination step failed, follow that protocol’s documented recovery instructions; a refund may depend on a timeout, a claim process, or support review. Never share your recovery phrase or sign an unrelated transaction to “unlock” a transfer.

When should you expect a refund?

There is no universal refund clock. In a timelocked atomic swap, the contract’s deadline sets when a refund path can open; in a relayer-based bridge, recovery depends on that route’s own rules and the state of its transfer.

Use the deadline and status shown by the protocol, not an estimate from a different bridge. If no recovery option appears after the stated window, contact the route’s official support with the transaction details, and avoid paying anyone who promises to recover the funds through a private key or seed phrase.