Set the destination minimum from the quoted output and a bounded slippage budget, provided the quote remains valid through execution. For an integration, the hard part is that the source transaction and destination swap happen at different times, so the quoted price may be stale when the destination trade is attempted.
Separate quote movement from execution protection
Slippage tolerance is the maximum shortfall your application accepts between a quoted output and the actual destination output. If a quote expects 1,000 units and the tolerance is 100 basis points (1%), the destination minimum is 990 units; encode that minimum in the execution condition rather than treating the displayed percentage as protection by itself.
Use integer arithmetic in the output token’s smallest units: minOut = floor(quotedOut × (10,000 − slippageBps) / 10,000). Pass the minimum and quote expiry with the order or intent, and have execution revert or follow an explicit recovery path if either check fails. Convert with the token’s decimals before comparing amounts, and account for transfer taxes or rebasing behavior if the route can touch such tokens.
Choose the budget from observed volatility, route depth, and time from quote to destination execution. As a starting point for testing, a deep, liquid route might use 30–100 bps, while a thin or volatile destination pool may need 100–300 bps; these are illustrative ranges, not guarantees. Larger tolerances reduce failed executions but expose users to worse prices, so monitor realized shortfall and failure rate by route instead of applying one global value.
Carry the bound across both legs
Model the flow as two price-sensitive events: the source-side conversion, if any, and the destination swap. Give each leg its own quoted amount and minimum, or derive a single end-to-end minimum from a quote that already includes both legs. Applying 1% independently to two sequential swaps can permit roughly 2% aggregate loss in the worst case, so check the total bound as well as each leg.
For example, suppose a source transaction converts 2 units of asset X and the route quotes 1,000 units of token Y on the destination chain. With a 75 bps destination tolerance, require at least 992.5 units of Y, rounded down to its smallest unit. If the source leg changes the amount delivered, calculate the destination minimum from the actual input or the route’s guaranteed output formula; do not reuse a destination quote based on an amount that was never delivered.
A relay bridge can combine cross-chain routing and a swap in one flow, whereas a bridge-only transfer leaves the destination trade to your application. In either design, bind the destination minimum to the quote and enforce it where the swap executes. For a relay bridge integration, also make expiry and failed destination execution observable: a source transaction can finalize after the quote has expired, leaving the integrator to retry, refund, or surface a recoverable order state.
Set quote validity separately from slippage. An illustrative 30–120 second expiry may suit fast routes, but finality assumptions and relayer latency determine the usable window; a longer expiry reduces stale-order failures while increasing exposure to market movement. If execution fails, preserve the order identifier and delivered amount so a retry uses a fresh quote and a new minimum rather than silently widening the old one.
Decide from the failure and loss budget
Compare route-level outcomes: execution success, destination output shortfall, time to completion, and recovery cost. Tighten the bound when a poor fill is more costly than a failed attempt; loosen it only when users explicitly accept worse execution to reduce reverts. The deciding condition is whether the route’s measured price movement during its actual completion window fits the loss budget—if it does not, quote again or choose a route with deeper destination liquidity.
Questions to check before shipping
Should slippage apply to each swap or the whole route?
Enforce per-leg minima when each leg has an independent execution point, then also verify an end-to-end minimum if the user’s promise is about final received value. A route-wide quote should include all price-sensitive conversions and fees that reduce output; otherwise the aggregate bound can understate the actual shortfall.
What should happen when the destination minimum is missed?
Fail the swap or invoke a defined recovery path, such as leaving the delivered asset claimable for a fresh attempt. Avoid automatically retrying with a larger minimum reduction: that changes the user’s accepted loss after signing and can turn a price-protection failure into an unexpected fill.
How should quote expiry relate to source finality?
Expiry should cover expected source inclusion, finality, and relay time with a measured margin, while the destination execution still checks its own deadline. If source finality regularly exceeds the quote window, use a later destination quote or a mechanism that can obtain a fresh quote without changing the user’s signed loss cap.
Can one tolerance work across every destination token?
Usually not. Volatility, pool depth, token transfer behavior, and route latency differ. Segment tolerances by route and asset pair, cap the maximum acceptable loss, and use observed execution data to adjust defaults; when a route cannot meet that cap reliably, choose a different route or ask the user to decide again.