AMM v4 Mathematik

Constant-Product-Invariante mit AMM v4s Gebührenkonvention, Reserve-zu-Orderbuch-Preiskonvertierung, Zielorder-Gitterkonstruktion und der PnL-Abwicklungsschritt.

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

Englische Version ansehen →

​

Die Invariante

Der Pool erhält coin_reserve × pc_reserve = k, wobei (nach der 2026-07 OpenBook-Entfernung):

coin_reserve = coin_vault_balance - accrued_pnl_coin
pc_reserve   = pc_vault_balance   - accrued_pnl_pc

Zwei wichtige Punkte:

1. Reserven sind jetzt nur noch Vault-basiert. Der historische Open-Order-Term (Token, die der Pool als OpenBook-Limitaufträge hinterlegt hatte) wurde entfernt — er war in der Praxis lange vor der Entfernung ohnehin null. Sie können k direkt aus den On-Chain-Vault-Bilanzen berechnen.
2. Die PnL-Abgrenzung (need_take_pnl_*) wird subtrahiert, damit die Kurve erhalten bleibt, wenn der Admin Gebühren einzieht. Gleiches Prinzip wie die protocol_fees_*-Ausschließung bei CPMM.

Das Programm berechnet dies über calc_total_without_take_pnl_no_orderbook (die alte Orderbuch-bewusste Variante ist weg).

Jede Swap*-Operation erzwingt k' ≥ k, nachdem der LP-Gebührenanteil wieder in die Reserven addiert wurde.

​

Gebührenkonvention

AMM v4 verwendet Verhältnisgebühren (Zähler/Nenner-Paare) statt der 1/1_000_000-Konvention von CPMM / CLMM. Die On-Chain-Fees-Struktur (siehe Fees::initialize im Programmquellcode) hat folgende Standardwerte:

Fees {
  min_separate_numerator:    5,
  min_separate_denominator:  10_000,   //  5/10_000 = 0.05%

  trade_fee_numerator:      25,
  trade_fee_denominator:    10_000,    // 25/10_000 = 0.25% — verwendet für OpenBook-Limitorder-Preisgestaltung

  pnl_numerator:            12,
  pnl_denominator:          100,       // 12/100   = 12%   — Protokollanteil DER Swapgebühr

  swap_fee_numerator:       25,
  swap_fee_denominator:     10_000,    // 25/10_000 = 0.25% — Gesamtgebühr auf AMM-Pfad-Swaps
}

Interpretation (veröffentlichte Mainnet-Standardwerte):

• Gesamtswapgebühr: swap_fee = amount_in × 25 / 10_000 = 0.25% der Bruttoeingabe.
• Protokollanteil: pnl_numerator / pnl_denominator = 12 / 100 = 12% der Swapgebühr, was sich auf 0.25% × 12% = 0.03% des Volumens beläuft. Dieser Anteil wird in den PnL-Zählern abgegrenzt und durch WithdrawPnl eingezogen.
• LP-Anteil: die verbleibenden 88% der Swapgebühr, was sich auf 0.25% × 88% = 0.22% des Volumens beläuft. Bleibt im Pool und erhöht k.
• Kein Fondsanteil. AMM v4 hat keine CPMM/CLMM-Fondsgebührenaufteilung.

Beachten Sie, dass pnl_numerator / pnl_denominator ein Bruchteil der Gebühr ist, nicht des Handelsvolumens — eine häufige Fehlinterpretation dieser Feldnamen.

trade_fee_numerator / trade_fee_denominator (auch 25 / 10_000) wurde historisch von der OpenBook-Integration verwendet, wenn gebühreninklusive Preise für das Limitorder-Gitter des AMM berechnet wurden. Mit dem entfernten OpenBook-Code ist dieses Feld vestigial; die aktive Swapgebühr ist swap_fee_*.

Abweichungen von diesen Standardwerten sind selten, existieren aber auf einigen Legacy-Pools; lesen Sie die Gebühren immer aus AmmInfo.fees aus, bevor Sie ein Angebot machen.

