Adaptive Slippage: How It Works
Fixed slippage is a blunt instrument. Set it to 0.5% and you're leaving money on the table on simple swaps. Set it to 0.01% and your complex multi-hop swap reverts. Orkid's adaptive slippage algorithm calculates the exact buffer needed for each route — no more, no less. Here's the math, the factors, and why it prevents fading.
Why fixed slippage is broken
Every DEX lets you set a slippage tolerance — the maximum price movement you'll accept between quote and execution. Most default to 0.5% (50 bps). Some let you go down to 0.01% (1 bps). The problem is that the right number depends on the route, and the route changes every time.
Consider two swaps:
If you set a fixed 50 bps tolerance, the first swap overpays by ~50 bps of unnecessary buffer. On $1K that's $0.50 — small. On $1M, it's $500. The second swap needs ~1.25 bps but you're allowing 50 bps — that's 48.75 bps of unnecessary exposure to MEV and price movement.
If you set a fixed 1 bps tolerance, the first swap is fine. The second swap reverts because 1 bps isn't enough for a 3-hop, 2-split route. You get nothing. You try again. Maybe it works, maybe it doesn't. This is called fading — your swap fails because the tolerance was too tight.
The three factors
Orkid's adaptive slippage algorithm computes the buffer based on three factors that directly affect price movement risk:
- 01
Hop count
Each hop in a route is a separate pool interaction. More hops = more pools that can move between quote and execution. A 1-hop route touches 1 pool. A 4-hop route touches 4. Each pool adds independent price risk. Orkid adds 0.4 bps per hop to the buffer.
- 02
Split count
When Orkid splits a swap across multiple pools (e.g., 60% through Uniswap V3 and 40% through Aerodrome), each split is an independent execution path. Splits need tighter coordination — if one split fills and the other doesn't, the effective price changes. Orkid adds 0.2 bps per split to the buffer.
- 03
Pool staleness
Pool data freshness matters. If the Tycho WebSocket hasn't received an update for a pool in the route within the last 5 seconds, that pool's state is less certain. Stale data means the computed quote might not match on-chain reality. Orkid adds a flat 0.3 bps surcharge if any pool in the route is flagged as stale.
The formula
The adaptive slippage buffer is calculated as:
buffer = base + (hops × 0.4) + (splits × 0.2) + (stale ? 0.3 : 0)
Where:
- base = 0.01 bps (always present, minimum floor)
- hops = number of pool interactions in the route
- splits = number of parallel execution paths
- stale = boolean, true if any pool in the route has > 5s staleness
The result is capped at 1.25 bps. If the formula produces a value above 1.25 bps, the buffer is set to 1.25 bps.
final_buffer = min(buffer, 1.25) bps
Worked examples
Let's run the numbers on four real-world route scenarios:
Notice the pattern: simple routes get tight buffers (0.41 bps), complex routes hit the cap (1.25 bps). The cap is the safety net — it prevents the buffer from growing unbounded on extreme routes while still being 40× tighter than the typical 50 bps platform default.
On a $100K swap, the difference between 0.41 bps and 50 bps is $49.59 of unnecessary slippage exposure. On a $1M swap, it's $495.90. That's real money that stays in your pocket instead of being available for MEV extraction.
Why this prevents fading
Fading happens when your swap reverts because the slippage tolerance was too tight. It's the most common failure mode in DeFi — and the most frustrating, because you get nothing, pay gas (on non-Orkid platforms), and have to try again.
Adaptive slippage prevents fading by scaling the buffer to match the actual risk of the route:
- Simple routes get tight buffers — but not zero. The 0.01 bps base + 0.4 bps for the single hop gives 0.41 bps of room. That's enough for normal block-to-block price movement on a single pool.
- Complex routes get wider buffers — up to the 1.25 bps cap. A 4-hop, 2-split route with stale data needs more room because each pool can move independently. The algorithm accounts for this.
- The cap prevents over-buffering — even on extreme routes, you never expose more than 1.25 bps. This limits MEV extraction surface area.
The result: Orkid's swap success rate is high because the buffer matches the risk. You don't fade on simple swaps (buffer is adequate) and you don't overpay on complex swaps (buffer is capped). The algorithm finds the sweet spot automatically.
FAQ
Can I override the adaptive slippage calculation?
No. Orkid's adaptive slippage is automatic and non-overridable. The solver computes the optimal buffer for each route based on hop count, split count, and pool staleness. This is a deliberate design choice: manual slippage settings are the #1 source of user error in DeFi. Set it too loose and you overpay. Set it too tight and your swap reverts. Adaptive slippage eliminates both failure modes. If you need custom execution parameters for large orders, use the liquidity desk integration (PRO-004) which supports custom slippage negotiation.
What happens when the slippage buffer hits the 1.25 bps cap?
When the calculated buffer exceeds 1.25 bps, it is capped at 1.25 bps. This means the swap proceeds with a tighter slippage tolerance than the algorithm would prefer. In practice, this rarely causes problems — the cap is conservative enough to allow execution in almost all conditions. If the route is so complex that even 1.25 bps is insufficient (extreme volatility + many hops + stale data), the swap may revert. The solver will then attempt a simpler route with fewer hops, which naturally gets a lower (uncapped) buffer.
How is pool staleness measured?
Pool staleness is measured as the time delta between the last Tycho WebSocket update for a pool and the current block timestamp. If the delta exceeds a threshold (currently 5 seconds on Base), the pool is flagged as stale. This doesn't mean the data is wrong — it means no swaps have occurred in that pool recently, so the state is less certain (someone could have added or removed liquidity without Tycho seeing it yet, though this is rare). The 0.3 bps staleness surcharge accounts for this uncertainty. Most active pools on Base have sub-second staleness.
Does adaptive slippage work on all chains?
Adaptive slippage is active on Base and Ethereum mainnet. The algorithm parameters (base 0.01 bps, 0.4/hop, 0.2/split, 0.3 stale, 1.25 bps cap) are tuned for Base's ~2 second block time. On Ethereum mainnet (~12 second blocks), the same parameters apply but the staleness threshold is adjusted to 15 seconds to account for longer block times. As Orkid expands to additional chains, parameters are tuned per-chain based on block time and finality characteristics.