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 →

​
Eine-Absatz-Zusammenfassung

Das AMM-Routing-Programm fasst Multi-Hop-Swaps in einer einzigen On-Chain-Transaktion zusammen, die Liquidität über mehrere Pools verteilt. Sie geben eine Route an (eine Liste von Pools und Zwischen-Mints) und eine Instruction mit Slippage-Parametern an; der Router führt dann alle N Hops nacheinander aus und leitet die Ausgabe eines Pools in die Eingabe des nächsten weiter. Für die Preisberechnung ist keine separate On-Chain-Router-Logik erforderlich – jeder Hop handhabt seine Gebühren und Kurve über sein eigenes Pool-Programm mittels CPI – aber der Router orchestriert die Account-Übergabe und Token-Bewegung.

​
Warum ein separates Router-Programm?

Raydium-Clients und Aggregatoren können Multi-Hop-Swaps jederzeit clientseitig ohne den Router verketten: bauen Sie N Swap-Instructions (eine pro Pool) und reichen Sie sie in einer einzigen Transaktion ein. Warum dann ein dediziertes Router-Programm?

​
Gründe für die Nutzung des Routers

  1. CPI von anderen Programmen. Wenn Ihr eigenes Programm einen Route als Teil einer größeren Transaktion aufrufen muss (z. B. ein Liquiditäts-Manager, der Gebühren in ein Ziel-Token tauscht), ist ein CPI in den Router sauberer, als N untergeordnete CPIs zu bündeln und alle ihre Accounts in Ihrem Contract zu verwalten.
  2. Atomarer Account-Status. Die Account-Liste jedes Hops wird in einem einzigen Instruction-Kontext validiert. Wenn der Status eines Zwischen-Pools beschädigt ist oder eine Limit-Price-Assertion fehlschlägt, schlägt die gesamte Route atomar fehl, ohne dass es zu Teilausführungen kommt.
  3. Einzelne Instruction-Komposition. SDKs und Frontends können eine Multi-Hop-Route als einen logischen Vorgang darstellen, nicht als N separate Instructions, die zufällig aufeinander folgen.

​
Client-seitige Verkettung bleibt die Standardmethode

Für die meisten Anwendungen ist es einfacher, separate Swap-Instructions für jeden Pool zu erstellen und sie nacheinander einzureichen – und ist gleichermaßen gültig. Der Raydium SDK’s Trade.makeSwapTransaction und ähnliche Flows arbeiten für die meisten Routes genau so. Der Router ist eine Alternative, keine Ersetzung. Verwenden Sie ihn, wenn:
  • Sie ein Programm implementieren, das Routing als Teil einer größeren atomaren Operation benötigt.
  • Sie einen Aggregator bauen, der eine einzelne „Sende diese Route”-Operation möchte.

​
Wie es funktioniert

Eine Router-Instruction enthält:
  • Swap-Argumente: exakte Eingabe (amount_in, minimum_amount_out) oder exakte Ausgabe (maximum_amount_in, amount_out).
  • Route-Spezifikation: eine Liste von program_id + Kinder-Programm-Accounts für jeden Hop, in der richtigen Reihenfolge. Der Router liest den ersten Account in jeder Hop-Gruppe, um zu bestimmen, welches Programm aufgerufen werden soll.
  • Limit-Preise (für CLMM): eine VecDeque<u128> von sqrt_price_x64-Grenzen. Wird nur für Hops in CLMM-Pools verwendet; eine leere Deque ist ein Fehler für ältere Instruction-Varianten.
Der Router führt dann aus:
  1. Führt den ersten Hop aus: überweist amount_in (oder berechnet die erforderliche Eingabe für exakte Ausgabe) in den Input-Vault des ersten Pools, ruft den Swap dieses Pools auf und sammelt die Ausgabe ein.
  2. Verkettung nachfolgender Hops: für jeden Hop N wird die Ausgabe von Hop N−1 als Eingabe für Hop N verwendet.
  3. Erzwingt Slippage-Schutz: bei jedem CLMM-Hop wird sqrt_price gegen den entsprechenden limit_price geprüft; beim finalen Hop wird die Gesamtausgabe gegen die globale minimum_amount_out geprüft.
Zwischen-Tokens können entweder über benutzergesteuerte ATAs (eine pro Hop, langsamer aber transparent) oder über ein gemeinsames PDA-abgeleitetes Account (eine Adresse für alle Hops, schneller, opak) fließen.

​
Delegation von Preisen und Gebühren

Der Router berechnet keine Preise selbst. Jeder Hop delegiert an die Kurve des Kinder-Programms:
  • AMM v4: verwendet die Constant-Product-Formel mit OpenBook-Hybrid-Preisen.
  • CPMM: verwendet die Constant-Product-Formel mit dem konfigurierten Gebührensatz.
  • CLMM: verwendet die Concentrated-Liquidity-Mathematik mit Tick-basierten Preisen.
  • Stable: verwendet die Stable-Swap-Kurve für ähnliche Token.
Gebühren werden von jedem Pool nach seiner eigenen Konfiguration erhoben. Der Router selbst erhebt keine Gebühr.

​
Wann Sie den Router vermeiden sollten

  • Geringe Hop-Anzahl (1–2 Hops). Der Account-Weitergabe-Overhead ist minimal; verwenden Sie einfach zwei separate Swap-Instructions.
  • Nicht-Raydium-Pools. Der Router kennt nur die vier Raydium-Pool-Typen. Für Routes, die externe Programme kreuzen, verketten Sie Instructions in Ihrem Client.
  • Bedingte Routing. Wenn Sie während der Route auf Basis von Preisen oder Pool-Status verzweigen müssen, ist On-Chain-Routing weniger flexibel als Client-seitige Komposition.

​
Mentales Modell

Denken Sie des Routers als ein Transaction-Packing-Utility. Es nimmt Ihre Route-Spezifikation und packt sie in eine Instruction, eine Transaktion, ein Compute-Budget. Jeder Hop ruft intern sein Pool-Programm via CPI auf und behandelt die Kurven-Mathematik dort. Die Aufgabe des Routers ist es, Accounts korrekt zu übergeben, Tokens zwischen Hops zu verschieben und Slippage zu überprüfen.

​
Nächste Schritte