CLMM-Mathematik

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →

Sqrt-Preis-Darstellung

CLMM speichert den Preis als sqrt_price_x64 — die Quadratwurzel des Token1-pro-Token0-Preises, als Q64.64-Festkommazahl:

\text{sqrt\_price\_x64} = \lfloor \sqrt{p} \cdot 2^{64} \rfloor

wobei p = token1_amount / token0_amount. Die Arbeit mit sqrt statt p linearisiert die Swap-Mathematik (Token-Mengen-Deltas werden linear in Δsqrt_price), und die x64-Festkommadarstellung erhält die Präzision über viele-Tick-Swaps hinweg. Die Tick ↔ Sqrt-Preis-Konvertierung wird über eine Bit-für-Bit-Logarithmus-Approximation vorberechnet:

\text{sqrt\_price\_x64}(t) \approx 2^{64} \cdot (1.0001)^{t/2}

implementiert als nachschlagbasierte Exponentiation in tick_math::get_sqrt_price_at_tick.

Liquidität als kanonische Einheit

Innerhalb eines Bereichs [sqrt_a, sqrt_b] (mit sqrt_a < sqrt_b) ordnet sich eine Position mit Liquidität L wie folgt Token-Mengen zu. Sei sqrt_c = sqrt_price_x64 der aktuelle Preis des Pools.

Fall	`amount0`	`amount1`
`sqrt_c <= sqrt_a` (Pool-Preis unter Bereich)	`L · (sqrt_b - sqrt_a) / (sqrt_a · sqrt_b)`	`0`
`sqrt_a < sqrt_c < sqrt_b` (im Bereich)	`L · (sqrt_b - sqrt_c) / (sqrt_c · sqrt_b)`	`L · (sqrt_c - sqrt_a)`
`sqrt_c >= sqrt_b` (Pool-Preis über Bereich)	`0`	`L · (sqrt_b - sqrt_a)`

Alle drei Identitäten folgen aus der Invariante x = L / sqrt_p, y = L · sqrt_p, die konzentrierte Liquidität innerhalb eines Bereichs erfüllt. Integratoren wünschen sich typischerweise die Umkehrung: Gegeben eine Einzahlung von amount0 / amount1, berechne das maximale L, das in den Bereich passt. Das SDK’s LiquidityMath.getLiquidityFromTokenAmounts macht dies. Die Formel für den In-Bereich-Fall:

L_0 = \text{amount0} \cdot \frac{\text{sqrt\_c} \cdot \text{sqrt\_b}}{\text{sqrt\_b} - \text{sqrt\_c}}, \qquad L_1 = \frac{\text{amount1}}{\text{sqrt\_c} - \text{sqrt\_a}}, \qquad L = \min(L_0, L_1)

Welche Seite bindet, bestimmt das tatsächlich verbrauchte Verhältnis; die andere Seite kann Reste haben.

Single-Tick-Swap-Schritt

Ein Swap verläuft in Schritten. Jeder Schritt entweder (a) verbraucht die gesamte verfügbare Eingabe innerhalb des aktuellen Tick-Bereichs, ohne einen Tick zu kreuzen, oder (b) bewegt den Preis genau zum nächsten initialisierten Tick. Gegeben der aktuelle Zustand (sqrt_c, L) und ein Swap nach unten (Token0 rein, Token1 raus, sqrt_price sinkt — Preis wird als token1/token0 notiert, also senkt das Hinzufügen von Token0 ihn), sitzt der nächste initialisierte Tick darunter bei sqrt_t < sqrt_c. Innerhalb dieses Mikro-Intervalls ist die Beziehung zwischen Eingabe und Preis:

\Delta\text{amount0} = L \cdot \left( \frac{1}{\text{sqrt\_t}} - \frac{1}{\text{sqrt\_c}} \right) = \frac{L \cdot (\text{sqrt\_c} - \text{sqrt\_t})}{\text{sqrt\_c} \cdot \text{sqrt\_t}}

und

\Delta\text{amount1} = L \cdot (\text{sqrt\_c} - \text{sqrt\_t})

