Transaction-API-Übersicht

Server-seitiger Swap-Transaktions-Builder für Solana.

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

Englische Version ansehen →

​

Was ist die Transaction API?

Die Raydium Transaction API (Route V2) ist ein Server-seitiger Service, der serialisierte Solana-Swap-Transaktionen erstellt, ohne dass Clients eine RPC-Verbindung aufrechterhalten oder das gesamte Raydium SDK einbinden müssen. Dies vereinfacht die Integration erheblich für:

• Web-Frontends, die keinen lokalen RPC-Client ausführen können
• Mobile Anwendungen mit begrenzten Ressourcen
• Headless-Trading-Bots
• Aggregatoren und Wallet-Provider

Anstatt komplexes Pool-Routing und Transaktionserstellung auf dem Client durchzuführen, fordern Sie Swap-Quotes und Transaktionserstellung von unserer API an, signieren dann das Ergebnis und broadcasten es über beliebige Solana-RPCs.

​

Workflow-Übersicht

Die Transaction API unterteilt die Aufgaben in zwei Phasen:

​

1. Compute-Phase: Quote abrufen

Rufen Sie /compute/swap-base-in oder /compute/swap-base-out auf, um die erwartete Swap-Ausgabe (oder erforderliche Eingabe) basierend auf aktuellen Pool-Zuständen zu erhalten. Dieser Endpoint ist schreibgeschützt und erfordert keine Signierung:

GET /compute/swap-base-in?inputMint=EPjF...&outputMint=So111...&amount=1000000&slippageBps=50&txVersion=V0

Die Antwort enthält:

• Erwarteter Ausgabebetrag
• Route-Aufschlüsselung (welche Pools und Liquiditätsquellen werden verwendet)
• Preisauswirkung

​

2. Transaction-Phase: Erstellen und signieren

Sobald Sie die Compute-Antwort haben, übergeben Sie diese (zusammen mit Wallet und Konfiguration) an /transaction/swap-base-in oder /transaction/swap-base-out:

POST /transaction/swap-base-in
Content-Type: application/json

{
  "wallet": "YourWalletAddress",
  "swapResponse": { ...response from /compute/swap-base-in },
  "txVersion": "V0",
  "computeUnitPriceMicroLamports": "1000",
  "wrapSol": false,
  "unwrapSol": false,
  "inputAccount": "TokenAccount1...",
  "outputAccount": "TokenAccount2..."
}

Die Antwort enthält:

• Eine Base64-codierte versionierte Transaktion, bereit zum Signieren
• Adressen von Address Lookup Tables (falls txVersion=V0)

Ihr Client:

1. Dekodiert die Transaktion
2. Signiert sie mit dem Keypair des Benutzers
3. Broadcastet sie über beliebige Solana-RPCs
4. Wartet auf Bestätigung

​

Compute-Endpoints

​

GET /compute/swap-base-in

Anwendungsfall: Benutzer gibt einen Eingabebetrag an, wir berechnen die Ausgabe.

Erforderliche Query-Parameter:

• inputMint – Mint-Adresse des Token, den Sie senden
• outputMint – Mint-Adresse des Token, den Sie möchten
• amount – Eingabebetrag in Lamports (kleinste Einheit)
• slippageBps – Maximale akzeptable Slippage in Basispunkten (0–10000)
• txVersion – V0 oder LEGACY

Optional:

• referrerBps – Falls Sie eine Referrer-Autorität haben, Basispunkte der Ausgabe zur Erfassung als Referrer-Gebühr

​

GET /compute/swap-base-out

Anwendungsfall: Benutzer gibt die gewünschte Ausgabe an, wir berechnen die erforderliche Eingabe.

Erforderliche Query-Parameter:

• inputMint, outputMint, amount (gewünschte Ausgabe), slippageBps, txVersion

Hinweis: Keine Referrer-Basispunkte für base-out (noch nicht implementiert).

​

Transaction-Endpoints

​

POST /transaction/swap-base-in

Erstellt eine Transaktion für einen festen Eingabebetrag.

Erforderliche Body-Parameter:

• wallet – Ihre signierende Wallet-Adresse
• swapResponse – Das gesamte Compute-Response-Objekt
• txVersion – Transaktionsversion
• computeUnitPriceMicroLamports – Prioritätsgebühr in Micro-Lamports

Optional:

• wrapSol – Falls true, native SOL für Eingabe wrappen
• unwrapSol – Falls true, WSOL zu SOL in Ausgabe unwrappen
• inputAccount – Token-Konto für Eingabe (erforderlich falls nicht SOL wrapping)
• outputAccount – Token-Konto für Ausgabe
• nonceInfo – Dauerhaft Nonce für Offline-Signierung
• jitoInfo – Jito MEV-Schutz-Bundle-Parameter
• referrerWallet – Referrer-Wallet für Gebührenerfassung

​

POST /transaction/swap-base-out

Erstellt eine Transaktion für einen festen Ausgabebetrag.

