Cross-Chain Swap Stuck? Check Its State Before Retrying

Before retrying a stuck cross-chain swap, establish whether the source transaction failed, the route is still processing, or the destination action needs recovery. A swap that has left the source wallet can remain incomplete while a bridge, solver or relayer handles the next step. Submitting again may create a second request; it does not resolve the first one.

Start with the source-chain transaction hash, not the wallet’s activity label. On an EVM chain, inspect the transaction receipt and decoded call to identify the contract function that ran. A successful receipt means the call executed; it does not prove that the destination transfer or swap completed. Check the emitted logs and the protocol’s status page for the route or message identifier tied to that transaction. For route-choice context, see which QuickSwap route fits each trade; route selection and execution timing are separate questions.

Did the source transaction actually fail?

A failed source receipt means the contract call reverted or otherwise failed under that chain’s execution rules, so the intended bridge request was not successfully created. The wallet may still have paid a network fee. Check the receipt’s status and failure details before submitting again. If the transaction is pending rather than confirmed, inspect its nonce and current network fee conditions; a replacement transaction with the same nonce can supersede it on chains that use that model.

Do not treat a wallet timeout as a failed transaction. The wallet may have stopped waiting while the network continued processing. Search the hash in a block explorer, then check whether the transaction is pending, included, dropped from the node’s mempool, or confirmed. These states have different consequences. A pending transaction may still execute. A dropped transaction may be resubmitted, but first verify that it was not included elsewhere or replaced.

When the receipt succeeds, inspect the call target, function arguments and logs. Confirm the source token, amount, destination chain and recipient. A successful call to a router can encode a swap and a bridge request in one transaction, but the exact function and event names depend on the protocol. Use the protocol’s own decoder or explorer data; do not infer completion from a token leaving the wallet alone.

Why can the destination leg still be pending?

A confirmed source transaction can leave a route waiting for a separate destination-side action. Depending on the protocol, that action may be performed by a relayer, solver, liquidity provider or a user submitting a claim. The source receipt confirms only what happened on the source chain. Look up the route’s message or order status and, if available, the destination transaction hash.

If a destination hash exists, inspect its receipt and logs on the destination chain. A successful destination receipt can confirm delivery even when the original interface has not refreshed. Verify the recipient address and token contract, since the received asset may use a different token representation from the source asset. If the destination transaction failed, check the protocol’s documented recovery path. Some designs allow a claim to be attempted again; others require a specific recovery function or support process. The route’s rules determine which applies.

If there is no destination transaction yet, distinguish a normal wait from a stalled route using the protocol’s status data. A solver-based route may be waiting for fulfillment; a bridge message may be waiting for verification or relay. These are different mechanisms, and the user’s next action differs. A “pending” label alone does not identify the mechanism or prove that the route is stuck.

What should you verify before retrying?

Compare the wallet, explorer and route tracker before taking another action. Use the route identifier associated with the confirmed source transaction, not a fresh quote or a second wallet prompt. Check these fields:

• Source status: Confirm whether the transaction is pending, failed or included, and whether the intended contract call succeeded.
• Route status: Match the source hash to the correct message, order or transfer identifier in the protocol tracker.
• Destination evidence: Check for a destination transaction, claim requirement, delivered token or documented recovery action.
• Recipient and amount: Verify the destination address, token and amount against the original request before claiming or retrying.

Retry only when the protocol’s state confirms that no live request remains and its instructions say a new submission is valid. If the source transaction is pending, resolve or wait on that transaction first. If it succeeded and the route is processing, do not submit a duplicate. If the destination action failed or requires a claim, follow that route’s recovery mechanism. A fresh swap is appropriate only after confirming that the original request failed or was fully refunded.

Keep the source hash, route identifier and any destination hash together when investigating. They show where the request stopped and which actor or contract path owns the next step. That is the useful distinction: a cross-chain swap is not one atomic transaction across both chains, so retry decisions depend on the state of each leg.