Ein Token1-Eingabe-Swap ist das Spiegelbild: sqrt_price steigt zum nächsten Tick oben, und die beiden Formeln tauschen, welcher Endpunkt subtrahiert wird. Das Programm kodiert die Richtung als zero_for_one (true, wenn die Eingabe-Mint token_mint_0 ist), und ein zero_for_one-Swap klemmt gegen MIN_SQRT_PRICE_X64. Das Programm macht eines von zwei Dingen:

Passt die gesamte Eingabe? Wenn die verbleibende Eingabe (nach Gebühr) kleiner als Δamount0 ist, um sqrt_t zu erreichen, löse für das neue sqrt_c' exakt: $\text{sqrt\_c}' = \frac{L \cdot \text{sqrt\_c}}{L + \Delta\text{input} \cdot \text{sqrt\_c}}$ (für einen exakten-Eingabe token0 → token1 Swap). Der Swap endet in diesem Schritt, ohne einen Tick zu kreuzen.
Eingabe übersteigt Δamount0? Setze sqrt_c' = sqrt_t, kreuze den Tick (wende liquidity_net an), dekrementiere verbleibende Eingabe um Δamount0, inkrementiere Ausgabe um Δamount1, und wiederhole.

Für die entgegengesetzte Richtung (token1 → token0, Preis geht nach unten), haben die Formeln sqrt_c und sqrt_t getauscht und die Inversion im anderen Slot. Die vollständige Rust-Implementierung lebt in raydium-clmm/programs/amm/src/libraries/swap_math.rs. Die Logik dort entspricht Uniswap v3’s SwapMath.computeSwapStep eins-zu-eins.

Gebühren bei jedem Schritt

Handelsgebühren werden von der Eingabe-Menge in jedem Schritt abgezogen, gleiche Konvention wie CPMM:

step_fee_amount  = ceil(step_input * trade_fee_rate / 1_000_000)
step_net_input   = step_input - step_fee_amount
protocol_portion = floor(step_fee_amount * protocol_fee_rate / 1_000_000)
fund_portion     = floor(step_fee_amount * fund_fee_rate     / 1_000_000)
lp_portion       = step_fee_amount - protocol_portion - fund_portion

Der LP-Anteil wird über die aktuell-im-Bereich-Liquidität aufgeteilt, indem der globale Gebühren-Wachstums-Akkumulator aktualisiert wird:

\text{fee\_growth\_global}_{\text{in}} \mathrel{+}= \text{lp\_portion} \cdot \frac{2^{64}}{L}

— d.h., er wird in Gebühren pro Liquiditätseinheit denominiert, Q64.64, sodass eine Position der Größe L_i, die über diesen Swap im Bereich blieb, später L_i · Δfee_growth_global / 2^{64} geschuldete Token zurückliest. Die Protokoll- und Fund-Anteile sammeln sich in PoolState.protocol_fees_token_{0,1} und PoolState.fund_fees_token_{0,1} an, identisch mit CPMM. Sie werden durch CollectProtocolFee / CollectFundFee eingezogen.

Gebühren-Wachstum außerhalb und innerhalb

Der knifflige Teil der CLMM-Gebühren-Buchhaltung: Eine Position verdient Gebühren nur, während der Pool-Preis innerhalb ihres Bereichs ist. Der Pool verfolgt kumulative Gebühren global; die Position muss die kumulativen Gebühren während sie in ihrem spezifischen Bereich ist kennen. Die Lösung ist ein Tick-basierter Akkumulator. Jeder Tick speichert:

fee_growth_outside_0_x64
fee_growth_outside_1_x64

Im Moment der Tick-Initialisierung:

Wenn der Pool-Preis über diesem Tick ist (tick_current >= this_tick), ist fee_growth_outside = fee_growth_global. (Alles bisher Verdiente ist „außerhalb” — d.h., unterhalb — dieses Ticks, relativ zum aktuellen Preis.)
Sonst fee_growth_outside = 0.

Wenn der Preis einen Tick kreuzt, flippt das Programm den fee_growth_outside dieses Ticks:

\text{fee\_growth\_outside} \gets \text{fee\_growth\_global} - \text{fee\_growth\_outside}

