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

# Routing-Mathematik

> Der Router führt selbst keine Preisberechnung durch; jeder Hop delegiert an die Kurvenfunktion seines Pool-Programms. Multi-Hop-Slippage ist kumulativ; CLMM-Hops verwenden limit_prices.

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

  [Englische Version ansehen →](/products/routing/math)
</Info>

## Der Router führt keine Berechnungen durch

Das Routing-Programm **implementiert keine Preislogik**. Es ist ein reiner Orchestrator: Es akzeptiert eine Route, übergibt Konten an untergeordnete Programme und verkettelt Token-Flüsse.

Jeder Hop berechnet Preise anhand seiner eigenen Pool-Programmkurve:

* **AMM v4 Hops:** verwenden die Constant-Product-Formel (`x · y = k`) mit OpenBook-Hybrid-Preisgestaltung. Siehe [`products/amm-v4/math`](/de/products/amm-v4/math).
* **CPMM Hops:** verwenden die Constant-Product-Formel mit konfigurierbaren Gebührentafeln. Siehe [`products/cpmm/math`](/de/products/cpmm/math).
* **CLMM Hops:** verwenden konzentrierte Liquiditäts-Tick-Mathematik. Siehe [`algorithms/clmm-math`](/de/algorithms/clmm-math).
* **Stable Hops:** verwenden die Stable-Swap-Kurve für ähnliche Assets. Siehe [`products/stable/math`](/de/products/stable/math).

Die einzige Beteiligung des Routers ist:

1. Aufrufen der Swap-Anweisung jedes Pools über CPI.
2. Erfassung des Ausgabebetrags.
3. Übergabe als Eingabebetrag an den nächsten Hop.
4. Überprüfung der endgültigen Ausgabe gegen das Slippage-Limit des Aufrufers.

## Slippage-Kumulierung

Bei einer Multi-Hop-Route ist der Slippage bei jedem Hop kumulativ. Ein kleiner Slippage bei Hop 1 wird zu einem größeren Slippage bei Hop 2, da das Volumen in Hop 2 bereits reduziert ist.

**Beispiel:**

```
Route: USDC → SOL → STEP

Pool 1 (USDC / SOL):
  Input: 1000 USDC
  Slippage: 1% (Spot würde 0,5 SOL geben, aber Sie erhalten 0,495 SOL)
  Output: 0,495 SOL

Pool 2 (SOL / STEP):
  Input: 0,495 SOL (bereits reduziert)
  Slippage: 1% (Spot würde 495 STEP geben, aber Sie erhalten 490 STEP)
  Output: 490 STEP

Gesamter effektiver Slippage auf USDC → STEP: 1,99%, nicht 1% + 1% = 2%.
```

Wenn Sie `minimum_amount_out` angeben, überprüft der Router Ihre endgültige Ausgabe gegen dieses globale Limit. Jeder Hop überprüft auch seinen eigenen Swap gegen seine lokale Gebührenstruktur, aber der Router führt keine Neuberechnung während der Route durch – Sie müssen die Route vorberechnen und ausreichende Slippage-Toleranz einplanen.

## CLMM Hops und limit\_prices

Für jeden Hop in einen CLMM-Pool überprüft der Router, dass der aktuelle `sqrt_price_x64` des Pools innerhalb einer angegebenen Grenze liegt. Die Grenzen werden als `VecDeque<u128>` namens `limit_prices` übergeben:

* Ein `sqrt_price_x64` pro CLMM-Hop in der Route.
* `sqrt_price_x64` ist die Tick-basierte Preisdarstellung, die von CLMM verwendet wird. Siehe [`algorithms/clmm-math`](/de/algorithms/clmm-math) für die Definition.
* Der Router erzwingt:

```
  sqrt_price_lower <= pool.sqrt_price_x64 <= sqrt_price_upper
```

für jeden CLMM-Hop und lehnt den Swap ab, wenn der Preis außerhalb der Grenzen liegt.

### Anweisungsvarianten und limit\_prices

* **`SwapBaseInWithUserAccount`, `SwapBaseOutWithUserAccount` (Legacy, Tags 0 und 1):** die `limit_prices` VecDeque ist **erforderlich**. Eine leere Deque wird mit einem Fehler abgelehnt, wenn ein Hop ein CLMM-Pool ist. Sie müssen einen Preis pro CLMM-Hop in der richtigen Reihenfolge angeben.

* **`SwapBaseIn`, `SwapBaseOut` (Aktuell, Tags 8 und 9):** die `limit_prices` VecDeque ist **optional**. Eine leere Deque wird stillschweigend ignoriert; keine Preisüberprüfung wird durchgeführt. Neuer Code sollte diese verwenden.

