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 →
Raydium existiert seit fünf Jahren. Mehrere seiner Programme befinden sich bereits in der dritten oder vierten Generation. Diese Seite bietet einen Überblick aus Betreiber-Perspektive: „Welche Programmversion verwende ich, wie ist der Status der älteren Versionen, und wie wechsle ich von A nach B, wenn ich derzeit auf der älteren Version laufe?”
Status auf einen Blick
| Programm | Aktuell | Deprecated | Neue Deployments | Bestehende Instanzen |
|---|---|---|---|---|
| AMM v4 | v4 (eine Generation) | Nein | Abgeraten, aber akzeptiert | Vollständig betriebsfähig |
| CPMM | v1 | — | Empfohlener Standard | Vollständig betriebsfähig |
| CLMM | v1 | — | Empfohlen für Limited-Range-LPs | Vollständig betriebsfähig |
| Farm | v6 | v3, v5 | Nur v6 | v3 + v5 im Auslauf (meist schreibgeschützt) |
| LaunchLab | v1 | — | Empfohlen für neue Launches | Vollständig betriebsfähig |
AMM v4 — Status und Verlauf
AMM v4 ist das ursprüngliche Raydium-Pool-Design: konstantes Produktpreismodell (x · y = k). Es wurde als Hybrid-AMM mit OpenBook (ehemals Serum) Orderbuch-Integration gestartet, die Teile der Kurve als Limitorders auf einem gebundenen Markt spiegelte. Die OpenBook-Integration wurde inzwischen deaktiviert — Pools geben keine Liquidität mehr an OpenBook weiter und alle Swaps laufen rein über die Kurve durch die V2-Swap-Entrypoints. AMM v4 ist heute praktisch ein reiner Constant-Product-AMM mit OpenBook-Accounts, die als inerte Zustände erhalten bleiben.
Was eingefroren ist
- Keine neuen Fee-Tiers. Die AMM v4-Gebührenstruktur ist pro Pool und wurde beim Deployment festgelegt. Neue Pools verwenden die gleiche hardcodierte ~0,25%-Handelsgebühr, ~12% für das Protokoll.
- Keine neue Feature-Entwicklung. Das Team hat AMM v4 seit CPMMs Wechsel zum neuen Standard keine neuen Instruktionen hinzugefügt. Das Programm ist im Wartungsmodus — nur Bugfixes, keine Erweiterung des Umfangs.
- Keine Token-2022-Unterstützung. AMM v4 wurde vor Token-2022 geschrieben und die Integration wurde nie nachträglich hinzugefügt. Token-2022-Mints müssen CPMM (oder, falls angemessen, CLMM) verwenden.
- OpenBook-Integration deaktiviert. Jeder AMM v4-Pool ist zwar noch an ein entsprechendes OpenBook-Market-Account on-chain gebunden, aber der Pool verwaltet keine Orders mehr auf diesem Markt. Ein OpenBook-Ausfall beeinträchtigt AMM v4-Swaps nicht mehr.
Was noch funktioniert
- Bestehende Pools werden normal gehandelt. Es wurde keine erzwungene State-Migration durchgeführt; v4-Pools aus dem Jahr 2021 sind immer noch der aktive Handelsplatz für viele hochvolumige Paare im Jahr 2026.
- LPs können Einzahlungen, Abhebungen und Farm-Rewards wie gewohnt einfordern. Die Migration zu CPMM ist optional.
- Aggregatoren routen weiterhin durch AMM v4. Jupiter und die Raydium Trade API indexieren v4-Pools als gleichberechtigte Handelsplätze.
Wann Sie AMM v4 noch verwenden sollten
Ehrlich gesagt: selten. Die Fälle, in denen v4 die bessere Wahl ist, sind eng begrenzt:- Das Paar hat bereits einen tiefgehendes, gut gehandeltes v4-Pool und Sie möchten Liquidität zur bestehenden Tiefe hinzufügen, anstatt einen Markt zu splitten.
user-flows/choosing-a-pool-type für den vollständigen Entscheidungsbaum.
CPMM — Adoptionskurve und v4 → CPMM-Migration
CPMM (constant-product market maker, interner Nameraydium-cp-swap) wurde 2024 als Clean-Room-Neuentwicklung mit der Absicht deployed, der neue Standard-Constant-Product-Pool zu sein. Es ist strukturell das einfachste der Raydium-Programme: reines x · y = k, kein Orderbuch, native Token-2022-Unterstützung, kleinerer Transaktions-Footprint.
Was CPMM Ihnen gegenüber AMM v4 bietet
- Bessere LP-Ökonomie standardmäßig. CPMMs Standard-AmmConfig leitet 100% der Handelsgebühren an LPs weiter (die Protokollgebühr ist je Tier umschaltbar). AMM v4 hardcodet ~12% für das Protokoll.
- Geringere Pool-Erstellungskosten. Kein OpenBook-Market nötig. Die Erstellung ist eine Transaktion, ~0,15 SOL Miete vs. ~0,6 SOL für v4.
- Token-2022. Transfer-Fee-Mints, Transfer-Hook-Mints (mit Vorbehalten), vertrauliche Transfers — alle werden auf CPMM unterstützt, keine auf v4.
- Sauberer Integrator-Interface. CPMM hat eine Anchor-CPI-freundliche veröffentlichte Crate (
raydium-cp-swap), eine einfachere Account-Liste und ein stabiles IDL. AMM v4 liefert ein IDL, hatte aber niemals eine verwaltete Rust-CPI-Crate. - Kleinere Account-Liste pro Swap. ~10 Accounts vs. ~17 für v4 (das die OpenBook-Market-Accounts mit sich trägt, auch wenn es sie nicht nutzt).
Wann Migration sinnvoll ist
Bei einem aktiv gehandelten Pool rechtfertigt der LP-Gebührenaufstieg allein meist die Migration innerhalb weniger Monate. Die Rechnung: Ein Pool mit 0,25% × $X täglichem Volumen gibt 0,03% an das Protokoll auf v4 ab (die fehlenden 12%). Auf CPMM kehrt das zu den LPs zurück. Über ein Jahr gerechnet summiert sich das bedeutsam. Für einen Pool mit niedrigem Volumen geht es bei der Migration eher um zukunftssichere Defaults — bessere Vorgaben, Token-2022-Unterstützung falls nötig, einfachere Integrationen.Wie Migration funktioniert
Es gibt kein In-Place-Upgrade. Migration ist eine neuen-Pool-erstellen, alten-Pool-leeren, neuen-Pool-auffüllen-Sequenz. Die vollständige Schritt-für-Schritt-Anleitung findet sich unteruser-flows/migrate-amm-v4-to-cpmm; die High-Level-Form:
- Erstellen Sie einen neuen CPMM-Pool für das gleiche Paar auf dem Fee-Tier, das Sie beibehalten möchten.
- Koordinieren Sie LPs: kündigen Sie ein Zeitfenster an, in dem der alte Pool geleert und der neue Pool mit Liquidität gefüllt wird.
- Jeder LP hebt sich aus dem v4-Pool ab und zahlt in den neuen CPMM-Pool ein.
- (Optional) Richten Sie eine CPMM-seitige Farm ein, um anreizgesteigerte LPs zum neuen Pool zu ziehen.
- Beobachten Sie, wie das Volumen zu dem tieferen Pool migriert, während Aggregatoren das Gewicht neu ausgleichen.
CLMM — ein Programm, stabil über Versionen hinweg
CLMM befindet sich in seiner ersten Programmversion. Es gab nie ein v2 — Verbesserungen wurden als In-Place-Upgrades zur gleichen Programm-ID ausgeliefert (hinter dem 24h-Timelock-Multisig), nicht als neue Generation. Das bedeutet, es gibt keine CLMM-Migrations-Geschichte: bestehende Positionen bleiben dort, wo sie sind, und das Verhalten des Programms kann sich subtil ändern, wenn ein Upgrade ausgeliefert wird, aber die Account-Layouts und PDAs sind stabil. Was sich über CLMM-Upgrades hinweg verändert hat:SwapV2-Instruktion hinzugefügt, um Token-2022-Transfer-Fee-Math korrekt zu unterstützen. Alt-Swapist weiterhin aufrufbar; neue Integrationen sollten aufSwapV2abzielen.- Reward-Stream-Erweiterungen — die
RewardInfo-Slot-Anzahl wurde erhöht (ursprünglich 3 → immer noch 3 aktuell, aber das Reservierungsmuster wurde verschärft). Keine Datenmigration nötig. - Tick-Array-Verdichtung — interne Optimierung zur Reduzierung von CU beim Swap-Durchqueren vieler Ticks. Extern unsichtbar.
raydium-idl-Repository (siehe sdk-api/anchor-idl). Falls Sie ein älteres SDK gegen das aktuelle Programm einsetzen, ist das schlimmste Szenario, dass Sie die neuen Instruktionen vermissen.
Farm v3 → v5 → v6
Von allen Raydium-Programmen hat Farm die expliziteste Versionsverlauf und den einzigen erzwungenen Migrationspfad. Die drei Generationen sind separate Programme mit separaten Programm-IDs und separaten State-Layouts.Generationen
| Version | Veröffentlicht | Status | Hauptfunktionen |
|---|---|---|---|
| v3 | 2021 | Auslauf. Bestehende Farms laufen; keine neuen Farms akzeptiert. | Einzelner Reward-Stream. Slot-basierte Emission. |
| v5 | Okt 2022 | Auslauf. Bestehende Farms laufen; keine neuen Farms akzeptiert. | Bis zu 2 Reward-Streams. Slot-basierte Emission. Ganzzahl per_second. |
| v6 | 2024 | Aktuell. Alle neuen Farms. | Bis zu 5 Reward-Streams. Echtzeitbasierte Emission. Q64.64 Fixed-Point per_second. Token-2022 Staking + Reward-Unterstützung. |
Warum drei Generationen existieren
- v3 → v5: benötigte mehrere gleichzeitige Reward-Streams (z.B. Dual-Incentive-Farms). v3s Single-Stream-Design konnte das ohne Neudesign nicht unterstützen.
- v5 → v6: v5s
u64Integer-Emissionsrate begrenzt die minimal ausdrückbare Rate auf „1 Token-Einheit pro Sekunde”. Für einen 9-Dezimal-Mint sind das 1 Lamport/Sek — viel zu grob für Low-Emission-Programme. v6s Q64.64 Bruch-Rate behebt das. v6 hob auch die Slot-basierte Aktualisierung auf Echtzeitbasierung an und addierte Token-2022-Unterstützung.
Was über Generationen hinweg gleich bleibt
- Das Muster „LP einzahlen, Pro-Share-Zähler aufbauen, bei Abhebung beanspruchen” ist über v3/v5/v6 identisch. Die Mathematik ändert sich nicht; nur die Präzision des Rate-Zählers und die Anzahl der unterstützten Streams.
UserStake(v3/v5) undUserLedger(v6) sind konzeptuell derselbe Record, mit unterschiedlichen Layouts. Das SDK normalisiert beide.
Migrationspfad
Es gibt kein In-Place-Upgrade zwischen Farm-Versionen. Um von v3/v5 zu v6 zu wechseln:- Warten Sie, bis die Emissionen der bestehenden Farm enden (oder reduzieren Sie sie).
- Staker heben sich ab und beanspruchen ausstehende Rewards auf der alten Farm.
- Der Farm-Betreiber erstellt eine neue v6-Farm gegen denselben Staking-Mint.
- Staker re-staken in die neue Farm.
UserLedger (v6) / UserStake (v5) Records.
Was „Auslauf” für v3 und v5 bedeutet
- Die v3- und v5-Programme sind weiterhin deployed und aufrufbar. Bestehende Farms können weiterhin ausstehende Rewards verteilen und Abhebungen akzeptieren.
- Die Raydium-UI präsentiert v3- und v5-Farms mit aktiven Rewards immer noch; sobald die
end_timeeiner v3/v5-Farm verstrichen ist, versteckt die UI sie aus „aktiv”, hält sie aber beanspruchbar. - Das Team wird keine neuen v3/v5-Farms erstellen. SDK-Helper für „Farm erstellen” routen nur zu v6.
- v3 und v5 erhalten Security-Upgrades aber keine Feature-Entwicklung. Falls ein kritischer Bug gefunden wird, wird er behoben; falls ein Feature nützlich sein könnte, wird es stattdessen v6 hinzugefügt.
products/farm-staking/accounts und products/farm-staking/instructions.
LaunchLab — ein Programm, evolvierende Config
LaunchLab befindet sich in seiner ersten Programmversion. Wie CLMM werden Verbesserungen als In-Place-Upgrades hinter dem 24h-Timelock ausgeliefert — nicht als neue Generationen. Was sich durch Upgrades entwickelt hat:- Creator-Fee-Slot. Hinzugefügt, damit Launches einen Teil der CPMM-Handelsgebühren nach Graduierung an den ursprünglichen Creator leiten können. Siehe
products/launchlab/creator-fees. - Kurvenformeln-Konfigurierbarkeit. Ursprünglich hardcodiert quadratisch; nun wählt
LaunchConfigaus einem kleinen Satz von Kurvenformen.
Programm-übergreifende Versionskompatibilität
Einige Kompabilität-Anmerkungen zwischen Produkten, auf die Integratoren regelmäßig stoßen:- CLMM
SwapV2ist nicht dasselbe wieSwap. Falls Ihr Client nurSwapspricht, werden Token-2022-Transfer-Fees stille fehlerhaft behandelt — die Mathematik liegt um den Gebührenbetrag daneben. Aktualisieren Sie aufSwapV2. - Farm v6 Staking mit CLMM-Positionen wird nicht so unterstützt wie LP-Token-Staking. CLMM-Positionen sind NFTs, keine fungiblen LP-Tokens. CLMM hat stattdessen einen eigenen nativen Reward-Mechanismus — siehe
products/clmm/fees. - CPMM-Pools, die durch Token-2022-Mints gestützt sind, funktionieren in Farms nur auf Farm v6. v3 und v5 lehnen Token-2022-Staking-Mints ab.
- AMM v4-Pools haben niemals Token-2022-LP-Mints. Falls Sie einen sehen, ist er gefälscht — AMM v4 unterstützt diese Kombination nicht.
Wo Sie mehr erfahren
introduction/history-and-milestones— der chronologische Veröffentlichungs-Timeline und warum jede Version wann landete.user-flows/migrate-amm-v4-to-cpmm— das Betreiber-Handbuch für den v4 → CPMM-Wechsel.user-flows/choosing-a-pool-type— Entscheidungsbaum für neue Pool-Deployments.products/farm-staking/accounts— Side-by-Side-Schema für v3 / v5 / v6.reference/changelog— was sich in dieser Dokumentation verändert hat, als die Programmversionen sich entwickelten.
- Pro-Produkt-Kapitelseiten, die oben zitiert wurden.
- Raydium SDK v2 — versionsabhängige Dispatch-Logik bestätigt, welchem Programm ein gegebener Pool angehört.
reference/program-addresses— kanonische IDs pro Version.


