Why Is My Cross-Chain Swap Still Pending?

A cross-chain swap stays pending when one stage has completed but a later stage has not yet reached a verifiable outcome. The source transaction can be confirmed while a bridge message awaits relaying, or the destination transaction can still be waiting for gas, liquidity or execution.

What does “pending” mean after the source transaction confirms?

It means the source chain has accepted your transaction, not necessarily that the destination chain has delivered your token. A routed swap can contain up to three legs: a source-chain swap, a bridge transfer, then a destination-chain swap. Each leg has its own transaction, state and failure conditions.

For a bridge message, the source protocol may lock or burn assets and emit a message or packet. A verifier or light client establishes that the source event is valid; then a relayer submits the proof or message to the destination, where a contract releases or mints assets. That relayer may be permissionless or run by a service, depending on the protocol. Axelar, for example, uses a validator set to attest to cross-chain events before execution on the destination. A source-chain confirmation alone does not prove that final execution occurred.

For IBC transfers, the packet has a sequence number and timeout height or timestamp. The destination chain processes the packet and writes an acknowledgement; a relayer carries that acknowledgement back to the source. Until the acknowledgement or a valid timeout is relayed, source-chain state may still show the packet in flight. IBC documentation describes how acknowledgements can follow packet processing.

Bitcoin adds a confirmation threshold: a bridge may wait for several blocks before accepting a deposit as sufficiently final. One confirmation means inclusion in a block; six is a common conservative benchmark for higher-value payments, not a universal bridge rule. Bitcoin’s developer guide explains the changing confidence as confirmations accumulate.

How can I find which leg is stuck?

Follow the transaction hashes in order, using the explorers for both chains and the bridge protocol if it provides one. First verify that the source transaction is included and successful. Then look for evidence that the bridge message was observed or relayed, and finally check whether a destination transaction exists and succeeded.

A common mistake is to treat “source confirmed” as “swap completed” and submit the route again. That can spend a second input while the first transfer is still progressing. Instead, match each hash to its chain and leg; a destination hash that does not exist points to a different stage than a destination transaction that reverted.

Read the route’s output state carefully. A failed destination swap may leave an intermediate token on the destination chain; a bridge failure can leave a bridge-side asset on the source chain; a source swap revert may return the original input. Rango’s transaction-status documentation distinguishes these partial outcomes and provides explorer links for route transactions. Its status reference describes the possible output types.

When should I wait, and when can I recover?

Wait while the source transaction is still unconfirmed, while a required confirmation threshold is not met, or while a valid bridge message is still inside its timeout window. A slow relayer or congested destination can delay progress without invalidating the transfer. Compare the latest on-chain event with the protocol’s stated timeout, rather than treating elapsed minutes alone as proof of failure.

If the source transaction reverted, the bridge stage normally never began; check the wallet’s receipt and token balance before doing anything else. If the bridge reports a timeout, the protocol may allow a refund after the timeout is provable on-chain. For IBC, a timeout is not simply a countdown in the interface: a relayer must submit the timeout proof, and the source chain then handles the packet according to the application’s rules.

If the destination transaction reverted, determine whether the bridge asset arrived and whether the failed leg is retryable or requires a refund. Slippage is one cause: a destination swap’s minimum output can become unattainable as the pool price moves. For example, with an illustrative 0.5% tolerance, a quote of 100 tokens would set a minimum near 99.5; a smaller execution reverts. Raising tolerance can improve execution odds but accepts a worse price, so only change it if the route permits a safe retry.

What should I check before taking action?

Use the source transaction hash, destination address, chain IDs and token contract addresses to confirm that you are checking the exact route. Check token decimals and balances too: a successful arrival in a different intermediate asset can look like a missing deposit if you inspect only the intended output token. Never share a seed phrase or sign an unrelated transaction to “unstick” a transfer.

Can I cancel a swap after the source transaction confirms?

Usually not by cancelling the original source transaction: once it is included, that transaction is part of the chain’s history. A bridge protocol may offer a separate refund or recovery path after a valid timeout or failure condition. Confirm the route’s actual on-chain state and protocol rules before initiating one, because a premature recovery attempt can fail or complicate the route.

Why does the wallet say successful while the destination token is missing?

The wallet often reports only that the transaction it signed succeeded on the source chain. It may not track relaying, destination execution or the final swap leg. Check the destination chain’s explorer and search the receiving address for the exact token contract; also inspect the route’s intermediate outputs and destination transaction status.

How long should I wait before retrying?

There is no safe universal timer. Use the route’s stated estimate as a guide, then compare the source confirmation count, bridge status and protocol timeout. If the source hash is still progressing or the bridge message remains valid, avoid submitting a duplicate. Retry only after the route reaches a terminal failure and its recovery instructions identify what asset remains and where.

The practical rule is to identify the last completed on-chain leg before acting; a pending label alone cannot tell you whether funds are moving, refundable or already delivered as an intermediate token. When comparing routes, Rango Bridge is an example of a cross-chain aggregator that routes swaps across multiple networks, so tracking each leg matters as much as checking the initial confirmation. Keep both chain explorers open and verify the destination result before retrying.