### Erstellen von limit\_prices

Für eine Route mit M CLMM-Hops sollte die Deque genau M Einträge enthalten. Ordnen Sie sie nach Hop:

```
limit_prices = [
  sqrt_price_for_first_clmm_hop,
  sqrt_price_for_second_clmm_hop,
  ...
]
```

### Wann limit\_prices überprüft werden

Der `sqrt_price_x64` ist ein Snapshot des aktuellen Preises des Pools. Er ändert sich kontinuierlich, während Swaps ausgeführt werden. Sie sollten:

1. Den aktuellen Zustand des Pools von der Blockchain abrufen.
2. Akzeptable Grenzen berechnen (z. B. ±0,5% des aktuellen Preises).
3. Diese Grenzen in `limit_prices` kodieren.
4. Die Grenzen in Ihre Router-Anweisung einbeziehen.

Wenn der Preis des Pools vor dem Landen der Transaktion über Ihre Grenzen hinaus driftet, lehnt der Router sie ab.

## Gebührenbehandlung

Jeder Pool erhebt seine eigene Gebühr gemäß seiner Konfiguration:

* **AMM v4:** 0,25% (fest) aufgeteilt zwischen LP, Protokoll und Fonds.
* **CPMM:** konfigurierbar pro `AmmConfig` (Standard 0,25%, Aufteilung variiert je nach Tier).
* **CLMM:** konfigurierbar pro Pool, vom Eingabebetrag abgezogen.
* **Stable:** 0,02% (fest), aufgeteilt 88% LP / 12% Protokoll.

Der Router **erhebt selbst keine Gebühr**. Die gesamte Gebührenbehandlung wird an jeden untergeordneten Pool delegiert. Die Ausgabe von Hop N hat bereits die Gebühr dieses Hops abgezogen.

Siehe die Gebührendokumentation des einzelnen Pools:

* [`products/amm-v4/fees`](/de/products/amm-v4/fees)
* [`products/cpmm/fees`](/de/products/cpmm/fees)
* [`products/clmm/fees`](/de/products/clmm/fees) (falls verfügbar)
* [`products/stable/fees`](/de/products/stable/fees) (falls verfügbar)

## Multi-Hop-Abrechnungsbeispiel

Angenommen, Sie routen USDC → SOL → STEP über zwei Constant-Product-Pools, jeweils mit einer Gebühr von 0,25%:

```
Input: 1000 USDC
Pool 1 (USDC/SOL):
  Gebühr: ceil(1000 * 0,25%) = 2,5 USDC
  Netto-Input zur Kurve: 997,5 USDC
  Kurven-Output (vor Slippage): 0,5 SOL
  Slippage-Marge: angenommen 1%, also erhalten Sie ~0,495 SOL

Pool 2 (SOL/STEP):
  Input: 0,495 SOL
  Gebühr: ceil(0,495 * 0,25%) ≈ 0,001 SOL
  Netto-Input zur Kurve: 0,494 SOL
  Kurven-Output: ~494 STEP
  Slippage-Marge: 1%, also erhalten Sie ~489 STEP

Endgültige Ausgabe: ~489 STEP
```

Der Router überprüft:

```
489 >= minimum_amount_out  // vom Aufrufer angegeben
```

Falls falsch, schlägt die gesamte Route atomar fehl.

## Genauigkeitsüberlegungen

Wie alle Solana-Programme verwendet der Router Integer-Arithmetik:

* Alle Beträge sind `u64` (Lamports oder kleinste Token-Einheiten).
* Kurvenberechnungen verwenden `u128` Zwischenwerte, wo nötig, um Überläufe zu vermeiden.
* Rundungskonventionen hängen vom untergeordneten Programm ab. Der Router führt keine Neuberechnung durch.

Wenn ein Hop aufgrund extremer Preisquoten einen Nullbetrag erzeugt (z. B. Swap von 1 Lamport auf einem 1B:1-Pool), leitet der Router diese Null an den nächsten Hop weiter, der sie möglicherweise als unzureichend ablehnt. Siehe die Fehlercodes des einzelnen Pools.

## Nächste Schritte

* [`products/amm-v4/math`](/de/products/amm-v4/math) — Constant-Product-Mathematik.
* [`products/cpmm/math`](/de/products/cpmm/math) — CPMM Constant-Product mit Token-2022.
* [`algorithms/clmm-math`](/de/algorithms/clmm-math) — konzentrierte Liquiditätspreisgestaltung.
* [`products/stable/math`](/de/products/stable/math) — Stable-Swap-Kurve.
* [`products/routing/code-demos`](/de/products/routing/code-demos) — Beispiele für Quoting vor dem Routing.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.