Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

This page consolidates the derivations behind CLMM. For the on-chain implementation, see products/clmm/math (which cites this page) and products/clmm/ticks-and-positions (which motivates the tick lattice).

​
Why sqrt-price, not price

Uniswap-v3-family CLMMs represent price as its square root, stored in a fixed-point Q64.64: 
sqrt_price_x64 = floor(sqrt(price) · 2^64)
Three reasons:
  1. Linear liquidity math. The amount of token0 or token1 in a price range turns out to be a linear function of sqrt_price, not of price. Storing sqrt_price lets the swap step evaluate those linear formulas without computing a square root.
  2. Overflow control. sqrt_price · L fits in u256 for all reasonable parameters; price · L can overflow much sooner.
  3. Tick math is uniform. Because ticks are defined as 1.0001^i, sqrt(price) = 1.00005^i is also an exact power-of-1.00005 ladder. Each tick-cross translates to a small multiplication in sqrt_price_x64 space.
Price and sqrt-price are one-to-one; the conversion is price = (sqrt_price_x64 / 2^64)^2.

​
Tick lattice

Prices are discretized onto a grid: 
price(tick_i) = 1.0001^i
tick_i is an i32. The live range is [MIN_TICK, MAX_TICK] = [−443636, 443636], giving a price range of roughly [2^−128, 2^128]. Each pool’s tick_spacing is set by its fee tier: smaller spacings for tight pairs (e.g. stablecoin 0.01% tier uses spacing 1), larger spacings for volatile pairs (0.25% tier uses 60, 1% tier uses 120). Positions must have tick_lower and tick_upper aligned to tick_spacing. A pool’s active ticks (those with liquidity starting or ending there) are the only ticks the swap step cares about.

​
Liquidity-to-amount

For a position with liquidity L and price range [sqrt_lo, sqrt_hi] (all sqrt_price values):
Pool stateAmount of token0Amount of token1
Price above range (sqrt_p ≥ sqrt_hi)0L · (sqrt_hi − sqrt_lo)
Price in rangeL · (sqrt_hi − sqrt_p) / (sqrt_p · sqrt_hi)L · (sqrt_p − sqrt_lo)
Price below range (sqrt_p ≤ sqrt_lo)L · (sqrt_hi − sqrt_lo) / (sqrt_lo · sqrt_hi)0
Derivation: differentiate the CPMM invariant locally. Inside any single tick range, the position behaves as a CPMM with virtual reserves (x_v, y_v) chosen so the pool’s current (sqrt_p, L) is consistent with L = sqrt(x_v · y_v). Integrating from sqrt_p to the range boundary yields the amounts above. Inverse formulas (used when minting a position for a given amount0 or amount1): 
L_from_amount0(amount0, sqrt_lo, sqrt_hi, sqrt_p) =
    amount0 · sqrt_p · sqrt_hi / (sqrt_hi − sqrt_p)

L_from_amount1(amount1, sqrt_lo, sqrt_hi, sqrt_p) =
    amount1 / (sqrt_p − sqrt_lo)

// For a symmetric deposit into an in-range position, take the min.
L = min(L_from_amount0, L_from_amount1)

​
Single-tick swap step

Within a single tick range the pool behaves like a CPMM. Given current sqrt_p and target sqrt_target: 
Δamount0_step = L · (sqrt_target − sqrt_p) / (sqrt_p · sqrt_target)     // if swapping for token0
Δamount1_step = L · (sqrt_target − sqrt_p)                              // if swapping for token1

​
Exact-input step

Given Δin_remaining: 
// Candidate new sqrt_p if we filled to the tick boundary:
sqrt_after_full = sqrt_target
amount_to_full  = Δamount_in_to_reach(sqrt_p → sqrt_target)

if Δin_remaining ≥ amount_to_full:
    // consume the rest of the bucket
    sqrt_p'         = sqrt_target
    Δin_consumed    = amount_to_full
    Δout            = amount_out_at_boundary
