Routing-Anweisungen

Referenz für die AMM-Routing-Anweisungen im Mainnet — sechs Varianten für Exact-Input/Exact-Output-Swaps und wSOL-Utilities.

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

Tag	Diskriminator	Genau	Variante
0	SwapBaseInWithUserAccount	Input	Legacy
1	SwapBaseOutWithUserAccount	Output	Legacy
5	CreateSyncNative	—	Utility
6	CloseTokenAccount	—	Utility
8	SwapBaseIn	Input	Aktuell
9	SwapBaseOut	Output	Aktuell

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

• products/routing/code-demos — Erstellung jeder dieser Anweisungen in TypeScript.
• products/routing/accounts — Per-AMM-Dispatch-Keys und Per-Hop-Kontenlayout.
• reference/error-codes — vollständige RouteError-Liste.