Gleiche Parameter wie base-in, außer:

• referrerInfo-Feld ist derzeit auskommentiert (noch nicht implementiert)

​

Response-Hülle

Alle Endpoints geben eine Standard-Hülle zurück:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "success": true,
  "version": "V1",
  "data": { ... }
}

Bei Fehler ist success false und msg enthält den Fehlercode (z.B. REQ_WALLET_ERROR, REQ_SLIPPAGE_BPS_ERROR).

​

Transaction-Response-Format

Eine erfolgreiche Transaction-Antwort sieht folgendermaßen aus:

{
  "id": "...",
  "success": true,
  "version": "V1",
  "data": {
    "transaction": "AgABB...",  // Base64-codierte Transaktion
    "addressLookupTableAddresses": ["Address1...", "Address2..."]  // Nur für V0
  }
}

​

Integrations-Beispiel

Hier ist ein typischer Ablauf in Pseudocode:

// 1. Quote abrufen
const quote = await fetch(
  'https://transaction-v1.raydium.io/compute/swap-base-in?' +
  'inputMint=EPjF...&outputMint=So111...&amount=1000000&slippageBps=50&txVersion=V0'
).then(r => r.json());

// 2. Quote validieren
if (!quote.success) {
  throw new Error(quote.msg);
}

// 3. Transaktion erstellen
const tx = await fetch(
  'https://transaction-v1.raydium.io/transaction/swap-base-in',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      wallet: userWalletAddress,
      swapResponse: quote,
      txVersion: 'V0',
      computeUnitPriceMicroLamports: '1000',
      inputAccount: userInputTokenAccount,
      outputAccount: userOutputTokenAccount,
    }),
  }
).then(r => r.json());

// 4. Dekodieren und signieren
const transaction = VersionedTransaction.deserialize(
  Buffer.from(tx.data.transaction, 'base64')
);
transaction.sign([userKeypair]);

// 5. Über RPC senden
const rpc = new Connection('https://api.mainnet-beta.solana.com');
const sig = await rpc.sendTransaction(transaction);
await rpc.confirmTransaction(sig);

​

Wichtige Parameter erklärt

​

txVersion

• V0: Moderne Solana-Transaktion mit Address Lookup Tables (ALTs). Kleinere Serialisierungsgröße, niedrigere Gebühren.
• LEGACY: Pre-ALT-Transaktionsformat. Größer, funktioniert aber mit allen RPC-Endpoints.

Wählen Sie V0, wenn möglich; fallen Sie auf LEGACY zurück, wenn Ihr RPC oder Wallet ALTs nicht unterstützt.

​

computeUnitPriceMicroLamports

Prioritätsgebühr für schnellere Block-Einbindung. Setzen Sie auf 0 für keine Prioritätsgebühr, oder höhere Werte (z.B. 1000), um in überlasteten Netzwerken zu konkurrieren. Einheiten sind Micro-Lamports pro Compute Unit.

​

slippageBps

Maximale Slippage-Toleranz in Basispunkten. 100 = 1%, 50 = 0,5%.

• Verwenden Sie niedrigere Werte (z.B. 25–50 bps) für die meisten stabilen Swaps
• Erhöhen Sie für volatile oder illiquide Paare

​

wrapSol und unwrapSol

• wrapSol: Falls true, wickelt die API Ihre native SOL in WSOL ein. Kein inputAccount erforderlich.
• unwrapSol: Falls true, wickelt die API die Ausgabe WSOL zurück zu native SOL aus. Kein outputAccount erforderlich.

Falls beide false sind, müssen Sie explizite Token-Konten angeben.

​

Netzwerk-Endpoints

Netzwerk	Mainnet	Devnet
Host	transaction-v1.raydium.io	transaction-v1-devnet.raydium.io
Protokoll	HTTPS	HTTPS

​

Fehlercodes

Häufige Fehlermeldungen:

Code	Bedeutung
REQ_SLIPPAGE_BPS_ERROR	Slippage ist ungültig oder außerhalb des Bereichs
REQ_INPUT_MINT_ERROR	Eingabe-Mint-Adresse ist ungültig
REQ_OUTPUT_MINT_ERROR	Ausgabe-Mint-Adresse ist ungültig
REQ_AMOUNT_ERROR	Betrag ist keine gültige Zahl
REQ_TX_VERSION_ERROR	txVersion muss V0 oder LEGACY sein
REQ_WALLET_ERROR	Wallet-Adresse ist ungültig
REQ_INPUT_ACCOUT_ERROR	Eingabe-Token-Konto fehlt oder ist ungültig
REQ_OUTPUT_ACCOUT_ERROR	Ausgabe-Token-Konto fehlt oder ist ungültig
UNKNOWN_ERROR	Server-seitiger Fehler; überprüfen Sie Ihre Request-Parameter

​

Siehe auch

• OpenAPI-Spezifikation
• Aggregator-Integrations-Leitfaden