> ## 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. # Constant-product AMM > Die x·y=k Invariante, reservebasierte Preisbildung, Slippage-Herleitung und die von Raydium CPMM und AMM v4 verwendeten Gebührenverarbeitungsvarianten. Dies ist die Referenzmathematik-Seite, zu der jedes x·y=k Produkt bei Raydium zurückverlinkt. **Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.** [Englische Version ansehen →](/algorithms/constant-product) ## Die Invariante Ein Constant-Product Market Maker (CPMM) verwaltet zwei Reserven `x` und `y` und erzwingt: ``` x · y ≥ k (nach jedem Trade) ``` wobei `k` das Produkt der Reserven vor dem Trade ist. Für einen gebührenfreien Markt gilt `x · y = k` exakt. Mit Gebühren wächst `k` streng (der LP-Anteil der Gebühr bleibt in den Reserven). Die Invariante ist bewusst geometrisch gestaltet: Sie garantiert, dass unabhängig davon, wie klein eine Reserve wird, die andere unbegrenzt wächst — das heißt, der Pool kann auf keiner Seite auf Null geleert werden. ## Preisbildung ### Spotpreis Der Grenzpreis von `y`, ausgedrückt in `x`, ist zu jedem Zeitpunkt die Tangente der Kurve: ``` p = y / x ``` (Herleitung: implizite Differentiation von `x · y = k` ergibt `dy/dx = −y/x`; den Betrag ignorierend, `|dy/dx| = y/x`). Dies ist der Preis, den der Pool für einen infinitesimal kleinen Trade anbietet. Bei jedem endlichen Trade ist der realisierte Preis aufgrund von Slippage entlang der Kurve schlechter. ### Exact-Input Swap (geben `Δx`, erhalten `Δy`) Mit Gebühren, sei `f` die Gebührenrate (z.B. `f = 0.0025` für 25 bps). Wenden Sie die Gebühr auf den Input an und verwenden Sie die Invariante, um den Output zu berechnen: ``` Δx_after_fee = Δx · (1 − f) Δy = y · Δx_after_fee / (x + Δx_after_fee) ``` Reserven nach dem Trade: ``` x' = x + Δx y' = y − Δy ``` Das vollständige `Δx` geht in die Reserven ein. Der LP-Anteil der Gebühr bleibt in `x'`; der Protokoll-Anteil wird durch einen separaten Buchungsschritt aus der Kurve ausgeschlossen (siehe [Fee accounting variants](#fee-accounting-variants) unten). ### Exact-Output Swap (erhalten `Δy`, bezahlen das minimal erforderliche `Δx`) ``` Δx_after_fee = x · Δy / (y − Δy) Δx = Δx_after_fee / (1 − f) ``` `Δx` wird aufgerundet, um sicherzustellen, dass der Pool nicht unterberechnet. ## Slippage und Preisauswirkung **Preisauswirkung** misst, wie sehr sich der Spotpreis des Pools aufgrund des Trades bewegt: ``` p_before = y / x p_after = y' / x' = (y − Δy) / (x + Δx) impact = (p_before − p_after) / p_before ``` Für kleine `Δx / x` ergibt eine Näherung erster Ordnung: ``` impact ≈ 2 · Δx / x (Gebühren ignorierend) ``` Intuition: Ein 1%-Swap verursacht ungefähr 2% Preisauswirkung. Dieser Faktor 2 ist der Grund, warum CPMM-Pools für mittlere Trades „dünn" erscheinen im Vergleich zu Orderbuch-Märkten — Sie kaufen nicht nur gegen das aktuelle beste Gebot, Sie gehen Ihre eigene Grenzpreis-Kurve hinauf. **Effektiver Preis**, den der Swapper bezahlt: ``` effective = Δx / Δy ``` Der Spread zwischen `p_before` und `effective` ist **Slippage**. On-Chain-`slippage` in UIs wird normalerweise als `(effective − p_before) / p_before` ausgedrückt; das SDK's `computeAmountOut` gibt sowohl `amountOut` als auch `priceImpact` aus diesem Grund zurück. ## Invarianten-Überprüfung im Code Nach einem Swap überprüfen Protokolle erneut: ``` k' = x' · y' ≥ k = x · y ``` Jede Verletzung ist ein Programm-Bug oder arithmetischer Overflow. Raydium's Swap-Anweisungen machen diese Überprüfung explizit als Nachbedingung: ```rust theme={null} let k_before = coin_reserve_before as u128 * pc_reserve_before as u128; let k_after = coin_reserve_after as u128 * pc_reserve_after as u128; require!(k_after >= k_before, ErrorCode::InvariantViolation); ``` ## Gebührenverarbeitungsvarianten Die Invarianten-Überprüfung setzt voraus, dass die LP-Gebühr in den Reserven bleibt. Verschiedene Raydium-Produkte handhaben die Protokoll-/Fonds-/Creator-Komponenten unterschiedlich: ### CPMM-Konvention Gebühren sind `u64` Basispunkt-ähnliche Sätze mit einem Nenner von `1_000_000`. Die Handelsgebühr wird in `trade_fee_rate` (Gesamt) unterteilt und dann über `protocol_fee_rate`, `fund_fee_rate`, `creator_fee_rate` aufgeschlüsselt. Bei jedem Swap: ``` trade_fee = ceil(Δx · trade_fee_rate / 1_000_000) protocol_fee = trade_fee · protocol_fee_rate / 1_000_000 fund_fee = trade_fee · fund_fee_rate / 1_000_000 creator_fee = trade_fee · creator_fee_rate / 1_000_000 lp_fee = trade_fee − protocol_fee − fund_fee − creator_fee ``` Die drei nicht-LP-Anteile werden in separaten Zählern (`protocol_fees_*`, `fund_fees_*`, `creator_fees_*`) aufsummiert, die **aus** den bei der Invarianten-Überprüfung verwendeten Reserven **ausgeschlossen** sind. So können Gebühren eingezogen werden, ohne die Kurve zu verschieben. Siehe [`products/cpmm/fees`](/de/products/cpmm/fees). ### AMM v4-Konvention Gebühren sind `numerator / denominator` Verhältnisse mit einem Nenner von `10_000`. Die Aufteilung ist bei der Pool-Erstellung fest und wird auf `AmmInfo.fees` gespeichert: ``` swap_fee = ceil(Δx · swap_fee_numerator / swap_fee_denominator) // z.B. 0,25% pnl_share = swap_fee · pnl_numerator / swap_fee_numerator // z.B. 0,03 / 0,25 = 12% lp_share = swap_fee − pnl_share // 0,22% des Volumens ``` `pnl_share` wird in `state_data.need_take_pnl_*` aufsummiert und aus Reserven ausgeschlossen; `lp_share` bleibt im Vault. Siehe [`products/amm-v4/fees`](/de/products/amm-v4/fees). Beide Konventionen bewahren die Invariante auf gleiche Weise — der Unterschied ist kosmetisch (Nenner + Anzahl der Unterkategorien). ## Rundungsregeln * **Gebührenberechnung rundet auf.** Stellt sicher, dass der Pool die Gebühr nicht unterberechnet. * **Ausgabemenge rundet ab.** Stellt sicher, dass die Invariante streng erfüllt bleibt (`k' > k` auch vor Gebühr). * **Exact-Output Input-Menge rundet auf.** Stellt sicher, dass der Benutzer nicht unterhalb bezahlt. Alle Arithmetik verwendet `u128` für die Zwischenprodukte `x · Δx`, um Overflow bei großen Reserven zu vermeiden. Endergebnisse werden auf `u64` mit Saturation-Überprüfung zurückgecastet. ## Edge Cases ### Leerer Pool Vor dem ersten `Deposit` ist `x = y = 0`. Swap-Anweisungen lehnen Pre-Deposit ab. ### Null-Output Wenn `Δx` klein genug ist, dass das abgerundete `Δy` 0 ist, wird die Anweisung mit `ZeroTradingTokens` zurückgewiesen. Dies verhindert Werteextraktion ohne Bezahlung; bedeutet auch, dass Staubswaps auf stark unausgeglichenen Pools fehlschlagen. ### Staub LP Der erste `Deposit` hat spezielle Behandlung: Er berechnet das initiale LP-Angebot als `sqrt(x · y)` und verbrennt einen kleinen „init burn" Betrag (normalerweise 100 LP-Einheiten), um den „First-Depositor Inflation Attack" zu verhindern (bei dem ein Angreifer an den Vault spendet und den LP-Token-Wert aufbläst). Nachfolgende Deposits verwenden Pro-Rata-Mathematik. ## Beziehung zu Arbitrage Der Preis eines CPMM-Pools ändert sich nur durch: 1. Trades durch den Pool selbst (Benutzer gehen die Kurve). 2. Spenden (Tokens an den Vault ohne Swap senden). Da Trades den Preis deterministisch mit der Kurve bewegen, erstellt jeder Pool, dessen Preis vom breiteren Marktpreis abweicht, eine Arbitrage-Gelegenheit. Arbitrageure bringen den Pool-Preis zurück zum Marktpreis in Erwartung. Darum wird gesagt, dass CPMM-Pools „einen Preis ohne Oracle anbieten": Der Markt findet den Preis durch Arbitrage, nicht indem der Pool ihn extern liest. Die Kehrseite: Der Pool selbst ist die Gegenpartei des Arbitrageurs, also ist jeder Arbitrage-Gewinn LP Impermanent Loss (minus der von LPs eingefangenen Gebühr). ## Durchgerechnete Beispiele ### Beispiel 1 — kleiner Trade, vernachlässigbarer Slippage Pool: `x = 1_000_000, y = 2_000_000, k = 2·10^12`. Gebühr `f = 0.0025`. Trade `Δx = 1_000`: ``` Δx_after_fee = 1000 · 0.9975 = 997.5 Δy = 2_000_000 · 997.5 / (1_000_000 + 997.5) = 1_995_000_000 / 1_000_997.5 ≈ 1_993.01 ``` Effektiver Preis: `1000 / 1993.01 ≈ 0.5018`. Spot vorher: `0.5`. Auswirkung: \~0,36%. ### Beispiel 2 — mittlerer Trade, sichtbarer Slippage Gleicher Pool, `Δx = 100_000` (10% von `x`): ``` Δx_after_fee = 100_000 · 0.9975 = 99_750 Δy = 2_000_000 · 99_750 / (1_000_000 + 99_750) = 199_500_000_000 / 1_099_750 ≈ 181_405 ``` Effektiv: `100_000 / 181_405 ≈ 0.5513`. Auswirkung: \~10,3% — ungefähr die Hälfte der `2 · 10% = 20%` Faustregel (die Regel ist eine Worst-Case-Obergrenze für eine gebührenfreie Constant-Product-Kurve; die Handelsgebühr plus die Umkehrung in der Formel bringt es hinunter). ## Hinweise * [`products/cpmm/math`](/de/products/cpmm/math) — CPMMs spezifische Rundungs- + Gebührendenominator-Wahlen. * [`products/amm-v4/math`](/de/products/amm-v4/math) — wie die OpenBook-integrierten Reserven von AMM v4 dieses Modell erweitern. * [`algorithms/slippage-and-price-impact`](/de/algorithms/slippage-and-price-impact) — dedizierte Seite zu Slippage-Toleranzauslegung für UIs. Quellen: * Uniswap v2 Whitepaper — die kanonische Aussage von `x · y = k`. * Raydium CPMM Programm-Quellcode. * Raydium AMM v4 Programm-Quellcode.