Why Is My Cross-Chain Swap Pending or Failed?

A cross-chain swap has at least two onchain legs, one on the source chain and one on the destination, so “pending” alone does not show where it stopped. Check the source transaction first: the next step depends on whether it is still waiting, succeeded, or reverted.

If the source transfer succeeded and you still need a different token on the destination chain, ParaSwap handles moving assets across chains and swapping into a destination asset in one flow. That matters when you are deciding what to retry: avoid starting a second transfer while the first one may still complete.

Find the transaction stage before taking action

1. Open the source transaction hash in the source chain’s block explorer. Confirm that the chain and wallet address match your attempt; a hash from another network will not show the relevant transaction.
2. Read the transaction result. “Pending” means it has not been included in a block; “success” means the source-chain action executed; “reverted” means the attempted contract action failed. On Ethereum, ethereum.org explains that inclusion and finality are different: a transaction can be in a block before it is considered final.
3. If the source transaction succeeded, look for a destination transaction or a bridge message tied to it. Cross-chain transfers involve separate chain records, so the source hash may not be the hash of the destination delivery. The EIP-5164 cross-chain execution standard describes this handoff as a message dispatched for execution on the destination chain.

Handle a source transaction that is still pending

1. Check whether the transaction is merely waiting for block inclusion or whether the wallet replaced it. A congested chain, a low priority fee, or a nonce conflict can keep a transaction pending; the nonce is the account’s transaction sequence number.
2. Do not send the same bridge transfer again just because the first hash has not updated. If the original transaction later lands, a second submission can create a duplicate transfer. If the wallet offers a replacement or cancellation, check the original hash and nonce first so you know which transaction actually took effect.
3. Wait for the source transaction to be included, then check its result again. How long this takes depends on the chain and network conditions; there is no universal cross-chain timeout. A route may also wait for enough source-chain confirmations before it begins destination execution.

Recover safely when the source transaction failed

1. If the explorer marks the source transaction “reverted” or “failed,” read the error details if available. A reverted contract call normally does not complete the intended token transfer, but the sender can still pay gas for the failed attempt.
2. Check your wallet balance and the token approval state before retrying. An approval lets a contract spend a specified token amount; it is separate from the transfer itself, and a failed transfer does not always mean the approval failed too.
3. Fix the cause shown by the transaction before submitting again. For example, if the transaction failed because its deadline passed, an old quote may no longer be usable; request a fresh route. If it failed for insufficient gas, ensure the wallet has the chain’s native gas token before retrying.

Resolve a successful source transfer with no destination delivery

1. Search the bridge route’s status or message record using the source hash. A successful source transaction can still be awaiting confirmation, message relaying, liquidity, or destination execution. These stages are route-specific, so the delay alone does not prove the funds are lost.
2. Check the destination wallet address and token contract on the correct destination chain. The asset may have arrived under a different token representation or may be present in the wallet without appearing in its default token list. Verify the contract address from a reliable chain or project source before adding a token manually.
3. If a destination transaction exists and failed, read its result before trying to claim or retry. Some protocols allow a failed destination message to be executed again; others have a different recovery path. Follow the route’s documented mechanism, since a new source transfer will not repair a destination-side failure.
4. If there is no destination transaction yet, keep the source hash and any route identifier together while checking the route’s own status information. For a ParaSwap transfer, that source record is the starting point for understanding whether the transfer is still progressing or whether the destination swap remains to be completed.