Zum Hauptinhalt springen

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

ProgrammAktuellDeprecatedNeue DeploymentsBestehende Instanzen
AMM v4v4 (eine Generation)NeinAbgeraten, aber akzeptiertVollständig betriebsfähig
CPMMv1Empfohlener StandardVollständig betriebsfähig
CLMMv1Empfohlen für Limited-Range-LPsVollständig betriebsfähig
Farmv6v3, v5Nur v6v3 + v5 im Auslauf (meist schreibgeschützt)
LaunchLabv1Empfohlen für neue LaunchesVollständig betriebsfähig
Die wichtigste Erkenntnis aus dieser Tabelle: AMM v4 ist nicht deprecated, und CPMM ist der neue Standard — aber sie existieren bewusst nebeneinander. AMM v4-Pools haben Jahre an Handelshistorie und werden nicht zu einer Zwangsmigration verpflichtet. Die Wahl des Programms für einen neuen Pool ist eine Empfehlung, keine zwingende Vorgabe.

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.
(OpenBook-integriertes Routing ist kein Grund mehr, AMM v4 zu wählen — diese Integration ist abgeschaltet.) 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 v4 → CPMM-Migration

CPMM (constant-product market maker, interner Name raydium-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 unter 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 Fee-Tier, das Sie beibehalten möchten.
  2. 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.
  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 anreizgesteigerte LPs zum neuen Pool zu ziehen.
  5. Beobachten Sie, wie das Volumen zu dem tieferen Pool migriert, während Aggregatoren das Gewicht neu ausgleichen.
Die Chain selbst erzwingt davon nichts — Raydiums API und Frontend bevorzugen einfach den Pool, der tiefer ist, und Aggregatoren routen durch denjenigen, der für den Benutzer am kostengünstigsten ist.

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-Swap ist weiterhin aufrufbar; neue Integrationen sollten auf SwapV2 abzielen.
  • 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.
Das IDL lebt im dedizierten 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

VersionVeröffentlichtStatusHauptfunktionen
v32021Auslauf. Bestehende Farms laufen; keine neuen Farms akzeptiert.Einzelner Reward-Stream. Slot-basierte Emission.
v5Okt 2022Auslauf. Bestehende Farms laufen; keine neuen Farms akzeptiert.Bis zu 2 Reward-Streams. Slot-basierte Emission. Ganzzahl per_second.
v62024Aktuell. 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 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 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) und UserLedger (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:
  1. Warten Sie, bis die Emissionen der bestehenden Farm enden (oder reduzieren Sie sie).
  2. Staker heben sich ab und beanspruchen ausstehende Rewards auf der alten Farm.
  3. Der Farm-Betreiber erstellt eine neue v6-Farm gegen denselben Staking-Mint.
  4. Staker re-staken in die neue Farm.
Die On-Chain-Realität sind zwei unabhängige Farm-Accounts. Ein Benutzer mit Stake in beiden hat zwei 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_time einer 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.
Detaillierte Informationen pro Version finden sich unter 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 LaunchConfig aus einem kleinen Satz von Kurvenformen.
Bestehende LaunchLab-Launches werden von Upgrades nicht beeinflusst — sobald ein Launch initialisiert ist, sind seine Parameter bis zur Graduierung eingefroren.

Programm-übergreifende Versionskompatibilität

Einige Kompabilität-Anmerkungen zwischen Produkten, auf die Integratoren regelmäßig stoßen:
  • CLMM SwapV2 ist nicht dasselbe wie Swap. Falls Ihr Client nur Swap spricht, werden Token-2022-Transfer-Fees stille fehlerhaft behandelt — die Mathematik liegt um den Gebührenbetrag daneben. 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 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

Quellen:
  • 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.