Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Dies ist das einzige kanonische Architektur-Diagramm der Dokumentation. Jedes andere Kapitel verweist hierher, anstatt das System neu zu zeichnen. Programm-IDs sind nicht in diese Seite eingebettet — sie befinden sich in
reference/program-addresses, damit sie an genau einer Stelle aktualisiert werden können.Was Raydium wirklich ist
Raydium ist nicht ein Programm. Es ist eine Reihe unabhängiger On-Chain-Solana-Programme, die eine gemeinsame Off-Chain-Oberfläche (REST-API, TypeScript-SDK, IDL-Registry) und einige Konventionen (Authority-PDAs, Fee-Config-Konten, Admin-Multisig) teilen. Eine Benutzerinteraktion — ein Swap, eine Einzahlung, eine Farm-Ernte — wird in genau eines dieser Programme geleitet; die Off-Chain-Oberfläche macht sie wie ein einzelnes Produkt wirken. Der On-Chain-Fußabdruck gliedert sich in vier Arten von Programmen:- AMM-Programme — vier separate Pool-Programme, jedes mit eigenem Format und Pricing-Modell:
- AMM v4 — das ursprüngliche Constant-Product-AMM. Ursprünglich ein Hybrid-Design, das die Kurve auf einen OpenBook-Markt (ehemals Serum) spiegelte; die OpenBook-Integration wurde seitdem deaktiviert und Pools funktionieren nun als reine AMMs gegen die Kurve. Immer noch der tiefste Handelsplatz für viele große Paare.
- CPMM — ein einfaches Constant-Product-AMM (
x · y = k), nativ auf Solana gebaut, mit erstklassiger Token-2022-Unterstützung. Das empfohlene Programm für neue Constant-Product-Pools. - CLMM — ein konzentriertes Liquiditäts-AMM im Uniswap-v3-Stil. Liquidität wird in Preisbereiche bereitgestellt; Gebühren fallen pro Position an; der Zustand ist um Ticks und einen
sqrt_price_x64organisiert. - Stable AMM — ein dünnes Liquiditäts-StableSwap-ähnliches Programm (abgeleitet von AMM v4 mit einer Lookup-Table-Preiskurve), das der Router für stablecoin-korrelierte Paare verwendet. Wird heute in der UI nicht als erstklassige Create-Pool-Option angeboten.
- Reward-Verteilung — Farm (v3 / v5 / v6, mit v6 als aktive Generation; v3/v5 nur im Abbau).
- Token-Launch — LaunchLab, ein Bonding-Curve-Programm. Neu initialisierte Launches graduieren zu CPMM. Die Legacy-AMM-v4-Migrationsinstruktion bleibt für bestehenden Launch-Zustand erhalten.
- Liquiditäts-Primitive — AMM Routing (der On-Chain-Multi-Pool-Router, der CPIs in die vier AMM-Programme in einer einzigen Transaktion ausführt) und LP-Lock / Burn & Earn (sperrt LP-Positionen, während Gebührenansprüche offen bleiben).
Kanonisches Diagramm
Wichtige Invarianten, die dieses Diagramm erfasst:- AMM-Programme sind gleichberechtigt. CPMM ruft nicht in CLMM auf; CLMM ruft nicht in AMM v4 auf; Stable AMM ist sein eigenes Programm. Ein direkter Swap auf einem Pool berührt genau ein AMM-Programm. Das einzige Programm, das mehrere AMMs in einer einzigen Transaktion zusammensetzt, ist AMM Routing, das CPIs in AMM v4 / CPMM / CLMM / Stable AMM ausführt, wenn eine Route Pool-Typen kreuzt.
- Das SDK und die Transaction-API sind Kompositionsebenen, keine Programme. Wenn die Web-UI oder ein Aggregator eine „Swap durch drei Pools”-Transaktion erstellt, näht das SDK (Client-seitig) oder die Transaction-API (Server-seitig) die Anweisungen zusammen, indem Quotes von der REST-API abgerufen werden. Die Chain sieht eine einzelne Solana-Transaktion mit N Anweisungen — kein Orchestrator-Programm besitzt den gesamten Flow.
- AMM v4s OpenBook-Verdrahtung ist inert. AMM v4 war das einzige AMM, das jemals an OpenBook gebunden war, aber die Integration wurde deaktiviert — Pools teilen keine Liquidität mehr mit OpenBook,
MonitorStepwird nicht mehr ausgelöst, und ein OpenBook-Ausfall hat keine Auswirkungen auf den aktuellen Swap-Verkehr. Die Market-Konten bleiben auf demAmmInfodes Pools aus Gründen der Rückwärtskompatibilität, verweisen aber auf ungenutzten Zustand. CPMM, CLMM und Stable AMM hatten nie eine CLOB-Abhängigkeit. - Neue LaunchLab-Pools graduieren zu CPMM. Die Initialisierung erfordert nun
migrate_type = CPSWAP.MigrateToAmmbleibt für bestehenden Legacy-Zustand erhalten. Vor dem Upgrade vom 14.08.2026 sperrte die CPMM-Migrationcreator_scaleseparat für den Creator. Migrationen, die danach ausgeführt wurden, kombinieren es mitplatform_scalein eine einzelne plattformeigene gesperrte LP-Position. Frühere Fee Keys bleiben unverändert. - LP-Lock ist ein Wrapper, kein fünftes AMM. Es hält LP-Positionen im Namen von Creatorn unter einer PDA, damit die zugrunde liegenden Gebühren noch beansprucht werden können, ohne die Möglichkeit zum Abheben von Liquidität freizulegen. Es setzt sich über CPMM- und CLMM-Pools zusammen.
- Off-Chain-Oberflächen ergänzen sich gegenseitig. Die REST-API ist schreibgeschützt mit Caching; die Transaction-API erstellt Server-seitig signaturfertige Transaktionen; das SDK erstellt sie Client-seitig. Alle drei hängen von derselben IDL-Registry als Schemawahrheitsquelle ab.
Datenfluss: ein CPMM-Swap, von Ende zu Ende
Um das Bild konkret zu machen, hier ist, was passiert, wenn ein Benutzer USDC → RAY auf einem CPMM-Pool von der Raydium-UI aus tauscht. (AMM v4 und CLMM unterscheiden sich in den Konten, die sie benötigen, nicht in der übergeordneten Form.)- Quote-Anfrage (Off-Chain). Die UI ruft
GET https://api-v3.raydium.io/compute/swap-base-inmit dem Input-Mint, Output-Mint, Betrag und einer Slippage-Toleranz auf. Die API konsultiert ihren Indexer, wählt eine Route (möglicherweise durch mehrere Pools) und gibt ein Quote plus die Liste der Programm-IDs, Pool-IDs und Fee-Konten zurück, die der Client benötigt. - Transaktionserstellung (Client + SDK). Der Client übergibt das Quote an
raydium-sdk-v2. Das SDK löst jeden PDA auf, den es benötigt (Authority-PDA, Pool-Zustand, Observation, Vaults — sieheproducts/cpmm/accounts), injiziert die Associated-Token-Konten des Benutzers (erstellt sie mit dem Associated-Token-Programm, falls fehlend) und gibt eine unsignierteTransactionaus. - Wallet-Signatur. Die Wallet des Benutzers signiert die Transaktion. Nichts Raydium-Spezifisches hier; dies ist der Standard-Solana-Wallet-Flow.
- On-Chain-Ausführung. Die signierte Transaktion trifft das Raydium-CPMM-Programm, das (a) den Pool-Zustand validiert, (b) die Constant-Product-Kurve mit der Fee-Config des Pools anwendet, (c) Token zwischen den ATAs des Benutzers und den Pool-Vaults über CPI in SPL Token / Token-2022 verschiebt, (d) das
observation-Konto für den TWAP aktualisiert und (e) zurückkehrt. - Indexer-Aufnahme. Die Solana-RPC ein paar Slots später legt die Programm-Logs offen. Der Raydium-Indexer analysiert sie, aktualisiert die Reserves des Pools, das 24h-Volumen und die APR und bedient die aktualisierten Werte für die nächste
/pools/info/ids-Anfrage.
Gemeinsame Infrastruktur
Mehrere Primitive werden von jedem Produkt verwendet und sind es wert, einmal benannt zu werden, damit spätere Kapitel ohne Neudefinition darauf verweisen können. Details befinden sich inprotocol-overview/shared-infrastructure; dies ist der Index.
Off-Chain-Oberfläche: API vs. SDK vs. IDL
Diese drei werden routinemäßig verwechselt. Sie tun unterschiedliche Dinge:- REST-API (
api-v3.raydium.io) ist eine Read-mostly, gecachte Ansicht des On-Chain-Zustands plus die Quote-Engine. Sie sagt Ihnen, welche Pools existieren, wie ihre Reserves aussehen, wie APRs aussehen und welche beste Route für einen Swap ist. Sie erstellt nicht Transaktionen. - TypeScript-SDK (
@raydium-io/raydium-sdk-v2) ist ein Transaction-Builder. Es kennt das Account-Layout und das Instruction-Format jedes Programms. Es ruft frischen Zustand von einer RPC ab (nicht von der API), bevor es eine Instruction zusammensetzt, damit es genaue Transaktionen signieren kann. Es spricht mit der API nur, wenn es ein Quote benötigt. - IDL-Registry ist das Schema, auf das beide angewiesen sind. Wenn Sie Rust-CPIs in ein Raydium-Programm schreiben, ist die IDL der Vertrag; wenn Sie eine TS-Integration schreiben, verwenden Sie IDLs indirekt durch das SDK.
Wo jedes Kapitel passt
Das obige Diagramm tritt — in reduzierter Form — in der gesamten Dokumentation auf. Hier ist, wo die vollständige Behandlung jedes Teils lebt, damit Sie sich einarbeiten können:- On-Chain-Programme: ein Kapitel pro Produkt unter
products/. Jedes Kapitel folgt der gleichen Vorlage (Übersicht → Konten → Mathematik → Anweisungen → Gebühren → Code-Demos). - Gemeinsame programmübergreifende Primitive:
protocol-overview/shared-infrastructureundalgorithms/für die Mathematik, die sich wiederholt (Constant-Product, Concentrated-Liquidity, Curve-Pricing). - Off-Chain-Oberfläche:
sdk-api/hat die vollständige SDK- und REST-API-Referenz, plussdk-api/anchor-idlundsdk-api/rust-cpi. - Benutzer-Level-Flows (Pool erstellen, Swap, LP, Rewards beanspruchen, Token starten):
user-flows/. - Integrationsmuster für andere Teams (Aggregatoren, Wallets, Bots):
integration-guides/. - Sicherheitsoberfläche, Admin-Schlüssel, bekannte Risiken, Audits:
security/. - Versionierte Änderungen und die AMM-v4 → CPMM / Farm-v3 → v6-Migrationsstory:
protocol-overview/versions-and-migration.
Nicht-Ziele dieses Diagramms
Ein paar absichtliche Auslassungen, damit niemand mehr hineinliest, als dort ist:- Keine Preis-Orakel. Raydium hängt nicht von Pyth, Switchboard oder einem externen Oracle für sein Core-AMM-Pricing ab. Quotes stammen aus On-Chain-Reserves. Das
observation-Konto existiert, damit andere Verträge einen Raydium-TWAP lesen können — Raydium selbst benötigt es nicht. - Kein On-Chain-Token-Voting-Programm. Admin-Aktionen wie Fee-Config-Updates und Programm-Upgrades werden von einem Multisig ausgeführt. Die Multisig-Schlüssel und Rotationsrichtlinie befinden sich in
security/admin-and-multisig. - Keine Brücken. Raydium ist Solana-nativ. Cross-Chain-Flows sind das Problem des Integrators und liegen außerhalb dieses Diagramms.
reference/program-addressesfür die kanonischen Programm-IDs, auf die auf dieser Seite verwiesen wird- github.com/raydium-io/raydium-sdk-V2
- github.com/raydium-io/raydium-idl

