Versionen und Migration

Release-Versionshistorie für jedes Raydium-Programm, der Deprecation-Status jeder Generation und praktische Migrationspfade zwischen ihnen.

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 ihrer dritten oder vierten Generation. Diese Seite bietet einen Überblick aus Betreiber-Perspektive: Welche Programmversion sollte ich verwenden, welcher Status gilt für die älteren Versionen, und wie migriere ich von Version A zu B, wenn ich heute noch die ältere Version nutze?

​

Status auf einen Blick

Programm	Aktuell	Veraltet	Neue Deployments	Bestehende Instanzen
AMM v4	v4 (eine Generation)	Nein	Nicht empfohlen, aber akzeptiert	Vollständig funktionsfähig
CPMM	v1	—	Empfohlener Standard	Vollständig funktionsfähig
CLMM	v1	—	Empfohlen für Ranged LPs	Vollständig funktionsfähig
Farm	v6	v3, v5	Nur v6	v3 + v5 im Auslaufen (größtenteils schreibgeschützt)
LaunchLab	v1	—	Empfohlen für neue Launches	Vollständig funktionsfähig

Die wichtigste Erkenntnis aus dieser Tabelle: AMM v4 ist nicht veraltet, und CPMM ist der neue Standard — aber beide existieren bewusst nebeneinander. AMM v4-Pools haben Jahre an Handelshistorie und werden nicht zwangsweise migriert. Die Wahl, auf welchem Programm ein neuer Pool gestartet wird, ist eine Empfehlung, keine Einschränkung.

​

AMM v4 — Status und Entwicklung

AMM v4 ist das ursprüngliche Raydium-Pool-Design: Constant-Product-Preisbildung (x · y = k). Es wurde als Hybrid-AMM mit einer OpenBook-Integration (ehemals Serum) gestartet, die Teile der Kurve als Limit-Orders auf einem gebundenen Markt spiegelte. Die OpenBook-Integration wurde inzwischen deaktiviert — Pools teilen keine Liquidität mehr mit OpenBook und alle Swaps werden rein gegen die Kurve über die V2-Swap-Entrypoints ausgeführt. AMM v4 ist heute praktisch ein reiner Constant-Product-AMM, wobei die OpenBook-Konten als inerte Zustände erhalten bleiben.

​

Was eingefroren ist

• Keine neuen Gebührentiers. Die AMM v4-Gebührenstruktur ist pro Pool und wurde bei der Bereitstellung festgelegt. Neue Pools akzeptieren die gleiche hardcodierte ~0,25% Handelsgebühr, ~12% für das Protokoll.
• Keine neuen Features. Das Team hat seit CPMM zum neuen Standard wurde keine neuen Instruktionen zu AMM v4 hinzugefügt. Das Programm befindet sich im Verwaltungsmodus — nur Bugfixes, keine Scope-Erweiterung.
• Keine Token-2022-Unterstützung. AMM v4 wurde vor Token-2022 geschrieben und die Integration wurde nie nachträglich implementiert. Token-2022-Mints müssen CPMM (oder CLMM, falls angemessen) verwenden.
• OpenBook-Integration deaktiviert. Jeder AMM v4-Pool ist immer noch an ein entsprechendes OpenBook-Market-Konto on-chain gebunden, aber der Pool postet oder verwaltet keine Orders mehr auf diesem Markt. Ein OpenBook-Ausfall beeinträchtigt AMM v4-Swaps nicht mehr.

​

Was noch funktioniert

• Bestehende Pools handeln normal. Keine Zustandsmigration wurde erzwungen; v4-Pools aus 2021 sind immer noch der aktive Handelsplatz für viele hochvolumige Paare im Jahr 2026.
• LPs können wie gewohnt einzahlen, abheben und Farm-Rewards ernten. Die Migration zu CPMM ist optional.
• Aggregatoren routen immer noch durch sie. Jupiter und die Raydium Trade API indexieren v4-Pools als erstklassige Handelsplätze.

​

Wann AMM v4 noch verwendet werden sollte

Ehrlich gesagt: selten. Die Fälle, in denen v4 die bessere Antwort ist, sind eng begrenzt:

• Das Paar hat bereits einen tiefen, gut gehandelten v4-Pool und Sie möchten Liquidität zur bestehenden Tiefe hinzufügen, anstatt einen Markt zu spalten.

(OpenBook-integriertes Routing ist kein Grund mehr, AMM v4 zu wählen — diese Integration ist aus.)

In jedem anderen Fall starten Sie neue Pools auf CPMM. Siehe user-flows/choosing-a-pool-type für den vollständigen Entscheidungsbaum.

​

CPMM — Adoptionskurve und die v4 → CPMM-Migration

CPMM (Constant-Product Market Maker, interner Name raydium-cp-swap) wurde 2024 als saubere Neuentwicklung bereitgestellt und sollte der neue Standard für Constant-Product-Pools sein. Es ist strukturell das einfachste von Raydiums Programmen: reines x · y = k, kein Orderbook, native Token-2022-Unterstützung, kleinerer Transaction-Footprint.

​

Was CPMM gegenüber AMM v4 bietet

