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

# AMM v4 Mathematik

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

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

  [Englische Version ansehen →](/products/amm-v4/math)
</Info>

## 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`](https://github.com/raydium-io/raydium-amm/blob/master/program/src/state.rs) 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)

<Note>
  **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.
</Note>

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`](/de/products/amm-v4/instructions) — wo `SwapBaseIn`, `Deposit` usw. eingebunden werden.
* [`products/amm-v4/fees`](/de/products/amm-v4/fees) — vollständige Gebührenmechanik, `TakePnl`-Details.
* [`algorithms/constant-product`](/de/algorithms/constant-product) — die gemeinsame Herleitung.

Quellen:

* [Raydium AMM Programmquellcode — `raydium-io/raydium-amm`](https://github.com/raydium-io/raydium-amm)
* Raydium SDK v2 `Liquidity`-Modul