Versionen und Migration

​

Status auf einen Blick

Die wichtigste Erkenntnis aus dieser Tabelle: AMM v4 ist nicht veraltet, und CPMM ist der neue Standard — aber sie koexistieren bewusst. AMM v4-Pools haben Jahre an Handelshistorie und werden nicht erzwungenermaßen 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 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 mit erhaltenen, inaktiven OpenBook-Konten.

​

Was eingefroren ist

• Keine neuen Fee-Tiers. 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 Wartungsmodus — nur Bugfixes, keine Scope-Erweiterung.
• Keine Token-2022-Unterstützung. AMM v4 wurde vor Token-2022 geschrieben und die Integration wurde nie nachgerüstet. Token-2022-Mints müssen CPMM (oder CLMM, wo 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. 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 soll der neue Standard-Constant-Product-Pool 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. 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 Kontoliste und eine stabile IDL. AMM v4 liefert eine IDL, hatte aber nie eine gepflegte Rust-CPI-Crate.
• Kleinere Kontoliste 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 je 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 High-Level-Form:

1. Erstellen Sie einen neuen CPMM-Pool für das gleiche Paar, auf dem gleichen Fee-Tier, 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 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 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 aktuell, 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): wechselt von Anchor 0.32.1 zu 1.0.2 und fügt den Admin CollectExcessLamports hinzu. Keine benutzergerichtete Instruktion oder Account-Layout geändert. Siehe den Changelog-Eintrag.

Die IDL lebt 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, dass Sie die neuen Instruktionen vermissen.

​

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

​

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 das 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 Low-Emission-Programme. 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, beim Abheben beanspruchen”-Accounting-Muster ist identisch über v3/v5/v6. 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 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:

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-Operator 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)-Records.

​

Was „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; sobald die end_time einer v3/v5-Farm verstrichen ist, versteckt die UI sie von „aktiv”, aber hält sie 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 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 Post-Graduation-CPMM-Handelsgebühren zum ursprünglichen Creator routen können. Siehe products/launchlab/creator-fees.
• Curve-Formel-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.

​

Cross-Program-Versionskompatibilität

Ein paar Cross-Product-Kompatibilitätsnotizen, auf die Integratoren routinemäßig stoßen:

• CLMM SwapV2 ist nicht die gleiche Instruktion wie Swap. Wenn Ihr Client nur Swap spricht, wird er Token-2022-Transfer-Fees stillschweigend falsch handhaben — die Mathematik ist um den Fee-Betrag falsch. Aktualisieren Sie auf SwapV2.
• 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 seinen eigenen nativen Reward-Mechanismus — siehe products/clmm/fees.
• CPMM-Pools, die von Token-2022-Mints unterstützt werden, funktionieren in Farms nur auf Farm v6. v3 und v5 lehnen Token-2022-Staking-Mints ab.
• AMM v4-Pools haben nie Token-2022-LP-Mints. Wenn Sie eine sehen, ist es eine Fälschung — AMM v4 unterstützt diese Kombination nicht.

​

Wo Sie mehr lesen können

• introduction/history-and-milestones — die chronologische Release-Timeline und warum jede Version landete, wenn sie es tat.
• user-flows/migrate-amm-v4-to-cpmm — das Operator-Runbook für den v4 → CPMM-Umzug.
• user-flows/choosing-a-pool-type — Entscheidungsbaum für neue Pool-Deployments.
• products/farm-staking/accounts — nebeneinander Schema für v3 / v5 / v6.
• reference/changelog — was sich in dieser Dokumentation geändert hat, während sich Programmversionen entwickelt haben.

Quellen:

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