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 →
Diese Seite ist die autoritative Anweisungsreferenz für das AMM-Routing-Programm. Für Code-Beispiele siehe products/routing/code-demos. Für Fehlererklärungen siehe reference/error-codes.

​
Übersicht der Anweisungen

TagDiskriminatorGenauVariante
0SwapBaseInWithUserAccountInputLegacy
1SwapBaseOutWithUserAccountOutputLegacy
5CreateSyncNative—Utility
6CloseTokenAccount—Utility
8SwapBaseInInputAktuell
9SwapBaseOutOutputAktuell
Legende:
  • Genau: Welcher Betrag vom Aufrufer festgelegt wird (Input = Exact-Input amount_in; Output = Exact-Output amount_out).
  • Variante: Legacy-Anweisungen erfordern eine nicht-leere limit_prices-Deque, auch wenn kein CLMM-Hop in der Route enthalten ist. Aktuelle Anweisungen (8 / 9) behandeln eine leere limit_prices als „keine Überprüfung”, was der empfohlene Weg für neuen Code ist.
Alle Swap-Varianten routen Zwischentokens über benutzergesteuerte ATAs — der Benutzer besitzt die Eingangs-ATA, jede Zwischen-ATA und die Ausgangs-ATA. Verwenden Sie für neue Integrationen Tag 8 (SwapBaseIn) oder Tag 9 (SwapBaseOut), es sei denn, Sie haben einen bestimmten Grund, eine Legacy-Variante aufzurufen.

​
Aktuelle Swap-Anweisungen (empfohlen)

Dies sind die Einstiegspunkte, die neuer Code verwenden sollte. Die Argumentstruktur ist identisch mit den Legacy-Varianten, aber limit_prices kann leer sein.

​
SwapBaseIn (Tag 8)

Exact-Input Multi-Hop-Swap. Der Aufrufer legt amount_in fest; der Router führt Hop für Hop aus und prüft, dass der endgültige Betrag bei oder über minimum_amount_out liegt. Argumente 
amount_in:            u64
minimum_amount_out:   u64
limit_prices:         VecDeque<u128>  // optional; leere Deque bedeutet keine Per-Hop-CLMM-Preischeck
Konten 
[
  <user_input_ata> W S,         // signer; balance >= amount_in
  <user_intermediate_ata_1> W,  // eine pro Zwischen-Hop
  ... <user_intermediate_ata_N> W,
  <user_output_ata> W,
  <token_program>,

  <pool_program_hop_1>,         // identifiziert, welche AMM-Familie Hop 1 ist
  <pool_state_hop_1> W,
  ... <other accounts required by hop 1's program>,

  <pool_program_hop_2>,
  <pool_state_hop_2> W,
  ... <hop 2 accounts>,

  ... [repeat per hop]
]
Die exakte Kontoliste pro Hop hängt vom zugrunde liegenden AMM-Programm ab (AMM v4 / CPMM / CLMM / Stable). Der Router ruft jedes nacheinander auf und validiert, dass die Programm-ID mit einem der vier unterstützten Programme übereinstimmt. Vorbedingungen
  • Der Aufrufer signiert mit user_input_ata.
  • user_input_ata.amount >= amount_in.
  • Jede Zwischen-Benutzer-ATA existiert und gehört dem Aufrufer.
  • Wenn ein Hop CLMM ist und Sie Preisgrenze-Erzwingung möchten, geben Sie einen limit_prices-Eintrag pro CLMM-Hop an.
Nachbedingungen
  • user_input_ata-Guthaben um amount_in verringert.
  • user_output_ata-Guthaben um ≥ minimum_amount_out erhöht.
  • Jede Zwischen-ATA verbleibt mit Null-Netto-Änderung (die Route verbraucht, was sie einen Hop früher produziert hat).
Häufige Fehler
  • ExceededSlippage — endgültiger Output < minimum_amount_out.
  • InvalidInput — leere Route, fehlgeformte Konten oder nicht unterstütztes pool_program.
  • SqrtPriceX64 — der Preis eines CLMM-Hops hat sich außerhalb der angegebenen limit_prices-Grenze bewegt (nur wenn limit_prices nicht leer ist).

​
SwapBaseOut (Tag 9)

Exact-Output Multi-Hop-Swap. Der Aufrufer legt amount_out fest; der Router prüft, dass der tatsächliche Input maximum_amount_in nicht überschreitet. Argumente 
maximum_amount_in:   u64
amount_out:          u64
limit_prices:        VecDeque<u128>  // optional; leere Deque bedeutet keine Per-Hop-CLMM-Preischeck
Konten — gleiche Struktur wie Tag 8. Vorbedingungen
  • Der Aufrufer signiert mit user_input_ata; Guthaben >= maximum_amount_in (schlimmster Fall).
  • Jede Zwischen- und die Ausgangs-ATA existieren.
Nachbedingungen
  • user_input_ata um den benötigten tatsächlichen Betrag verringert (≤ maximum_amount_in).
  • user_output_ata um genau amount_out erhöht.
