Slippage calculation has a specification problem. Most formulas in common use were designed for single-venue execution against a known order book or constant-product curve. Cross-chain routing in 2026 involves at minimum two separate liquidity pools, a bridge or IBC channel, and often a multi-hop sequence on the destination chain. The standard formulas underestimate realized slippage in most cases because they treat each leg independently and ignore how depth changes between the time you estimate and the time you execute.
This piece walks through the methodology we use at Osmosis for computing expected routing slippage on cross-chain paths. It is not a paper on AMM theory. It is a practical accounting of what the standard formulas miss and how to build estimates that hold up at real execution sizes.
Why single-pool slippage formulas fail on cross-chain paths
The textbook formula for price impact on a constant-product pool (xy = k) gives you the percentage price shift for a given trade size relative to pool reserves. This is accurate for an isolated swap in a pool with stable depth. On a cross-chain route, you have at minimum two of these calculations to chain together, plus a bridge cost at the midpoint.
The errors compound in three places. First, the estimate is made against a depth snapshot, but the execution happens some number of blocks later. Depth on DEX pools changes continuously as liquidity providers enter and exit positions, so the snapshot you priced against may be stale by the time the transaction settles. Second, bridge execution introduces a confirmation window during which the destination pool depth can shift. Third, on multi-hop routes with three or more pools, the output of each leg becomes the input of the next, which means a 0.4% adverse price move in the first pool propagates through the entire remaining path as a compounding error.
We are not saying the constant-product formula is wrong. It is correct for what it computes: instantaneous price impact at a given depth state. The problem is using it as if depth is static and legs are independent.
The depth decay factor
A practical fix is to model depth decay as a function of execution time. On actively traded pairs on major DEXs, intraday depth variance at the 1% price impact threshold can exceed 20% of the mean value over a trading session. For a route that requires 15-30 seconds of bridge confirmation plus destination-chain transaction finality, the window is long enough that you should be discounting your initial depth estimate.
The specific decay rate depends on the pair and the chain. Stablecoin-to-stablecoin pools on high-volume pairs tend to be more stable because the incentive to provide liquidity is consistent. Volatile token pairs, particularly assets with narrow liquidity bases on the Cosmos side, can move significantly within a single block confirmation window.
A conservative approach: take the depth estimate at the moment of routing calculation and apply a haircut based on the 30-day intraday variance of that pool. For pairs where you have limited historical depth data, a 15% haircut on the 1% impact threshold depth is a reasonable starting point for sizing your slippage estimate, then tighten it as you accumulate pool-specific observations.
Accounting for multi-hop path order
Multi-hop routing is common on Cosmos chains. ATOM to a long-tail asset often routes through an intermediate pair, such as OSMO or USDC, before the final hop. The order of hops matters for slippage accumulation.
If the high-depth hop comes first, you get a favorable output token that then gets traded into the thin pool. This is better than routing into the thin pool first, because the thin pool now sees a smaller notional in the currency it prices. In practice, most routing algorithms on Osmosis DEX already do this correctly, but when you are computing expected slippage for a route you did not design, you need to check the depth at each leg explicitly rather than assuming the path is ordered correctly.
The other trap is treating the intermediate token as cost-free to pass through. In reality, some intermediate pairs carry a 0.1-0.3% fee at each hop. On a three-hop route, that fee drag alone can be 0.6-0.9% before any price impact is counted.
Bridge slippage: the leg most estimates ignore
For routes that cross from Ethereum or an EVM chain to Cosmos, the bridge is often the largest source of unaccounted slippage. Most aggregators show you the quoted exchange rate, which is computed before the bridge initiates. The execution rate at the destination depends on what the destination pool depth looks like when the bridged tokens arrive, which is a function of what happened during the bridge confirmation window.
On bridges with 5-15 minute confirmation windows, the destination pool can experience a meaningful amount of inbound and outbound liquidity flow. If a large directional trade hits the destination pool during your bridge window, you arrive to a thinner pool than you expected. Most aggregate routing tools do not account for this because they do not have real-time access to destination pool depth during the bridge window. The estimate is computed once at initiation and treated as fixed.
The practical mitigation is to set a minimum acceptable depth threshold at the destination pool and abort or reroute if depth drops below it before the bridge transaction finalizes. This requires having live depth monitoring on the destination pool during the confirmation window, not just a one-time snapshot at routing time.
A working methodology for slippage estimation
To put this into a coherent workflow: start with pool depth at each leg, not TVL. TVL is a poor proxy for executable depth at standard notional sizes because concentration of liquidity around the current price varies significantly across pool types. A Uniswap v3 concentrated liquidity pool can have a relatively small TVL but very high depth at a narrow price range, while a Curve-style stableswap pool has predictably high depth across the peg range. Compute the actual depth curve at your target notional, not a TVL ratio.
Next, chain the legs explicitly. Output of leg one, minus bridge fee, minus bridge slippage at arrival, becomes input of leg two. Run each pool calculation at the adjusted notional size after fees, not at the original input size. The difference is small on simple two-hop routes but meaningful on three or more hops.
Apply the depth haircut based on the time window. For same-chain swaps settling within a few blocks, the decay factor is close to zero. For IBC transfers with 30-second relay latency, use 5-10% as a starting point unless you have pair-specific data. For EVM bridges with multi-minute windows, a 15-20% haircut on destination depth is conservative but defensible until you have more observations on that specific bridge-pair combination.
Finally, track realized versus estimated slippage after each execution. The gap between your model and the market's actual behavior is where the most useful calibration data lives. Most research desks compute slippage estimates but rarely systematically compare them to execution outcomes. That feedback loop, closed over time, is where routing models improve.
What this means for tools that do it for you
If you use a routing aggregator, understand what its slippage estimate is actually computing. The most common approach is single-snapshot depth at the time of quote, with each leg treated independently. This is correct for single-chain swaps and directionally useful for cross-chain routes, but it will systematically understate realized slippage at large notional sizes and for routes with long confirmation windows.
For research purposes, the distinction between quoted slippage and realistically estimated slippage matters most when you are comparing routes or computing execution cost as part of a broader analysis. If you are writing a report comparing three routing paths for a $500k ATOM acquisition, the single-snapshot estimate will rank the routes in roughly the right order but the absolute numbers will be optimistic. Accounting for depth decay and leg sequencing typically adds 0.1-0.4% to the estimate for moderate-size trades on well-traveled paths, and more for tail pairs.
The core principle is that cross-chain routing slippage is a function of depth at the time of each settlement, not at the time of the quote. Building estimates that respect that timing gap is the difference between a routing model and a routing approximation.