​

Direkter Swap-Mathematik (AMM-Pfad)

Der einfachste Fall: Der Benutzer tauscht gegen die Vault-Reserven des Pools aus, ohne mit OpenBook zu interagieren. Die internen Reserven des Pools (einschließlich On-Book-Zuordnungen) sind der Nenner.

SwapBaseIn (exakte Eingabe):

amount_after_fee = amount_in − ceil(amount_in × swap_fee_numerator / swap_fee_denominator)
amount_out = amount_after_fee × out_reserve
           / (in_reserve + amount_after_fee)
require(amount_out >= minimum_amount_out)

Die hier verwendeten Reserven sind die Vault-Bilanzen (minus abgegrenzte PnL). Historisch addierte die Formel auch die Token, die der AMM in OpenBook-Aufträge gesperrt hatte; dieser Term wurde entfernt — die effektiven Reserven entsprechen jetzt den rohen Vault-Bilanzen abzüglich ausstehender PnL. Der MonitorStep / implizite Abwicklungspfad, der die OpenBook-Seite aktualisierte, wurde entfernt.

SwapBaseOut (exakte Ausgabe):

amount_in_after_fee = ceil(in_reserve × amount_out / (out_reserve − amount_out))
amount_in_gross     = ceil(amount_in_after_fee × swap_fee_denominator
                            / (swap_fee_denominator − swap_fee_numerator))
require(amount_in_gross <= maximum_amount_in)

​

Orderbuch-Interaktion (historisch)

Entfernt. Die in diesem Abschnitt beschriebene Gitterkonstruktion zeigt, wie AMM v4 ursprünglich die Kurve auf einen OpenBook-Markt spiegelte. Die OpenBook-Integration — einschließlich des MonitorStep-Cranks und der build_orders-Gitterlogik — wurde aus dem Programm entfernt (2026-07-Upgrade). Die folgende Mathematik wird rein als historischer Kontext bewahrt, um zu zeigen, wofür die On-Chain-Konten target_orders / amm_open_orders einmal dimensioniert waren.

Getrennt von Benutzer-Swaps platzierte AMM v4 historisch ein Gitter von Limitaufträgen auf dem OpenBook-Markt. Das Gitter wurde aus AmmInfo-Parametern berechnet:

• depth — Anzahl der Preisstufen pro Seite.
• amount_wave — Basiseinheit der Größe pro Stufe.
• min_size, coin_lot_size, pc_lot_size — OpenBook-Marktbeschränkungen.
• state_data.swap_acc_coin_fee, swap_acc_pc_fee — kumulative Gebührenzähler seit letztem TakePnl.

Das Programm leitet Preise pro Stufe ab, indem es vom aktuellen Kurvenpunkt in konstanten Verhältnisschritten ausgeht:

price_level(k) = curve_price × (1.0001 ^ k)       # konzeptionell
size_level(k)  = amount_wave × f(depth, k)        # verjüngt nach Tiefe

Die genauen Preise und Größen werden durch target_orders bestimmt, die in build_orders berechnet und mit amm_open_orders bei jedem MonitorStep verglichen werden. Jede Abweichung führt zu Stornierungen + neuen Aufträgen. Neu gefüllte Aufträge auf OpenBook werden bei der nächsten Operation, die die OpenBook-Seite aktualisiert, in die Pool-Vaults abgewickelt.

Integratoren müssen das Gitter selten berechnen — der Raydium-Keeper verwaltet es — aber es ist nützlich zu wissen, dass:

• Ein Pool mit signifikanter On-Book-Liquidität diese Liquidität zu k beitragen hat, nicht untätig sitzt.
• Ein veralteter OpenBook-Markt (Event-Queue voll, Cranks blockiert) verhindert Gitteraktualisierungen; der AMM kann dann Preise anbieten, die vom sichtbaren Orderbuch abweichen, bis zum nächsten Crank.

​

Abwicklungsschritt (PnL)