• Bessere LP-Ökonomie standardmäßig. CPMMs Standard-AmmConfig leitet 100% der Handelsgebühren an LPs weiter (mit umschaltbarer Protokollgebühr pro Tier). AMM v4 hardcodiert ~12% für das Protokoll.
• Niedrigere Pool-Erstellungskosten. Kein OpenBook-Markt erforderlich. 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 Einschränkungen), vertrauliche Transfers — alle auf CPMM unterstützt, keine auf v4.
• Saubere Integrator-Oberfläche. CPMM hat eine Anchor-CPI-freundliche veröffentlichte Crate (raydium-cp-swap), eine einfachere Kontenliste und ein stabiles IDL. AMM v4 liefert ein IDL, hatte aber nie eine gepflegte Rust-CPI-Crate.
• Kleinere Kontenliste pro Swap. ~10 Konten vs ~17 für v4 (das die OpenBook-Market-Konten trägt, auch wenn es sie nicht nutzt).

​

Wann Migration lohnenswert ist

Für einen aktiv gehandelten Pool rechtfertigt die LP-Gebührenverbesserung allein die Migration normalerweise 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 LPs zurück. Über ein Jahr verteilt sich das bedeutsam.

Für einen Pool mit niedrigem Volumen geht es bei der Migration mehr um Zukunftssicherung — bessere Standards, Token-2022-Unterstützung, falls Sie sie jemals brauchen, 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 ist in user-flows/migrate-amm-v4-to-cpmm; die übergeordnete Form:

1. Erstellen Sie einen neuen CPMM-Pool für das gleiche Paar, auf dem gleichen Gebührentier, das Sie beibehalten möchten.
2. Koordinieren Sie LPs: Kündigen Sie ein Fenster an, in dem der alte Pool geleert und der neue Pool gefüllt wird.
3. Jeder LP hebt sich aus dem v4-Pool ab und zahlt in den neuen CPMM-Pool ein.
4. (Optional) Richten Sie eine CPMM-seitige Farm ein, um incentivierte LPs zum neuen Pool zu locken.
5. Beobachten Sie, wie das Volumen migriert, während Aggregatoren sich zum tieferen Pool umgewichten.

Die Chain selbst erzwingt nichts davon — Raydiums API und Frontend bevorzugen einfach den tieferen Pool, und Aggregatoren routen durch den für den Benutzer günstigsten.

​

CLMM — ein Programm, stabil über Versionen

CLMM befindet sich in seiner ersten Programmversion. Es gab keine 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-Migrationsstory: bestehende Positionen bleiben dort, wo sie sind, und das Programmverhalten kann sich subtil ändern, wenn ein Upgrade ausgeliefert wird, aber die Account-Layouts und PDAs sind stabil.

Was sich über CLMM-Upgrades hinweg geändert hat:

• SwapV2-Instruktion hinzugefügt, um Token-2022-Transfer-Fee-Mathematik korrekt zu unterstützen. Alte Swap ist immer noch aufrufbar; neue Integrationen sollten SwapV2 anvisieren.
• Reward-Stream-Erweiterungen — der RewardInfo-Slot-Count wurde erhöht (die ursprünglichen 3 → immer noch 3 derzeit, aber das Reservierungsmuster wurde verschärft). Keine Datenmigration erforderlich.
• Tick-Array-Komprimierung — interne Optimierung zur Reduzierung von CU beim Swap-Crossing-Many-Ticks. Extern unsichtbar.
• Anchor 1.0-Rebuild (2026-09-30): Wechsel von Anchor 0.32.1 zu 1.0.2 und Hinzufügen des Admin CollectExcessLamports. Keine benutzerorientierten Instruktions- oder Account-Layout-Änderungen. Siehe den Changelog-Eintrag.
• CreateCustomizablePoolV2 (2026-10-22): CreatePermissionedPool wird umbenannt und erlaubnisfrei gemacht; das Permission-Konto und CreatePermissionPda / ClosePermissionPda werden entfernt. Pool-Ersteller, die die alte Instruktion aufrufen, müssen gegen das neue IDL neu erstellen. Keine Account-Layout-Änderung. Siehe den Changelog-Eintrag.

Das IDL befindet sich im dedizierten raydium-idl-Repository (siehe sdk-api/anchor-idl). Wenn Sie ein älteres SDK gegen das aktuelle Programm ausführen, ist der schlimmste Fall das Fehlen der neuen Instruktionen.

​

Farm v3 → v5 → v6

Von allen Raydium-Programmen hat Farm die expliziteste Versionshistorie und den einzigen erzwungenen Migrationspfad. Die drei Generationen sind separate Programme mit separaten Programm-IDs und separaten State-Layouts.

​

Generationen

Version	Veröffentlicht	Status	Hauptmerkmale
v3	2021	Im Auslaufen. Bestehende Farms laufen; keine neuen Farms akzeptiert.	Einzelner Reward-Stream. Slot-basierte Emission.
v5	Okt 2022	Im Auslaufen. Bestehende Farms laufen; keine neuen Farms akzeptiert.	Bis zu 2 Reward-Streams. Slot-basierte Emission. Integer per_second.
v6	2024	Aktuell. Alle neuen Farms.	Bis zu 5 Reward-Streams. Wall-Clock-Emission. Q64.64 Fixed-Point per_second. Token-2022-Staking + Reward-Unterstützung.