Die Invariante, die dies bewahrt: Für jeden Tick t ist fee_growth_outside(t) gleich den Gebühren, die aufgelaufen sind, während tick_current auf der entgegengesetzten Seite von t war. Gebühren-Wachstum innerhalb eines Bereichs [tick_lower, tick_upper] wird dann abgeleitet:

if tick_current >= tick_upper:
    fee_growth_below = fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_global - fee_growth_outside(tick_upper)
elif tick_current >= tick_lower:
    fee_growth_below = fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_outside(tick_upper)
else:
    fee_growth_below = fee_growth_global - fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_outside(tick_upper)

fee_growth_inside = fee_growth_global - fee_growth_below - fee_growth_above

Dies ist die Uniswap-v3-Gebühren-Wachstums-Formel, unverändert.

Was eine Position speichert und was sie liest

Ein PersonalPositionState speichert fee_growth_inside_0_last_x64 und fee_growth_inside_1_last_x64: die fee_growth_inside-Werte beim letzten Mal, als die Position berührt wurde. Bei jeder nachfolgenden Berührung (Erhöhung, Verringerung, Einzug) macht das Programm:

Berechnet den aktuellen fee_growth_inside_{0,1}_x64 mit der obigen Formel.
Berechnet Δ = fee_growth_inside_now − fee_growth_inside_last (Modular-Subtraktion auf u128).
Addiert Δ × position.liquidity / 2^{64} zu tokens_fees_owed_{0,1}.
Aktualisiert fee_growth_inside_last auf den neuen Wert.

Token bewegen sich tatsächlich nur aus den Tresoren bei CollectFees / DecreaseLiquidity, gegen tokens_fees_owed.

Belohnungen

Jeder der bis zu 3 Belohnungsströme des Pools verwendet die gleiche Growth-Inside-Maschinerie, in seinem eigenen reward_growth_global_x64-Akkumulator. Zur Emissionszeit:

\text{reward\_growth\_global} \mathrel{+}= \text{emission\_per\_second} \cdot \Delta t \cdot \frac{2^{64}}{L}

— Emissionen skalieren umgekehrt mit aktiver Liquidität, sodass ein dichterer Pool jeder Position proportional weniger pro Sekunde zahlt, aber über mehr Positionen insgesamt. Die pro-Position geschuldete Belohnung ist

\text{reward\_owed} = (\text{reward\_growth\_inside}_{\text{now}} - \text{reward\_growth\_inside}_{\text{last}}) \cdot L / 2^{64}

und wird durch DecreaseLiquidity / DecreaseLiquidityV2 ausgezahlt — es gibt keine eigenständige Collect-Reward-Anweisung. Siehe /de/products/clmm/fees.

Durchgerechnetes Beispiel: Exakte-Eingabe-Swap

Angenommen:

tick_spacing = 60
sqrt_price_x64 = 1 × 2^{64} — Preis = 1,0, also tick_current = 0.
Aktive Liquidität L = 1_000_000 × 2^{64}.
Nächster initialisierter Tick darunter: t = −60 (sqrt_price_b ≈ 0.997005 × 2^{64}). Ein Token0-Eingabe-Swap bewegt sich nach unten, also ist der Tick oben hier irrelevant.
Handelsgebührsatz: 500 (0,05%).

Benutzer: SwapBaseInput exakte Eingabe 1.000 Token0. Schritt 1 — Gebühren:

trade_fee       = ceil(1000 * 500 / 1_000_000)  = 1
step_net_input  = 999

Schritt 2 — passt 999 innerhalb des aktuellen Tick-Bereichs?

Δ zum nächsten Tick (amount0):
  L · (sqrt_c - sqrt_t) / (sqrt_c * sqrt_t)
  ≈ 1_000_000 · (1 − 0.997005) / (1 · 0.997005)
  ≈ 3004.4 Token0

999 < 3004.4, also passt die gesamte Eingabe ohne Tick-Kreuzen. Schritt 3 — neuer Preis:

sqrt_c' = L · sqrt_c / (L + Δin · sqrt_c)
        = 1_000_000 · 1 / (1_000_000 + 999 · 1)
        ≈ 0.999002