Der 0,03%-Protokollanteil wird in state_data.need_take_pnl_coin und state_data.need_take_pnl_pc abgegrenzt. TakePnl verschiebt diese Beträge aus den Vaults zum vom Admin angegebenen Ziel und setzt die Zähler dann auf null.

Entscheidende Eigenschaft: Reserven in der Invariante werden immer minus abgegrenzter PnL berechnet, daher verschiebt TakePnl die Kurve nicht. Dies entspricht der CPMM-Konvention.

​

Durchgerechnetes Beispiel

Pool-Status:

• coin_reserve = 1_000_000_000_000 (1.000.000 Coin-Seite; 6 Dezimalstellen)
• pc_reserve = 2_000_000_000_000 (2.000.000 PC-Seite; 6 Dezimalstellen)
• Gebühren: Standard swap = 25/10_000, pnl = 3/10_000.

Benutzer: SwapBaseIn exakte Eingabe 1_000_000_000 Coin (1.000 Coin).

swap_fee        = ceil(1_000_000_000 * 25 / 10_000)    = 2_500_000
amount_after_fee =                                      997_500_000

amount_out = amount_after_fee * pc_reserve
           / (coin_reserve + amount_after_fee)
           = 997_500_000 * 2_000_000_000_000
           / (1_000_000_000_000 + 997_500_000)
           ≈ 1_995_015_009  (1.995,015 PC)

// Von der 2_500_000 Swapgebühr:
pnl_share = 2_500_000 * 3 / 25  = 300_000    (geht zum Protokoll über need_take_pnl_coin)
lp_share  = 2_500_000 * 22 / 25 = 2_200_000  (bleibt in coin_reserve)

new coin_reserve = 1_000_000_000_000 + 1_000_000_000                 = 1_001_000_000_000
                   (davon 300_000 abgegrenzte PnL)
  curve coin_reserve = 1_001_000_000_000 − 300_000 = 1_000_999_700_000
new pc_reserve   = 2_000_000_000_000 − 1_995_015_009                 ≈ 1_998_004_984_991

k' = curve_coin_reserve * new_pc_reserve
   ≈ 2.000_002_701E24
k  = 1_000_000_000_000 * 2_000_000_000_000
   = 2.0E24
k' > k   ✓

Der LP-Anteil (2_200_000) wird nirgendwo separat aufgeschlüsselt — er ist einfach der Residuum, der k' erhöht.

​

Präzisionsregeln

• Reserve-Multiplikationen verwenden u128; endgültige Divisionen runden gegen null.
• swap_fee rundet auf (damit der Pool nicht unterberechnet).
• amount_in für SwapBaseOut rundet auf (damit der Benutzer nicht unterbezahlt).
• Pools mit extremen Reserveverhältnissen können bei sehr kleinen Eingaben auf ZeroTradingTokens treffen; gleiche Konvention wie CPMM.

​

Einschränkungen gegenüber CPMM

• AMM v4s Reserven sind jetzt nur noch Vault-basiert, daher können Sie direkt aus den Vault-Bilanzen anbieten (minus need_take_pnl_*) — die vorherige Anforderung, die open_orders.free / open_orders.locked-Beträge zu addieren, gilt nicht mehr. Das SDK / API-Angebot bleibt die einfachste Option.
• AMM v4 stellt keinen strukturierten On-Chain-TWAP bereit. Externe Verbraucher, die einen AMM-v4-gestützten Preis möchten, müssen ihn selbst aus Handelsprotokollen berechnen.
• Token-2022 wird nicht unterstützt.

​

Nächste Schritte

• products/amm-v4/instructions — wo SwapBaseIn, Deposit usw. eingebunden werden.
• products/amm-v4/fees — vollständige Gebührenmechanik, TakePnl-Details.
• algorithms/constant-product — die gemeinsame Herleitung.

Quellen:

• Raydium AMM Programmquellcode — raydium-io/raydium-amm
• Raydium SDK v2 Liquidity-Modul