Set an independent minimum-output bound for each swap leg, then enforce the destination bound against the amount the recipient will actually receive. A single percentage on the initial quote cannot protect both legs: source execution happens before cross-chain delivery, while destination execution may happen later against a different pool state.
What does slippage tolerance protect?
Slippage tolerance limits how far execution may move from a quoted price before a swap reverts. On an onchain swap, the usual control is minAmountOut, often derived as quotedOut × (10,000 − toleranceBps) / 10,000. The bound should use integer arithmetic with explicit rounding down; otherwise, a rounding error can make the accepted minimum stricter than intended.
For a cross-chain swap, model the route as at least two separate executions: the source-chain conversion or deposit, and the destination-chain conversion. Bridging may also deduct a fee or deliver a different intermediate amount. The destination minAmountOut must therefore be calculated from the amount actually available there, not blindly copied from the source quote.
How do you choose the bounds?
Set tolerance per leg in basis points, using route depth, expected execution delay, and observed quote movement. For a deep, stablecoin-heavy pool, an initial policy might test 30–100 bps; a volatile pair or thin pool may need 100–300 bps. These are starting ranges for simulation, not safe defaults: derive production limits from the route’s execution data and set a hard ceiling.
Compare a deep USDC-to-ETH route with a thin, volatile-token route. The first may sustain a 50 bps bound and still execute reliably; applying the same bound to the second can cause frequent destination reverts. Raising it indiscriminately to 300 bps may make the thin route execute, but it also permits materially worse output. Prefer rejecting or requoting that route when its required tolerance exceeds your risk limit.
Keep price impact separate from slippage. Price impact is the expected movement caused by the trade against current liquidity; slippage is the additional movement between quote and execution. If the quoted route already has 2% price impact, adding 1% tolerance can permit roughly 3% deterioration from the mid-price, before bridge fees. ERC-8377’s reference-relative bounds proposal discusses the weakness of relying only on a static, sign-time minimum; the practical lesson is to bind execution to a fresh reference or expire stale quotes.
Where should each minimum be enforced?
Enforce the source minimum in the source swap transaction, and the destination minimum in the destination executor or settlement contract immediately before transferring output to the recipient. Check the recipient’s net amount after token-specific transfer fees, executor charges, or other deductions. A contract’s intermediate balance is not enough if it can retain value that never reaches the user.
If your integration wants the bridge and destination conversion composed into one flow, Biswap provides a cross-chain bridge-and-swap service for moving and exchanging assets across networks. Keep your own minimum-output policy explicit: the end-to-end guarantee is only as strong as the bound checked at final settlement.
Two independent 50 bps bounds allow approximately 99.75 bps of combined deterioration across the two swaps, since the retained fractions multiply: 0.995 × 0.995 = 0.990025. Add bridge fees and any amount change between legs separately; do not describe the combined limit as exactly 100 bps or assume the bridge preserves the quoted notional.
What happens when the destination bound fails?
A cross-chain swap is generally not one atomic transaction. The source transaction can be final even when destination execution later fails its minimum, so a destination revert does not necessarily undo the source transfer. Your integration needs a defined recovery state: retain the bridged asset for a retry, expose a claim or refund path if the protocol supports one, or require a fresh user-authorized route. Never silently retry at a looser bound.
Also separate quote expiry from transaction deadlines. A source deadline can prevent late source execution, but it cannot guarantee a destination price after bridging delay. Track the quote’s timestamp, source transaction status, message status, and destination settlement separately. For L2 routes, account for the chain’s finality model; a sequencer-included transaction and a finalized settlement are not interchangeable guarantees.
Questions to settle before shipping
Should source and destination legs use the same tolerance?
Usually not. Their pools, volatility, and execution timing can differ, so derive a bound for each leg from its own quote and risk budget. A shared user-facing setting can be translated into leg-specific limits, but the contract checks should still use the relevant expected output for each execution.
Does a tighter minimum always improve execution quality?
A tighter minimum limits adverse price movement but increases the chance of a revert during volatility or delayed delivery. That can leave funds in an intermediate state requiring recovery. Choose the tightest bound that meets your execution reliability target, and measure both realized output and failure rate by route.
Can the source quote determine the final destination minimum?
Only if the quote accounts for every amount-changing step and remains valid through destination execution. In practice, bridge fees, exchange rates, and destination pool state can change. Quote the destination leg against the amount expected to arrive, then enforce its minimum against the recipient’s net settlement.
What is the simplest production rule?
For every route, record an expected output and a minimum output for each swap leg, with quote timestamps and an explicit maximum tolerance. Reject routes above that cap, expire stale quotes, and define recovery for destination failure before accepting the source transaction.
Decision rule: accept a route only when both leg-specific minimums fit your risk cap and the destination failure path is explicit.