Why a Cross-Chain Swap Stalls at One Slippage Check
Source slippage can stop a swap before bridging; destination slippage can revert the final leg after funds arrive, so check each stage’s status and minimum output.
The Top Crypto Editors 3 min read
Why can a cross-chain swap stall after you approve it? Because source-side and destination-side slippage checks protect different trades at different points in the route. A source failure usually prevents funds from leaving the starting chain; a destination failure can happen after the bridge leg has already completed.
What does source-side slippage protect?
Source-side slippage limits how far the initial swap’s execution price can move from its quote before the transaction reverts. If your route first trades your wallet’s token for a bridge asset, the source transaction checks that it receives at least a minimum amount of that asset. A changed pool price, competing trade or stale quote can push output below that floor.
When this check fails, the bridge step generally does not begin: the input tokens remain in your wallet, though the failed transaction can still cost source-chain gas. Refreshing the route gives you a current quote and minimum output. For a walkthrough of the route setup, see how a QuickSwap cross-chain swap works.
What does destination-side slippage protect?
Destination-side slippage applies to the final swap after bridged funds reach the receiving chain. The destination transaction checks whether it can convert the bridge asset into your selected token while meeting that leg’s minimum output. If the pool moves too far before execution, that swap may revert even though the source transaction succeeded.
What you receive after a destination failure depends on the route and bridge design. Some routes deliver the intermediate bridge asset to your destination wallet; others may show a partial or failed status while the transfer is still being resolved. A stalled screen alone does not identify which leg failed.
How can you tell which check stopped the route?
Track the source transaction first, then look for a destination transaction or route status. Use the transaction hashes and explorer records supplied by the app; a confirmed source transaction paired with a reverted destination transaction points to a later-stage failure. Don’t submit the same swap again until you know whether the first route delivered funds.
- Source transaction reverted: check its reason and source-side minimum output.
- Source confirmed, destination pending: wait for the route status to update.
- Destination reverted: check whether the bridge asset arrived and what recovery action the route supports.
When you retry, compare the quoted output with the minimum output for each leg, if the interface exposes them. A wider slippage tolerance can reduce reverts, but it also accepts a worse execution price; use the narrowest setting that fits the asset and route conditions. The next number to watch is the destination leg’s minimum output.