A cross-chain swap usually needs at least two on-chain transactions: one on the source chain and another on the destination. The first can succeed while the second fails because delivery and execution are separate steps, so a successful source receipt means the transfer started, not that you received the destination asset.
Source success and destination success are separate events
On the source chain, a bridge contract may lock or burn your token and publish a message describing the transfer. A relayer or other delivery system carries that message to the destination, where a contract verifies it and releases, mints, or swaps the asset. Wormhole’s transfer-flow documentation describes this separation between sending a message and redeeming it.
quickswap lets you move an asset across chains and swap it along the way in one flow, which can save you from arranging the bridge and destination trade separately. The underlying destination work still has to execute on that chain, so check for a completed destination transaction before treating the swap as finished.
For example, imagine you send a token from chain A to receive another token on chain B. The source transaction confirms and the original token is locked, but the destination swap reverts because the price moved beyond the route’s slippage tolerance. Your source transaction remains successful; the destination result is the part that needs attention.
A valid message can still fail during destination execution
Delivery and execution can fail for different reasons. The message may still be waiting for verification or a relayer, or it may reach the destination and fail when the contract tries to act on it. LayerZero and Wormhole both document systems in which a message must be delivered and then executed on the destination.
- Insufficient execution resources: The destination call may run out of gas or compute units.
- Changed market conditions: A swap can revert if its minimum output or slippage limit is no longer met.
- Destination restrictions: A token, recipient, or contract call may not be accepted by the route.
- Delay or congestion: The message may be valid but not yet submitted or finalized on the destination chain.
Look at the destination transaction status, not only the source receipt. A pending message and a reverted destination transaction are different cases: the first may need more time, while the second shows an execution attempt that did not complete. If a destination transaction reverted, its gas may still have been spent; who covers relay or retry costs depends on the route.
Check the existing transfer before starting another
Start with the source transaction hash and find the transfer’s message or route status in the service you used. Then check whether a destination transaction exists and, if it does, read its failure reason. Keep the source hash: it connects the two legs and is usually the key information needed to locate a delayed or failed transfer.
If the message is still pending, allow for confirmation and delivery time before acting. If execution failed, use the original route’s recovery or retry process when available; some protocols let a message be submitted again, while others require a specific claim or recovery path. Do not start a second transfer just because the destination balance has not changed: the first transfer’s tokens may already be locked or burned.
I would retry only after confirming that the original message can be safely executed again or that the route’s recovery process says to do so. If you use quickswap, treat its cross-chain swap as one flow for convenience, while checking both chain outcomes when something appears stuck. The answer changes if the source transaction itself failed: then no successful source transfer needs destination recovery.