Concentrated liquidity execution depends on the liquidity active along the entire swap path, not the pool's total deposited value. A swap can cross tick boundaries, enter thinner ranges or pass through a liquidity gap before reaching its size or price limit. Estimate output from the relevant pool state, then check the route, fees and explicit execution limits before treating a quote as usable.
This AI-assisted guide uses official protocol documentation and source code, following the editorial policy. Its original worked swap is hypothetical, with the arithmetic checked locally; it does not report a live pool test.
The next range changes the trade
In a concentrated-liquidity automated market maker, liquidity providers choose price ranges. Positions whose ranges include the current price contribute to active liquidity; positions outside it do not. A large deposit parked far from the current price cannot support a swap until that range becomes relevant. Uniswap's concentrated-liquidity explanation describes this distinction and how ticks mark position boundaries.
Within a range of constant active liquidity, the exchange rate changes continuously as the swap consumes input. At an initialized boundary, positions can enter or leave the active set. The next segment can therefore be much thinner even when the first segment looks deep.
This is a different mechanism from consuming discrete asks in an order book. The order-book depth worksheet remains useful for that venue model; copying its rows directly into a concentrated-liquidity calculation would misrepresent the curve.
The following example isolates this path dependence. It uses Uniswap v3 mechanics for education and makes no claim about KLINEO supporting DEX execution.
A two-range calculation you can reproduce
Define price P as units of token Y per unit of token X. A trader sends Y to buy X, so P rises. Assume normalized token units, fixed pool state, ordinary tokens and no competing transactions. The round boundaries are mathematical teaching values; a deployed pool restricts position boundaries to its allowed tick grid.
For a segment with constant liquidity L, moving from square-root price a to b requires:
- Net Y input:
L × (b − a). - X output:
L × (1/a − 1/b).
These are the within-range relationships in section 6.2.3 of the Uniswap v3 whitepaper. At the boundary, update active liquidity before applying them again. Here, L is the model's liquidity parameter, not a dollar amount or the pool's token balance.
Use 125 Y of net input after swap fees. Start at P = 1.00. The first active range ends at 1.21 with L = 1,000; the next has L = 250 and extends through 1.44.
| Swap segment | Start P → end P | Square-root price | Active L | Net Y used | X received |
|---|---|---|---|---|---|
| First range | 1.00 → 1.21 | 1.00 → 1.10 | 1,000 | 100 | 90.909091 |
| Second range | 1.21 → 1.44 | 1.10 → 1.20 | 250 | 25 | 18.939394 |
| Total | 1.00 → 1.44 | — | Changes at boundary | 125 | 109.848485 |
The first row consumes 1,000 × (1.10 − 1.00) = 100 Y. Its output is 1,000 × (1 − 1/1.10) = 90.909091 X. That leaves 25 Y, which moves square-root price by 25/250 = 0.10 in the thinner second segment.
The average pre-fee execution price is 125/109.848485 ≈ 1.137931 Y per X. The terminal marginal price is 1.44. Neither is interchangeable with the initial price of 1.00. Budgeting 125 Y at the initial rate would incorrectly predict 125 X.
Keep fees outside that net-input calculation. At an illustrative fixed 0.30% input fee, ignoring integer rounding, supplying 125 net Y requires 125/0.997 ≈ 125.376128 gross Y. Gas is another cost. Real contract arithmetic uses integer token amounts and protocol rounding, so this table is a teaching model, not transaction calldata.
Replace one range with a gap
Now change the assumed liquidity distribution. Keep the first segment unchanged, but place no active liquidity between P = 1.21 and P = 1.44. The L = 250 segment starts at 1.44 instead and, for this alternative fixture, extends beyond 1.69. Assume no configured price limit stops the swap before that price.
In the v3 core calculation, zero-liquidity steps can advance price toward the next boundary or configured price limit without exchanging tokens in that empty interval. Once liquidity becomes active again, the remaining swap can continue. This follows from the pool's tick-crossing loop and its single-step swap arithmetic. A gap does not automatically mean every swap reverts, and it supplies no output while crossed.
After spending the same first 100 net Y, the remaining 25 Y now starts at square-root price 1.20. With L = 250, it reaches 1.30, or P = 1.69. Its output is 250 × (1/1.20 − 1/1.30) ≈ 16.025641 X.
| Same 125 net Y input | Total X output | Average pre-fee Y/X | Terminal P |
|---|---|---|---|
| Adjacent active ranges | 109.848485 | 1.137931 | 1.44 |
| Gap before second active range | 106.934732 | 1.168937 | 1.69 |
The gap example delivers about 2.913753 fewer X. Adding a wide slippage tolerance would not create liquidity in the missing interval. It would only change what deterioration the caller accepts.
There is also an integration edge case: the v3 SwapRouter callback rejects swaps entirely within zero-liquidity regions. The example starts with active liquidity and exchanges tokens there; do not generalize it into a promise that a wholly empty route is usable. Uniswap v3 SwapRouter source.
A quote, a price limit and a minimum output differ
A quote estimates an outcome from an observed state. A core price limit constrains how far the pool price may move. A router minimum output constrains the total tokens received. In the v3 router, exact-input execution checks the returned output against amountOutMinimum; exact-output execution uses a maximum-input check. The router also applies a deadline. Uniswap's swap protection parameters explain these separate constraints.
For the hypothetical tables, a minimum of 109 X passes the adjacent-range estimate and fails the gap estimate. If an actual transaction returns less than that minimum, the router check reverts it. This is conditional protection, not evidence that the original quote remains available.
A core price limit can also stop execution before all intended input is consumed. Review the integration's handling of unspent input and returned amounts instead of assuming every successful call completed the original intention. Record actual input and output, then reconcile fees and gas in the transaction-cost analysis worksheet.
Preserve the state behind the path
Two displays can disagree because they refer to different blocks, pools, fee tiers, directions or routes. A multihop path adds another pool's state and another conversion; an attractive first hop cannot establish the final output.
For a reproducible comparison, retain this worksheet alongside the quote:
| Evidence field | Question it resolves |
|---|---|
| Chain, block identifier and observation time | Which state produced the estimate? |
| Pool addresses, token order and decimals | Which assets and units does the price represent? |
| Input amount and fee tiers | Was the same spending instruction compared? |
| Active liquidity and crossed initialized boundaries | Where did the usable liquidity change? |
| Complete route and final output estimate | Did every hop enter the calculation? |
| Minimum output, maximum input or price limit | Which outcome would the caller reject? |
Data integrity remains necessary even when the formula is correct. On centralized venues, order-book checksums test a feed-specific representation of local book state. For an on-chain quote, preserve a consistent block-state reference; a checksum from another data model cannot certify the swap path.
An oracle is a separate reference again. A pool's instantaneous exchange rate does not establish whether an external observation is current or representative. Use the oracle staleness and deviation guide when checking the timestamp and update policy of that comparison source.
LP withdrawals, other swaps or transaction ordering can change the state before execution. A historical candle also cannot reconstruct which liquidity ranges existed at that moment. Treat missing range data as missing evidence, not a flat-cost assumption. Changing liquidity, transaction failure and adverse price movement remain part of the broader trading risks, even when every arithmetic step in the estimate is correct.
Editorial method: Prepared with AI assistance from the linked Uniswap documentation and source code reviewed on 23 October 2026. The two-range and gap fixtures are original hypothetical examples checked arithmetically. No live pool, transaction or KLINEO DEX capability was tested. See the editorial policy.