Häufige Fehler
  • ExceededSlippage — erforderlicher Input überschreitet maximum_amount_in.
  • InvalidInput, SqrtPriceX64 — wie für Tag 8.

​
Legacy-Swap-Anweisungen

Diese älteren Varianten sind im Live-Programm noch aufrufbar und werden hier der Vollständigkeit halber dokumentiert. Bevorzugen Sie Tag 8 / Tag 9 für neuen Code; beide Legacy-Varianten unten erfordern eine nicht-leere limit_prices-Deque, auch wenn kein CLMM-Hop beteiligt ist, was sie umständlich zu verwenden macht.

​
SwapBaseInWithUserAccount (Tag 0)

Exact-Input Multi-Hop-Swap, identisch mit Tag 8 in Form, aber mit der strengeren limit_prices-Anforderung. Argumente 
amount_in:           u64
minimum_amount_out:  u64
limit_prices:        VecDeque<u128>  // erforderlich, nicht leer
Konten — gleiche Form wie SwapBaseIn (Tag 8). Alle Zwischen-Slots müssen ATAs sein, die dem Aufrufer gehören. Vorbedingungen
  • Der Aufrufer signiert mit user_input_ata.
  • user_input_ata.amount >= amount_in.
  • Alle Zwischen-Benutzer-ATAs existieren und gehören dem Aufrufer.
  • limit_prices ist nicht leer (ein Eintrag pro CLMM-Hop; füllen Sie mit Platzhalterwerten auf, wenn kein CLMM-Hop beteiligt ist).
Nachbedingungen
  • user_input_ata-Guthaben um amount_in verringert.
  • user_output_ata-Guthaben um ≥ minimum_amount_out erhöht.
Häufige Fehler
  • ExceededSlippage.
  • InvalidInput — leere limit_prices wird bei dieser Legacy-Variante abgelehnt.
  • SqrtPriceX64.

​
SwapBaseOutWithUserAccount (Tag 1)

Exact-Output-Swap, das Legacy-Gegenstück zu SwapBaseOut (Tag 9). Argumente 
maximum_amount_in:   u64
amount_out:          u64
limit_prices:        VecDeque<u128>  // erforderlich, nicht leer
Konten — gleiche Form wie Tag 0 / Tag 9. Vorbedingungen
  • Der Aufrufer signiert mit user_input_ata.
  • user_input_ata.amount >= maximum_amount_in.
  • Alle Zwischen-Benutzer-ATAs existieren und gehören dem Aufrufer.
  • limit_prices ist nicht leer.
Nachbedingungen
  • user_input_ata um den benötigten tatsächlichen Betrag verringert (≤ maximum_amount_in).
  • user_output_ata um genau amount_out erhöht.
Häufige Fehler
  • ExceededSlippage.
  • InvalidInput.
  • SqrtPriceX64.

​
Utility-Anweisungen

​
CreateSyncNative (Tag 5)

Erstellen Sie (falls fehlend) und synchronisieren Sie eine wSOL-ATA in einem Schritt. Praktisch beim Wrappen von SOL inline neben einem Swap. Argumente 
amount: u64    // SOL zum Wrappen (Lamports)
Konten 
[
  <user_wsol_ata> W,            // ATA für wSOL; wird erstellt, falls fehlend
  <user_native_account> W S,    // signer; SOL wird von hier abgebucht
  <wsol_mint>,
  <system_program>,
  <token_program>,
  <associated_token_program>,
]
Effekt
  • Erstellt user_wsol_ata, falls nicht vorhanden.
  • Überweist amount Lamports vom nativen SOL-Guthaben des Unterzeichners zur ATA.
  • Ruft SyncNative auf der ATA auf, damit sein Token-Guthaben die neuen Lamports widerspiegelt.
Häufige Fehler
  • InvalidOwner — der Besitzer von user_wsol_ata ist nicht der Unterzeichner.

​
CloseTokenAccount (Tag 6)

Schließen Sie ein Token-Konto und geben Sie seine Miete an die Zielgeldbörse zurück. Paart mit CreateSyncNative: Nach einem wSOL-Leg-Swap rufen Sie CloseTokenAccount auf, um die Miete wiederherzustellen, die die wSOL-ATA unterstützt hat. Argumente — keine. Konten 
[
  <token_account_to_close> W,
  <destination_for_rent> W,
  <owner> S,
  <token_program>,
]
Effekt
  • Schließt token_account_to_close.
  • Überweist den mietfreien Lamport-Saldo (~0,00203928 SOL im Mainnet für ein Vanilla-SPL-Token-Konto) zu destination_for_rent.
  • Das Token-Konto muss einen Token-Saldo von Null haben.
Häufige Fehler
  • InvalidOwner — der Aufrufer ist nicht der ATA-Besitzer.
  • Token-Kontosaldo ist nicht Null.

​
Weiterführende Ressourcen