d.h. sqrt_c' landet leicht unter sqrt_c, was die richtige Richtung ist: Ein token0 → token1 Swap fügt Token0 zum Pool hinzu und senkt daher den token1/token0-Preis. Schritt 4 — Ausgabemenge:

Δout Token1 = L · (sqrt_c − sqrt_c')
            = 1_000_000 · 0.000998
            ≈ 998.00

Nach Berücksichtigung von Rundungen erhält der Benutzer ≈ 998 Token1. Die Gebühr (1 Token0) wird zwischen LP, Protokoll und Fund durch trade_fee_rate × protocol_fee_rate / 1e6 (und ähnlich für Fund) aufgeteilt; der LP-Anteil fließt in fee_growth_global_0_x64.

Limit-Order-Matching während Swap

Wenn ein Swap-Schritt einen Tick kreuzt, der offene Limit-Orders hält, verbrauchen diese Orders Swap-Eingabe vor der LP-Kurve, zum exakten Preis des Ticks. Das Matching ist FIFO innerhalb des Ticks nach order_phase-Kohorte.

Pro-Kohorte-Zustand auf `TickState`

order_phase                  : u64    monotone Kohorten-ID
orders_amount                : u64    Eingabe-Token-Summe in der aktuellen (neuesten) Kohorte
part_filled_orders_remaining : u64    verbleibende Eingabe der Kohorte, die der Swap gerade füllt
unfilled_ratio_x64           : u128   Q64.64 Füllverhältnis für die teilweise gefüllte Kohorte

Das Zwei-Kohorten-Layout existiert, weil neue Orders auf einem Tick während eine ältere Kohorte noch gefüllt wird, geöffnet werden können. Neu geöffnete Orders treten orders_amount bei und erben die nächste order_phase; sie können nicht füllen, bis die vorherige Kohorte vollständig verbraucht ist.

Matching-Schritt

Pseudo-Code für das Matching, das bei jedem Tick-Kreuzen während eines Swaps passiert:

fn match_limit_orders_at_tick(tick, swap_input_remaining, sqrt_p):
    # 1. Versuche zuerst die teilweise gefüllte Kohorte zu füllen.
    if tick.part_filled_orders_remaining > 0:
        consume = min(tick.part_filled_orders_remaining, swap_input_remaining)
        # Aktualisiere das Unfilled-Verhältnis für diese Kohorte.
        tick.unfilled_ratio_x64 *= (1 - consume / tick.part_filled_orders_remaining)
        tick.part_filled_orders_remaining -= consume
        swap_input_remaining -= consume
        if tick.part_filled_orders_remaining == 0:
            tick.unfilled_ratio_x64 = 0
        if swap_input_remaining == 0: return

    # 2. Befördern Sie die aktive Kohorte.
    if tick.orders_amount > 0:
        tick.part_filled_orders_remaining = tick.orders_amount
        tick.orders_amount = 0
        tick.order_phase += 1
        tick.unfilled_ratio_x64 = ONE_X64
        # Rekursion mit der frisch beförderten Kohorte.
        return match_limit_orders_at_tick(tick, swap_input_remaining, sqrt_p)

    return  # Tick hat keine weiteren Limit-Orders

Ausgabe-Token, die an die Limit-Order-Besitzer gehen, werden nicht pro Swap übertragen. Sie sitzen virtuell im Ausgabe-Tresor des Pools, bis der Order-Besitzer SettleLimitOrder (oder DecreaseLimitOrder) aufruft. Der Pool verfolgt einfach, wie viel der Kohorte jetzt gefüllt ist, über unfilled_ratio_x64. Jeder LimitOrderState speichert seinen eigenen (order_phase, unfilled_ratio_x64)-Snapshot zur Öffnungszeit, sodass die Abwicklung sich reduziert auf:

filled_amount  = total_amount × (1 − tick_now.unfilled_ratio_x64 / order.unfilled_ratio_x64)
                if tick_now.order_phase > order.order_phase
                else 0
output_amount  = price_at(tick_index) × filled_amount   # angepasst für Richtung

Diese O(1)-Abwicklung ist der ganze Punkt des Kohorten-Designs — ein Tick kann beliebig viele Orders füllen, ohne Pro-Order-Gas.

Interaktion mit der LP-Kurve

In einem Swap-Schritt passiert Limit-Order-Matching am Tick (Null Δsqrt_price); LP-Kurven-Verbrauch passiert zwischen Ticks. Die Reihenfolge ist daher:

Kreuze Tick t_cross (wende LP liquidity_net-Änderung zuerst an, da dies wie Uniswap-V3 es macht).
Fülle alle Limit-Orders, die bei t_cross sitzen.
Fahre entlang der LP-Kurve zum nächsten initialisierten Tick oder bis swap_input-Erschöpfung fort.

Limit-Orders geben Händlern daher mehr effektive Liquidität genau zum Order-Tick-Preis (ein Preis-Verbesserungs-Effekt), auf Kosten von LPs, die keine Gebühren auf diesem Portion des Swap-Volumens verdienen — der Limit-Order-Portion des Handels ist gebührenfrei für den Swapper, da der Limit-Order-Placer als Maker agiert. Der dynamische Gebühren-Zuschlag (falls aktiviert) gilt immer noch für den LP-Portion des gleichen Swaps.

Dynamische Gebühren-Ableitung

PoolState.dynamic_fee_info trägt den Volatilitätszustand. Jeder Swap-Schritt berechnet den Pro-Schritt-Gebührensatz als:

\text{fee\_rate}_{\text{total}} = \text{trade\_fee\_rate}_{\text{config}} + \underbrace{\frac{\text{dynamic\_fee\_control} \cdot (\text{vol\_acc} \cdot \text{tick\_spacing})^2} {D_{\text{ctrl}} \cdot S_{\text{vol}}^2}}_{\text{dynamischer Zuschlag}}

wobei:

$D_{\text{ctrl}} = 100{,}000$ — DYNAMIC_FEE_CONTROL_DENOMINATOR
$S_{\text{vol}} = 10{,}000$ — VOLATILITY_ACCUMULATOR_SCALE
vol_acc ist der Pro-Swap-Akkumulator nach der Aktualisierungsregel unten
tick_spacing ist von PoolState.tick_spacing

Das Ergebnis wird bei

100{,}000 / 10^6 = 10\%

geklemmt.

Akkumulator-Aktualisierung

Zwei Regeln werden bei jedem Swap angewendet, in Reihenfolge: Verfall. Der Referenz-Boden verfällt basierend auf der Zeit seit der letzten Aktualisierung:

\text{vol\_ref} = \begin{cases} 0 & \text{wenn } \Delta t > \text{decay\_period} \\ \text{vol\_acc}_{\text{prev}} \cdot \dfrac{\text{reduction\_factor}}{10{,}000} & \text{wenn } \text{filter\_period} < \Delta t \le \text{decay\_period} \\ \text{vol\_ref}_{\text{prev}} & \text{wenn } \Delta t \le \text{filter\_period} \end{cases}

Akkumulieren. Der neue Akkumulator ist die Referenz plus Tick-Distanz, die seit dem vorherigen Referenz-Index durchquert wurde:

\text{vol\_acc} = \min\left( \text{vol\_ref} + \left| t_{\text{ref}} - t_{\text{now}} \right| \cdot S_{\text{vol}}, \text{max\_vol\_acc} \right)

tick_spacing_index_reference (

t_{\text{ref}}

) ist in Tick-Spacing-Einheiten, nicht rohen Ticks:

t_{\text{ref}} = \lfloor \text{tick\_current} / \text{tick\_spacing} \rfloor

Warum parabolisch in Tick-Distanz

Das Quadrieren des Akkumulators bedeutet, dass die Gebühr als das Quadrat steigt, wie weit der Preis von seinem Referenzpunkt entfernt gelaufen ist. Empirisch entspricht dies der Varianz-Skalierung des Preises unter Random-Walk-Druck: Eine 2×-Tick-Ausflug impliziert 4× die implizite Volatilität, also berechnet 4× den Zuschlag. Der dynamic_fee_control-Parameter kalibriert das absolute Niveau. Das filter_period-Fenster verhindert, dass winzige Sub-Sekunden-Oszillationen (z.B. MEV-Bots, die Sandwiching betreiben) den Akkumulator aufblähen. Das decay_period-Fenster verhindert, dass ein einzelner vergangener Spike Gebühren auf unbestimmte Zeit berechnet, nachdem der Markt sich beruhigt hat.

Numerische Robustheit

Alle Zwischenprodukte gehen durch u128- oder u256-förmige Arithmetik. CLMM verwendet U128Sqrt-Helfer und FullMath::mulDiv-Muster, direkt von Uniswap v3 portiert.
Divisions-Rundung wird pro-Schritt gewählt, um die Invariante k' ≥ k lokal durchzusetzen. SwapBaseInput rundet Ausgabe ab; SwapBaseOutput rundet Eingabe auf.
Tick-Kreuze, die PoolState.liquidity auf Null senken, sind erlaubt (der Preis kann ein „Liquiditätsloch” durchqueren), aber der Swap rückt einfach zum nächsten initialisierten Tick vor, ohne Eingabe zu verbrauchen, und berechnet keine Gebühr.
Overflow-Schutz: sqrt_price_x64 wird im inklusiven Bereich [MIN_SQRT_PRICE_X64, MAX_SQRT_PRICE_X64] gehalten, entsprechend [MIN_TICK, MAX_TICK]. Ein Swap, der eine Grenze überschreiten würde, wird mit SqrtPriceLimitOverflow zurückgewiesen.

Wo es weitergeht

/de/products/clmm/ticks-and-positions für wie die Tick-Karte am Spaziergang teilnimmt.
/de/products/clmm/fees für die Gebühren-/Belohnungs-Seite der Mathematik im Detail.
/de/algorithms/clmm-math für die Ableitungen hinter L = sqrt(x · y) und den Bereichs-vs-Liquiditäts-Formeln.

Quellen:

raydium-io/raydium-clmm — libraries/swap_math.rs, libraries/tick_math.rs
“Uniswap v3 Core” Whitepaper, §6–7

Produkte

Algorithmen

Sqrt-Preis-Darstellung

Liquidität als kanonische Einheit

Single-Tick-Swap-Schritt

Gebühren bei jedem Schritt

Gebühren-Wachstum außerhalb und innerhalb

Was eine Position speichert und was sie liest

Belohnungen

Durchgerechnetes Beispiel: Exakte-Eingabe-Swap

Limit-Order-Matching während Swap

Pro-Kohorte-Zustand auf `TickState`

Matching-Schritt

Interaktion mit der LP-Kurve

Dynamische Gebühren-Ableitung

Akkumulator-Aktualisierung

Warum parabolisch in Tick-Distanz

Numerische Robustheit

Wo es weitergeht

​Sqrt-Preis-Darstellung

​Liquidität als kanonische Einheit

​Single-Tick-Swap-Schritt

​Gebühren bei jedem Schritt

​Gebühren-Wachstum außerhalb und innerhalb

​Was eine Position speichert und was sie liest

​Belohnungen

​Durchgerechnetes Beispiel: Exakte-Eingabe-Swap

​Limit-Order-Matching während Swap

​Pro-Kohorte-Zustand auf TickState

​Matching-Schritt

​Interaktion mit der LP-Kurve

​Dynamische Gebühren-Ableitung

​Akkumulator-Aktualisierung

​Warum parabolisch in Tick-Distanz

​Numerische Robustheit

​Wo es weitergeht

Sqrt-Preis-Darstellung

Liquidität als kanonische Einheit

Single-Tick-Swap-Schritt

Gebühren bei jedem Schritt

Gebühren-Wachstum außerhalb und innerhalb

Was eine Position speichert und was sie liest

Belohnungen

Durchgerechnetes Beispiel: Exakte-Eingabe-Swap

Limit-Order-Matching während Swap

Pro-Kohorte-Zustand auf `TickState`

Matching-Schritt

Interaktion mit der LP-Kurve

Dynamische Gebühren-Ableitung

Akkumulator-Aktualisierung

Warum parabolisch in Tick-Distanz

Numerische Robustheit

Wo es weitergeht