Zum Hauptinhalt springen

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.

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

​
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 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: 
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.

​
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. 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

Quellen:
  • Uniswap v2 Whitepaper — die kanonische Aussage von x · y = k.
  • Raydium CPMM Programm-Quellcode.
  • Raydium AMM v4 Programm-Quellcode.