else:
    // we don't cross; solve for the terminal sqrt_p
    sqrt_p'         = L · sqrt_p / (L + Δin_remaining · sqrt_p)      // for 0→1 swaps
    Δin_consumed    = Δin_remaining
    Δout            = L · (sqrt_p − sqrt_p')                          // proportional to Δsqrt
The 0→1 swap lowers sqrt_p (price declines as we sell token0 in). A 1→0 swap raises it. The formulas are symmetric with sqrt_p and sqrt_target swapped.

​
Exact-output step

Same structure, solving for Δin instead.

​
Multi-tick swap loop

A swap iterates over ticks until the input is exhausted or the price limit is hit: 
while Δin_remaining > 0 and sqrt_p != sqrt_price_limit:
    next_tick = find_next_initialized_tick(pool.tick_current, direction)
    sqrt_target = min(next_tick.sqrt_price, sqrt_price_limit)       // directionally

    (Δin, Δout, sqrt_p') = single_step(sqrt_p, sqrt_target, L, Δin_remaining)

    Δin_remaining -= Δin
    accumulated_out += Δout

    if sqrt_p' == next_tick.sqrt_price:
        // crossing the tick
        L += next_tick.liquidity_net * direction_sign
        flip_fee_growth_outside(next_tick)
        match_limit_orders_at_tick(next_tick, ...)        // see products/clmm/math
        pool.tick_current = next_tick.tick_index
    sqrt_p = sqrt_p'
Each single_step uses the pool’s current L. L changes only when crossing an initialized tick. Liquidity between ticks is constant, which is what makes the step math closed-form. liquidity_net at a tick is the signed sum of position liquidities that start at that tick minus those that end there. Crossing upward adds liquidity_net; crossing downward subtracts it. When the pool has limit orders open at a tick, the cross-tick step also opportunistically consumes part of the swap input to fill those orders (FIFO across cohorts). The matching algorithm and the dynamic-fee surcharge that may apply on top of the base step are documented in products/clmm/math; they don’t change the closed-form single-step formulas above.

​
Fee-growth accumulators

CLMM tracks fees per unit of active liquidity, per side, globally and per tick: 
fee_growth_global_0_x64     // Q64.64, monotone
fee_growth_global_1_x64
tick.fee_growth_outside_0_x64   // "fees accrued while this tick was outside the active range"
tick.fee_growth_outside_1_x64
On each single_step: 
step_lp_fee = (Δin · fee_rate) · (1 − protocol_fraction − fund_fraction)
fee_growth_global += step_lp_fee · 2^64 / L     // only for the input side
(The other side’s fee_growth_global does not move on this step, since no token on that side was paid as input.) When crossing a tick, the program flips fee_growth_outside: 
tick.fee_growth_outside_0_x64 = fee_growth_global_0_x64 − tick.fee_growth_outside_0_x64
tick.fee_growth_outside_1_x64 = fee_growth_global_1_x64 − tick.fee_growth_outside_1_x64
“Outside” is relative to tick_current. When tick_current is above the tick, outside means “below”. When tick_current is below, outside means “above”. The flip swaps the interpretation.

​
fee_growth_inside for a position

Given a position [tick_lower, tick_upper] and the current tick_current: 
if tick_current >= tick_upper:
    inside = tick_lower.fee_growth_outside − tick_upper.fee_growth_outside
else if tick_current < tick_lower:
    inside = tick_upper.fee_growth_outside − tick_lower.fee_growth_outside
else:     // position is in range
    inside = fee_growth_global
           − tick_lower.fee_growth_outside
           − tick_upper.fee_growth_outside
A position’s uncollected fees for token side s are: 
tokens_owed_s += L · (fee_growth_inside_s − fee_growth_inside_last_s) / 2^64
fee_growth_inside_last_s = fee_growth_inside_s
This update runs on every interaction with the position (IncreaseLiquidity, DecreaseLiquidity, CollectFees).

​
Worked example — crossing one tick

Pool (simplified):
  • sqrt_p_x64 = 2^64 · 1.0 = 2^64 (price = 1.0)
  • L = 1_000_000
  • tick_current = 0
  • Next initialized tick below: tick = −60, sqrt_price = 1.0001^(−30) ≈ 0.99700, liquidity_net = −400_000 (this tick ends a position, so a downward cross removes 400k)
  • Fee rate: 0.25%
Swap: Δin = 10_000 token0, direction = 0→1. Step 1 — up to sqrt_target = 0.99700 · 2^64: 
amount_in_to_target = L · (1/sqrt_target − 1/sqrt_p)
                    = 1_000_000 · (1/0.99700 − 1/1.0)
                    ≈ 1_000_000 · 0.003009
                    ≈ 3_009
3,009 < 10,000, so we fill this step completely: 
Δin_step  = 3_009 / (1 − 0.0025)  = 3_017    // gross of fee
Δout_step = L · (sqrt_p − sqrt_target) ≈ 1_000_000 · 0.00299 ≈ 2_990
sqrt_p    = 0.99700 · 2^64
tick_current = −60
L         = 1_000_000 + (−400_000)  = 600_000         // crossed the tick
fee_growth_outside at tick −60 is flipped
Δin_remaining = 10_000 − 3_017 = 6_983
Step 2 — with new L = 600_000: The next initialized tick (say tick = −120) is at sqrt = 0.99402. Recompute amount_in_to_target: 
amount_in_to_target = 600_000 · (1/0.99402 − 1/0.99700)
                    ≈ 600_000 · 0.003010
                    ≈ 1_806
Still less than Δin_remaining. Cross again. Continue until Δin_remaining reaches zero. The full sequence of Δout accumulates to the final swap output.

​
Initialization and overflow guards

  • MIN_SQRT_PRICE_X64 and MAX_SQRT_PRICE_X64 correspond to tick = ±443636. Any swap that would push sqrt_p outside this range reverts.
  • The user’s sqrt_price_limit parameter must lie in the same interval; the program checks.
  • Products of L · Δsqrt are computed in u256 then shifted back to u128 to avoid overflow.

​
Differences vs Uniswap v3

  • Oracle. Raydium’s ObservationState stores (block_timestamp, tick_cumulative, seconds_per_liquidity_cumulative) ring buffer; slightly different wire format from Uniswap’s but the same TWAP math.
  • Token-2022. Raydium CLMM supports Token-2022 mints; the transfer-fee variant requires additional pre/post-swap amount adjustments. See algorithms/token-2022-transfer-fees.
  • Tick bitmap. Raydium packs the initialized-tick bitmap into [u64; 16] per pool for fast find_next_initialized_tick; Uniswap uses a per-word on-chain mapping. The tradeoff is rent vs lookup cost.
  • Reward slots. Raydium supports 3 per-pool reward streams with separate reward_growth_global_x64 counters; same structure as the fee-growth accumulator.

​
Pointers

Sources:
  • Uniswap v3 whitepaper (canonical derivation of sqrt-price math).
  • Raydium CLMM program source.