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.
Eine Solana-Transaktion ist eine Liste von Instruktionen, die atomar ausgeführt werden. Das Verständnis der Transaktionsstruktur — Instruktionen, Konten, Unterzeichner, Compute Budget — ist eine Voraussetzung für das Erstellen, Debuggen oder Optimieren von etwas mit Raydium. Diese Seite behandelt diese Struktur, die Limits, die sie einschränken, und wie sich die beiden Gebührenkategorien (Solana-Netzwerkgebühren, Raydium-Protokollgebühren) bei einem echten Swap addieren.
Transaktionsaufbau
Eine Solana-Transaktion hat drei Kernkomponenten:
- Message: die geordnete Liste der Instruktionen, die Konten, auf die sie verweisen, und den kürzlichen Blockhash.
- Signatures: eine pro Unterzeichner, bestätigen, dass die Transaktion autorisiert wurde.
- Recent blockhash: beweist, dass die Transaktion aktuell ist; Transaktionen mit veralteten Blockhashes (>150 Slots alt) werden abgelehnt.
Instruktionen
Eine Instruktion legt fest:
program_id — das aufzurufende Programm.accounts — die Konten (und deren writable/signer-Flags) die das Programm berühren darf.data — undurchsichtige Bytes, die das Programm interpretiert.
Eine einzelne Transaktion kann mehrere Instruktionen enthalten. Sie werden in Reihenfolge ausgeführt; wenn eine fehlschlägt, werden alle vorherigen Instruktionen zurückgerollt (atomar).
Eine typische Raydium-Swap-Transaktion umfasst:
ComputeBudget::SetComputeUnitLimit — erhöht das Standard-CU-Limit.ComputeBudget::SetComputeUnitPrice — setzt eine Prioritätsgebühr.- Optional
CreateAssociatedTokenAccount — erstellt das Ausgabe-ATA, falls der Benutzer noch keine hat.
Raydium::SwapBaseInput — führt den Swap aus.- Optional
CloseAccount — schließt ein wrapped-SOL-ATA.
Das SDK packt diese automatisch über raydium.trade.swap().
Konten in Transaktionen
Jedes Konto, das durch eine Instruktion in der Transaktion berührt wird, muss in der Kontoliste der Transaktion aufgeführt sein. Jedes Konto wird gekennzeichnet:
- Signer / non-signer: muss der Inhaber des Kontos die Transaktion unterzeichnen?
- Writable / read-only: kann die Transaktion das Konto ändern?
Die Runtime erzwingt diese Flags: Ein Programm, das versucht, in ein nicht beschreibbares Konto zu schreiben, schlägt fehl, und die Runtime lehnt Transaktionen ab, denen erforderliche Unterzeichner fehlen.
Bei einem CPMM-Swap hat die Kontoliste etwa 13 Einträge (siehe solana-fundamentals/account-model). CLMM-Swaps mit mehreren Tick-Array-Übergängen können 20+ haben.
Transaktionsgrößenlimit
Solana begrenzt Transaktionen auf 1232 Bytes einschließlich Signaturen, Message und Headers. Dies ist das häufigste Hindernis für komplexe Transaktionen — Raydiums CLMM mit Multi-Hop-Routing stoßen regelmäßig an diese Grenze.
Aufschlüsselung eines typischen ~1000-Byte-Raydium-Swaps:
| Komponente | Größe |
|---|
| Signature | 64 B |
| Signature count | 1 B |
| Message header | 3 B |
| Blockhash | 32 B |
| Account keys (13 × 32 B) | 416 B |
| Instructions (4 × ~100-150 B) | 400–600 B |
| Gesamt | ~900–1100 B |
Address Lookup Tables (ALTs)
ALTs ermöglichen es einer Transaktion, auf Konten über einen 1-Byte-Index in einer veröffentlichten Tabelle zu verweisen, anstatt einen vollständigen 32-Byte-Pubkey zu verwenden. Dies komprimiert eine Transaktion erheblich:
- Eine Transaktion, die auf 20 Konten direkt verweist: ~640 B Pubkeys.
- Dieselbe Transaktion mit ALTs: ~20 B Indizes + ALT-Referenzen.
Raydium verwaltet ALTs für CPMM/CLMM-Swap-Pfade im Mainnet. Das SDK nutzt sie automatisch. Aggregatoren, die Multi-Hop-Routen erstellen, verlassen sich stark darauf.
import { VersionedTransaction } from "@solana/web3.js";
// SDK builds a v0 (versioned) tx with ALT references
const { transaction } = await raydium.trade.swap({ /* ... */ });
// transaction is a VersionedTransaction, not a legacy Transaction.
Compute Budget
Jede Transaktion hat ein Compute Unit (CU) Budget. Die Überschreitung beendet die Ausführung und verursacht den Fehlschlag der Transaktion.
- Standard: 200.000 CU pro Transaktion.
- Maximum: 1.400.000 CU pro Transaktion (erhöht über
ComputeBudget::SetComputeUnitLimit).
- Pro-Block-Obergrenze: 48M CU pro Block (auf Protokollebene).
Typischer Raydium-CU-Verbrauch (siehe integration-guides/priority-fee-tuning für die vollständige Tabelle):
| Instruktion | CU |
|---|
| CPMM swap | ~140.000 |
| CLMM swap (keine Tick-Übergänge) | ~170.000 |
| CLMM swap (4 Tick-Übergänge) | ~320.000 |
| Farm v6 stake | ~130.000 |
| CPMM pool creation | ~250.000 |
ComputeBudget; sonst erhalten Sie den 200k-Standard, was für die meisten Raydium-Instruktionen zu niedrig ist.
import { ComputeBudgetProgram } from "@solana/web3.js";
tx.add(
ComputeBudgetProgram.setComputeUnitLimit({ units: 300_000 }),
);
Prioritätsgebühren
Über die Basisgebühr (5000 Lamports pro Signature) hinaus priorisieren Validatoren zunehmend Transaktionen, die Prioritätsgebühren zahlen: ein Pro-CU-Trinkgeld in Microlamports.
priority_fee = compute_unit_price (micro-lamports) × compute_unit_limit
tx.add(
ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 10_000 }),
);
integration-guides/priority-fee-tuning für die Anpassung dieser dynamisch.
Limits für Instruktions- und Kontoanzahl
Über das 1232-Byte-Gesamtlimit hinaus:
- Max Konten pro Transaktion: 128.
- Max Konten pro Instruktion (CPI): 64.
- Max Instruktionen pro Transaktion: kein hartes Limit, nur durch das Größenlimit beschränkt.
- Max CPI-Tiefe: 4 (ein Programm kann ein anderes aufrufen, das wiederum ein anderes aufrufen kann, 4 Ebenen tief).
Raydium-CLMM-Swaps, die mehrere Tick-Arrays überqueren, können hart gegen das Kontolimit stoßen — ein einzelner Swap berührt den Pool, Ein-/Ausgabetresore, Ein-/Ausgabe-ATAs, mehrere Tick-Arrays, möglicherweise zusätzliche Konten eines Transfer-Hook-Programms, plus die obligatorischen Compute-Budget-/System-/Token-Programm-Referenzen. Entwürfe, die Raydium über CPI komponieren (z. B. Auto-Compounder), müssen dies berücksichtigen.
Gebührenkategorien bei einem Raydium-Swap
Eine Benutzer-Swap-Transaktion zahlt Gebühren in zwei Kategorien:
Solana-Netzwerkgebühren
Bezahlt an Validatoren in SOL.
- Basisgebühr pro Signature: 5000 Lamports pro Signature. Fast immer 1 Signature = 0,000005 SOL.
- Prioritätsgebühr: CU-Preis × CU-Limit in Microlamports. Variiert mit Stau; siehe
integration-guides/priority-fee-tuning.
Diese Gebühren gehen an Validatoren, sind nicht mit Raydium verbunden und werden auch für fehlgeschlagene Transaktionen erhoben (außer in einigen Prioritätsgebühr-Grenzfällen).
Raydium-Protokollgebühren
Werden vom Swap-Betrag abgezogen.
- Swap-Gebühr: Prozentsatz der Eingabe (CPMM typischerweise 0,25%, CLMM 0,01%–1% pro Stufe). Aufgeteilt zwischen LPs und Protokoll-Zielen. Siehe
ray/protocol-fees.
Diese Gebühren sind intern in Raydiums Bilanzierung — der Benutzer sieht sie als einen kleineren Ausgabebetrag als ein gebührenfreier Pool produzieren würde.
Beispiel: $1000 USDC → SOL über CPMM 0,25%-Stufe
| Gebührenkategorie | Betrag | Geht zu |
|---|
| Basisgebühr pro Signature | 0,000005 SOL (~$0,0007) | Validator |
| Prioritätsgebühr (10k µL × 300k CU) | 0,003 SOL (~$0,45) | Validator |
| CPMM swap fee (0,25%) | $2,50 | LPs + Protokoll |
| Gesamtkosten für Benutzer | ~$2,95 | |
Versionierte Transaktionen
Solana hat zwei Transaktionsformate:
- Legacy: das ursprüngliche Format, kein ALT-Support.
- v0 (Versioned): unterstützt ALTs, erweiterbar für zukünftige Versionen.
Alle modernen Solana-Tools verwenden v0. Das Raydium SDK sendet standardmäßig v0-Transaktionen.
// Building a v0 tx directly
import { VersionedTransaction, TransactionMessage } from "@solana/web3.js";
const msg = new TransactionMessage({
payerKey: owner.publicKey,
recentBlockhash: blockhash,
instructions: [ /* ... */ ],
}).compileToV0Message([lookupTableAccount]);
const tx = new VersionedTransaction(msg);
tx.sign([owner]);
Blockhash-Aktualität
Eine Transaktion muss einen Blockhash aus den letzten ~150 Slots (~60 Sekunden) enthalten. Über dieses Fenster hinaus lehnen Validatoren es ab.
Für Wiederholungsschleifen rufen Sie einen frischen Blockhash bei jedem Versuch ab:
async function sendWithRetry(tx, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
const { blockhash, lastValidBlockHeight } = await connection.getLatestBlockhash();
tx.message.recentBlockhash = blockhash;
tx.sign([owner]);
try {
return await connection.sendRawTransaction(tx.serialize());
} catch (e) {
if (i === maxRetries - 1) throw e;
}
}
}
integration-guides/priority-fee-tuning für das vollständige Muster Wiederholung-mit-eskalierenden-Gebühren.
Parallele Ausführung
Solana führt nicht konfligierende Transaktionen parallel auf Multi-Core-Validatoren aus. Zwei Transaktionen sind in Konflikt, wenn beide dasselbe Konto schreiben.
Auswirkungen auf Raydium:
- Zwei Swaps auf dem gleichen Pool können nicht parallel ausgeführt werden — beide schreiben in den Pool-Status.
- Ein Swap auf Pool A und ein Swap auf Pool B führen parallel aus, wenn sich Kontolisten nicht überlappen.
- Eine schreibgeschützte Transaktion blockiert nie einen Writer auf dem gleichen Konto (schreibgeschützt ist konzurrent mit sich selbst, aber nicht mit Writes).
Deshalb kann Solana hohen DEX-Durchsatz aufrechterhalten, trotz Single-Pool-Serialisierung.
Transaktionsbestätigungsstufen
Beim Einreichen einer Transaktion wählen Sie eine Bestätigungsstufe:
| Stufe | Wartezeit | Finalität |
|---|
processed | ~400 ms | Nicht finalisiert; kann zurückgerollt werden |
confirmed | ~1 s | Supermajorität hat abgestimmt |
finalized | ~13 s | Supermajorität ist verwurzelt |
confirmed Standard. Bei Operationen mit großem Wert (Pool-Erstellung, Reward-Top-ups) ist finalized sicherer.
await connection.sendAndConfirmTransaction(tx, [owner], {
commitment: "confirmed",
});
Simulation
Solana unterstützt das Simulieren einer Transaktion vor der Einreichung:
const sim = await connection.simulateTransaction(tx);
console.log(sim.value.logs);
console.log(sim.value.unitsConsumed);
getBestSwapInfo, um zu überprüfen, dass die gewählte Route tatsächlich erfolgreich ist. Simulation ist nicht kostenlos — sie verbraucht RPC-Kapazität — aber sie fängt Fehler ab, bevor Sie dafür bezahlen.
Verweise
Quellen:
