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 →
Jede Solana-Transaktion setzt zwei Parameter: ein Compute Unit Limit (maximale CUs, die die Transaktion verbrauchen darf; standardmäßig 200.000 × Anzahl der Instructions bis zu einer Obergrenze pro Transaktion) und eine Priority Fee in Mikro-Lamports pro CU. Unzureichende Werte für beide Parameter führen zum Scheitern — zu niedrige CU-Limits verursachen
ProgramFailedToComplete; zu niedrige Priority Fees führen dazu, dass die Transaktion bis zum Ablauf unbestätigt bleibt.Die zwei Einstellungen
setComputeUnitLimit(units)— beschränkt die Berechnung; die Transaktion bezahlt für höchstensunitsCUs.setComputeUnitPrice(microLamports)— Priority-Fee-Gebot in Mikro-Lamports pro CU. Gesamte Priority Fee =units × microLamports × 1e-6Lamports.
250_000 × 50_000 / 1e6 = 12.500 Lamports ≈ 0,0000125 SOL ≈ 0,003 USD bei 200 USD SOL. Priority Fees in dieser Größenordnung sind für die meisten Benutzer-Swaps unbedeutend, aber erheblich für Bots, die täglich 1000 Transaktionen durchführen.
CU-Benchmarks pro Instruction
Benchmarks aus Mainnet-Ausführungsprotokollen, gemittelt über neuere Durchläufe. Die Zahlen sind ungefähr (±15%); nehmen Sie für Ihre spezifischen Abläufe eine Neubewertung vor.| Instruction | SPL Token | Token-2022 (einfach) | Token-2022 (Transfer Fee) |
|---|---|---|---|
| CPMM initialize_pool | 180.000 | 200.000 | — |
| CPMM swap_base_input | 140.000 | 180.000 | 200.000 |
| CPMM swap_base_output | 150.000 | 185.000 | 205.000 |
| CPMM deposit | 130.000 | 160.000 | 180.000 |
| CPMM withdraw | 120.000 | 150.000 | 170.000 |
| CLMM create_pool | 70.000 | 85.000 | — |
| CLMM open_position_v2 | 120.000 | 140.000 | 160.000 |
| CLMM increase_liquidity_v2 | 150.000 | 175.000 | 195.000 |
| CLMM decrease_liquidity_v2 | 140.000 | 165.000 | 185.000 |
| CLMM swap_v2 (0 Tick-Überquerungen) | 170.000 | 205.000 | 225.000 |
| CLMM swap_v2 (1 Tick-Überquerung) | 220.000 | 255.000 | 275.000 |
| CLMM swap_v2 (3 Tick-Überquerungen) | 320.000 | 355.000 | 375.000 |
| CLMM collect_fee | 80.000 | 95.000 | 105.000 |
| AMM v4 swap_base_in | 140.000 | — | — |
| AMM v4 deposit | 120.000 | — | — |
| AMM v4 withdraw | 110.000 | — | — |
| Farm v6 create_farm | 70.000 | 85.000 | — |
| Farm v6 deposit (1 Reward Slot) | 130.000 | 155.000 | 175.000 |
| Farm v6 deposit (3 Reward Slots) | 220.000 | 255.000 | 275.000 |
| Farm v6 withdraw | entspricht deposit | ||
| Farm v6 harvest | entspricht deposit | ||
| Farm v3/v5 deposit | 100.000 | — | — |
| LaunchLab initialize | 100.000 | — | — |
| LaunchLab buy_exact_in | 140.000 | — | — |
| LaunchLab graduate | 250.000 | — | — |
Zusammengesetzte Transaktionen
Summieren Sie die einzelnen Budgets und addieren Sie:- +1.500 CU pro CPI-Frame — der feste Overhead der Runtime für jeden Cross-Program-Aufruf.
- +20.000 CU pro ATA-Erstellung —
create_associated_token_accountist nicht kostenlos. - +5.000 CU für
setComputeUnitLimit/setComputeUnitPricejeweils.
units × microLamports, daher kostet ~25% über-Budget 25% zusätzliche Priority Fee).
Priority-Fee-Schätzung
Solanas lokaler Gebührenmarkt bedeutet, dass Priority Fees pro beschreibbarem Account berechnet werden. Eine Transaktion, die in einen heißen Account (beliebter Pool-Status) schreibt, zahlt mehr als eine Transaktion, die in einen kalten Account schreibt. Das globale Gebührenniveau ist nicht die richtige Metrik für Raydium-Swaps; Sie wollen Gebühren auf die spezifischen Pools, die Sie berühren.Strategie 1: RPC-Provider-Schätzer
Jeder große RPC-Provider veröffentlicht einen Priority-Fee-Schätzer, der aktuelle Gebühren auf spezifischen Accounts abfragt:Min / Low / Medium / High / VeryHigh / UnsafeMax. Ordnen Sie sie den Perzentilen zu:
| Ebene | Perzentil | Anwendungsfall |
|---|---|---|
| Min | 25. | Hintergrund, nicht dringende Bot-Transaktionen |
| Low | 50. | Normale Benutzer-Swaps |
| Medium | 60. | Standard für Wallet-UIs |
| High | 75. | Zeitempfindliche Arbitrage |
| VeryHigh | 95. | Liquidationen, Notfall-Exits |
getPriorityFeeEstimate), Triton (getRecentPrioritizationFees mit Account-Liste), QuickNode (ähnlich).
Strategie 2: Direkte RPC-Abfrage
Verwenden Sie die Standard-getRecentPrioritizationFees RPC:
Strategie 3: Historische Selbstoptimierung
Für Bots mit ständigem Durchsatz verfolgen Sie Ihre eigenen Landungs- gegenüber Ablauf-Raten:Umgang mit CU-Erschöpfungsfehlern
Symptom: Transaktion schlägt fehl mitexceeded maximum number of instructions allowed (200000) oder ProgramFailedToComplete.
Diagnose:
- Erhöhen Sie das CU-Limit. Wenn Ihre Transaktion 195k von einem 200k-Budget verwendete, erhöhen Sie auf 300k.
- Teilen Sie die Transaktion. Wenn Sie die 1,4M-Obergrenze pro Transaktion erreichen, brechen Sie in zwei Transaktionen auf. Farm
harvest then stakeist eine klassische Transaktion zum Aufteilen, wenn Rewards zahlreich sind. - Trimmen Sie Accounts. Jeder zusätzliche beschreibbare Account addiert ~2.000 CU. Das Prunen ungenutzter Accounts hilft bei Grenzfällen.
- Verwenden Sie Lookup-Tabellen. LUT-Lookups sind ~50 CU pro aufgelöstem Address, sparen 5.000 CU einer vollständigen Account-Referenz pro Eintrag.
Umgang mit steckengebliebenen Transaktionen
Symptom: Transaktion eingereicht, bestätigt sich nie, läuft schließlich ab mitBlockhashNotFound.
Diagnose:
getSignatureStatuses([sig])gibtnullzurück → Leader hat es nie gesehen.- Gibt
{ confirmationStatus: null }zurück → Leader sah es, aber nahm es nicht auf.
- Erhöhen Sie die Priority Fee. Reichen Sie mit der 2-fachen aktuellen Gebühr erneut ein.
- Bauen Sie mit neuem Blockhash auf. Blockhash-Lebensdauer liegt bei ~60 Sekunden; danach ist die Transaktion ungültig, unabhängig von Gebühren.
- Multi-RPC-Broadcast. Einige RPCs haben bessere Leader-Verbindungen als andere. Reichen Sie parallel zu 3–5 ein.
- Wechseln Sie zu Jito Bundles. Siehe
integration-guides/routing-and-mev. Bundles umgehen öffentliche Paket-Warteschlangen.
Bei Netzwerküberlastung
Wenn das Netzwerk überlastet ist (Jupiter / Jito Bundle Dashboards zeigen Rückstau, RPC-Latenz spitzt zu, Transaktionsablauf-Raten klettern), passen Sie an:| Parameter | Normale Bedingungen | Überlastete Bedingungen |
|---|---|---|
| CU-Limit | +25% über Schätzung | +25% über Schätzung (unverändert) |
| Priority-Fee-Perzentil | 50. | 75.–95. |
| Retry-Anzahl | 3 | 5–7 |
| Retry-Backoff | 500ms | 1000ms |
| Jito Bundles verwenden | Optional | Stark empfohlen |
| Blockhash-Refresh bei Retry | Ja | Ja, obligatorisch |
- Priority-Fee 75. Perzentil > 500k Mikro-Lamports: Überlastung.
- Jito 50. Perzentil Tip > 0,001 SOL: Überlastung.
- RPC-Antwort p99 > 2s: RPC-spezifisches Problem oder Überlastung.
Gebührenbudgetierung für Bots
Ein Trading-Bot, der täglich ~1000 Transaktionen durchführt, benötigt ein Priority-Fee-Budget. Schätzung:Fallstricke
1. CU-Limit vergessen
Der Standard ist 200k CUs × (Instructions in Transaktion). Ein Single-Instruction-Swap standardisiert auf 200k; das ist für CPMM auf SPL Token ausreichend, aber nicht für CLMM mit Tick-Überquerungen oder alles Token-2022. Setzen Sie es immer explizit.2. Priority Fee auf dem falschen Account
Wenn Sie die Priority Fee gegen die Token-Mint schätzen, aber der heiße Account der Pool-Status ist, ist Ihre Schätzung zu niedrig. Der Pool-Status ist der richtige beschreibbare Account zum Ziel für Raydium.3. Gebühren skalieren mit CU-Limit
total_priority_fee = units × microLamports. Die Erhöhung von units von 200k auf 1M bei 50k Mikro-Lamports/CU multipliziert Priority Fee um das 5-fache. Über-budgetieren Sie nicht einfach für den Fall; messen Sie.
4. Standard-Transaktionsversion
Legacy-Transaktionen haben niedrigere Account-Limits; V0-Transaktionen mit Address-Lookup-Tabellen ermöglichen größere Routen. Das SDK verwendet standardmäßig V0 intxVersion: TxVersion.V0. Wechseln Sie nicht zu Legacy, es sei denn, Sie benötigen Wallet-Kompatibilität.
5. skipPreflight verbirgt CU-Fehler
skipPreflight: true sendet die Transaktion ohne lokale Simulation. Sie sparen ~100ms, verlieren aber das frühe Feedback zur CU-Erschöpfung. Verwenden Sie es nur bei Retries, nicht beim ersten Versuch.
Verweise
integration-guides/routing-and-mev— Jito-Bundle-Strategien.integration-guides/aggregator— Transaktionsassembly.integration-guides/cpi-integration— CU-Stapelung über zusammengesetzte CPIs.- Solana Compute Budget Program Docs
- Solana
getRecentPrioritizationFeesRPC - Helius Priority Fee API
- Benchmarks: Mainnet-Ausführungsprotokolle (Raydium SDK Integration Tests, April 2026).