​

Warum es drei Generationen gibt

• v3 → v5: benötigte mehrere gleichzeitige Reward-Streams (z. B. Dual-Incentive-Farms). Das Single-Stream-Design von v3 konnte dies ohne Redesign nicht unterstützen.
• v5 → v6: v5s u64-Integer-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 Programme mit niedriger Emission. v6s Q64.64-Bruchrate behebt dies. v6 hob auch das Slot-basierte Update auf Wall-Clock an und fügte Token-2022-Unterstützung hinzu.

​

Was über Generationen hinweg gleich bleibt

• Das „LP einzahlen, Pro-Share-Counter auflaufen lassen, bei Abhebung beanspruchen”-Buchhaltungsmuster ist über v3/v5/v6 identisch. Die Mathematik ändert sich nicht; nur die Präzision des Rate-Counters und die Anzahl der unterstützten Streams.
• UserStake (v3/v5) und UserLedger (v6) sind konzeptionell der gleiche Datensatz, 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:

1. Warten Sie, bis die Emissionen der bestehenden Farm enden (oder fahren Sie sie herunter).
2. Staker heben sich ab und beanspruchen ausstehende Rewards auf der alten Farm.
3. Der Farm-Betreiber erstellt eine neue v6-Farm gegen den gleichen Staking-Mint.
4. Staker re-staken in die neue Farm.

Die On-Chain-Realität sind zwei unabhängige Farm-Konten. Ein Benutzer mit Stake in beiden hat zwei UserLedger (v6) / UserStake (v5)-Datensätze.

​

Was „Im Auslaufen” für v3 und v5 bedeutet

• Die v3- und v5-Programme sind immer noch bereitgestellt und aufrufbar. Bestehende Farms können immer noch ausstehende Rewards verteilen und Abhebungen akzeptieren.
• Die Raydium-UI zeigt immer noch v3- und v5-Farms mit aktiven Rewards an; sobald die end_time einer v3/v5-Farm verstrichen ist, versteckt die UI sie von „aktiv”, hält sie aber beanspruchbar.
• Das Team wird keine neuen v3/v5-Farms erstellen. SDK-Helfer für „Farm erstellen” routen nur zu v6.
• v3 und v5 erhalten Sicherheits-Upgrades, aber keine Feature-Arbeit. Wenn ein kritischer Bug gefunden wird, wird er behoben; wenn ein Feature nützlich sein könnte, wird es stattdessen zu v6 hinzugefügt.

Vollständige Details pro Version sind in products/farm-staking/accounts und products/farm-staking/instructions.

​

LaunchLab — ein Programm, evolvierende Konfiguration

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 Post-Graduation-CPMM-Handelsgebühren an den ursprünglichen Creator leiten können. Siehe products/launchlab/creator-fees.
• Kurvenformel-Konfigurierbarkeit. Ursprünglich hardcodiert quadratisch; jetzt wählt die LaunchConfig aus einem kleinen Satz von Kurvenformen.

Bestehende LaunchLab-Launches werden durch Upgrades nicht beeinträchtigt — sobald ein Launch initialisiert ist, sind seine Parameter bis zur Graduation eingefroren.

​

Programmübergreifende Versionskompatibilität

Einige produktübergreifende Kompatibilitätshinweise, auf die Integratoren regelmäßig stoßen:

• CLMM SwapV2 ist nicht dasselbe wie die Swap-Instruktion. Wenn Ihr Client nur Swap unterstützt, werden Token-2022-Transfergebühren stillschweigend falsch behandelt — die Mathematik ist um den Gebührenbetrag falsch. Aktualisieren Sie auf SwapV2.
• Farm v6 Staking mit CLMM-Positionen wird nicht auf die gleiche Weise unterstützt wie LP-Token-Staking. CLMM-Positionen sind NFTs, keine fungiblen LP-Token. CLMM hat stattdessen einen eigenen nativen Belohnungsmechanismus — siehe products/clmm/fees.
• CPMM-Pools mit Token-2022-Mints 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. Wenn Sie einen sehen, ist er gefälscht — AMM v4 unterstützt diese Kombination nicht.

​

Weitere Informationen

• introduction/history-and-milestones — die chronologische Veröffentlichungs-Timeline und warum jede Version zu ihrer Zeit eingeführt wurde.
• 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-Bereitstellungen.
• products/farm-staking/accounts — nebeneinander angeordnetes Schema für v3 / v5 / v6.
• reference/changelog — was sich in dieser Dokumentation mit der Entwicklung der Programmversionen geändert hat.

Quellen:

• Produktspezifische Kapitelseiten, die oben inline zitiert werden.
• Raydium SDK v2 — versionsbewusste Dispatch-Logik bestätigt, zu welchem Programm ein bestimmter Pool gehört.
• reference/program-addresses — kanonische IDs pro Version.