Retry a Cross-Chain Swap Only After Checking Its State

Retry a cross-chain swap only after you know which on-chain step failed. A swap can involve a source-chain deposit, a message or liquidity transfer, and a destination-chain execution; a timeout in the interface does not show which of those steps completed. Submitting the whole swap again can therefore create a second transfer while the first is still progressing.

Start with the source transaction hash and check its receipt on the source chain. If you need a route walkthrough, Acrossbridge’s cross-chain swap steps cover the sequence to follow. Then use the bridge or swap’s own status page to match that source transaction to its destination action. Treat the interface as a view of state, not as the state itself.

What should I check before retrying a cross-chain swap?

Identify the last step with a verifiable on-chain result, then distinguish it from steps that are still pending off-chain. A source receipt proves that the source transaction was included; it does not by itself prove that a relayer delivered a message or that a destination swap succeeded. A relayer is a service that submits a cross-chain message or transaction on the user’s behalf.

Record the source transaction hash, source and destination networks, token addresses, recipient, and any bridge or swap identifier shown by the service. Check the source receipt and relevant contract events, then look for the matching destination transaction or message status. Confirm token addresses and networks rather than relying on token names, which can be reused. If the source transaction is pending, wait or use the source chain’s supported transaction replacement flow. A replacement with the same account nonce competes with the pending transaction; it is not a second independent attempt.

If the source transaction reverted, its state changes were rolled back, although network fees may still have been charged. After confirming the revert, correct the cause—such as an expired quote, insufficient balance, or an execution limit—and submit a new swap if the route remains available. If the source transaction succeeded, do not resubmit the deposit just because the destination has not updated.

When is a destination retry safe?

A destination retry is appropriate only when the source leg is complete and the protocol exposes a retry for the same message or operation. Some routes use a liquidity provider, which pays out on the destination while settling the source leg through a separate mechanism. Others pass a message that a destination contract must execute. These designs have different recovery paths, so a generic “retry swap” button may not mean “repeat the same destination call.”

Check whether the protocol marks the message as failed, retryable, expired, or already executed. A failed destination call may leave the source-side transfer intact, but the recovery might require a claim, a message execution, or a protocol-specific refund. Use the route’s official interface or documented contract method for that state. Do not manually replay calldata or send tokens to an address supplied in a support message.

A retryable message should be tied to the original transfer identifier or proof. On protocols that enforce replay protection, executing the same message twice should be rejected or have no second effect; that protection is contract-specific and should not be assumed across routes. Verify the destination transaction after retry and check its receipt and resulting token balance. A wallet prompt or a submitted transaction hash only confirms submission, not successful execution.

What if the swap is pending, expired, or unclear?

Wait when the source leg is confirmed and the route still reports a pending message within its stated processing window. Cross-chain finality and relayer availability differ by route. Repeated submissions during that interval can create duplicate work, consume more gas, or complicate support review without advancing the original transfer.

Use a fresh quote only after establishing what happened to the first attempt. If the route’s terms say an expired transfer can be reclaimed, follow that route’s refund or recovery process and verify the refund on-chain before starting again. A quote expiring in the interface does not prove that an already submitted source transaction was cancelled. Likewise, a missing destination transaction is not proof that the source transfer failed.

Before any new signature, check the destination chain, recipient, token contract, amount, slippage or minimum-output bound, and the contract or spender being authorized. Stop if the recovery page asks for a seed phrase, an unrelated token transfer, or an approval with a scope you cannot verify. In practice, the safer choice is to retry the narrowest failed step the protocol identifies; restarting the full swap is appropriate only after the first attempt is confirmed reverted or recovered.

The source receipt can confirm whether the source transaction succeeded or reverted, and a destination receipt can confirm whether a submitted destination transaction executed. Whether a pending message will arrive, whether a route offers a valid retry or refund, and whether a displayed status is current remain unverified until the protocol’s records and on-chain events support them.