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 →
Solanas Account-Modell ist das Wichtigste, das Sie verstehen müssen, bevor Sie Raydiums Code lesen. Anders als bei Ethereum, wo der Zustand zusammen mit dem Contract-Code gespeichert wird, sind Solana-Programme völlig zustandslos: Der gesamte Zustand lebt in separaten „Konten”, auf die Programme operieren. Jeder Raydium-Pool, jede Position und jedes Vault ist ein Konto — wenn Sie verstehen, wie diese Konten funktionieren, ergibt der Rest der Dokumentation Sinn.

​
Die fundamentale Aufteilung: Programme vs. Konten

​
Programme

Ein Programm auf Solana ist ausführbarer Code — eine kompilierte Binärdatei, die aus einer Datei geladen, auf einem Pubkey bereitgestellt und über Transaktionen aufgerufen wird. Programme haben keinen zugeordneten Zustand; sie enthalten nur Logik. Raydiums Programme:
  • CPMM: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
  • CLMM: CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK
  • AMM v4: 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
Jedes ist eine feste Binärdatei. Das Programm „erinnert” sich zwischen Aufrufen an nichts.

​
Konten

Ein Konto ist eine Datenzeile in der Blockchain. Jedes Konto hat:
  • pubkey — seine Adresse.
  • owner — das Programm, das es besitzt (steuert Schreibvorgänge).
  • data — die Rohdaten.
  • lamports — SOL-Guthaben (1 SOL = 1.000.000.000 Lamports).
  • rent_epoch — Legacy-Rent-Abrechnungsfeld (seit Rent-Exemption obligatorisch ist, ignoriert).
Wenn Sie einen Raydium-Pool abfragen, lesen Sie ein oder mehrere Konten. Wenn ein Swap ausgeführt wird, liest und schreibt das CPMM-Programm mehrere Konten — den Pool-Zustand, die Vaults, den Observation-Zustand und die Token-Konten des Nutzers.

​
Eigentümerschaft

Jedes Konto wird von genau einem Programm besessen. Nur der Code dieses Programms kann das data-Feld des Kontos ändern. Ein Benutzer kann lamports (SOL senden/empfangen) auf einem Konto ändern, das er signieren kann, aber um data zu ändern, muss das Besitzer-Programm dies in dessen Namen tun. Beispiele:
  • Ihre Benutzer-Wallet: besessen vom System-Programm. Lamports leben hier; Sie signieren, um zu übertragen.
  • Ihr USDC-Token-Konto: besessen vom SPL-Token-Programm. Die transfer-Anweisung des Token-Programms aktualisiert das Guthaben.
  • Ein Raydium-Pool-Zustandskonto: besessen vom CPMM-Programm. Nur CPMMs Anweisungen können die Reserven, Gebühren usw. ändern.
  • Der PersonalPositionState eines Raydium-Position-NFT: besessen vom CLMM-Programm.
„Besessen von” ist streng: Wenn Programm A in ein Konto schreibt, das von Programm B besessen wird, lehnt die Solana-Runtime die Transaktion ab.

​
Rent und Rent-Exemption

Das Erstellen eines Kontos verbraucht Speicherplatz. Solana berechnet Miete für diesen Speicher, aber seit 2020 müssen alle neuen Konten rent-exempt sein — das heißt, sie halten genug Lamports, dass die Miete, die sie über 2 Jahre schulden würden, im Voraus bezahlt ist. In der Praxis:
  • Ein rent-exemples Konto lebt für immer.
  • Das Schließen des Kontos gibt die Lamports an den Unterzeichner zurück.
Bei einem 165-Byte-Konto (z.B. SPL-Token-Konto) beträgt die Rent-Exemption etwa 0,00204 SOL. Bei einem 1.440-Byte-Raydium-CPMM-Pool-Zustand sind es etwa 0,011 SOL.

​
Raydium-Rent-Kosten

KontoGrößeRent
CPMM PoolState~1.440 B~0,011 SOL
CLMM PoolState~1.500 B~0,012 SOL
CLMM TickArray~9.000 B~0,063 SOL
CLMM PersonalPositionState~280 B~0,003 SOL
ATA165 B~0,002 SOL
Vault (Token-Konto)165 B~0,002 SOL
Die Pool-Erstellung erfordert Rent für mehrere Konten gleichzeitig — deshalb kostet die CPMM-Pool-Erstellung insgesamt etwa 0,15 SOL.

​
Daten- vs. ausführbare Konten

Konten gibt es in zwei Varianten:

​
Datenkonten

Speichern den Zustand (Pool-Reserven, Token-Guthaben, Nutzerpositionen). executable = false. Dies ist die überwiegende Mehrheit.

​
Ausführbare Konten

Speichern Programm-Bytecode. executable = true. Das sind Programme (CPMM, CLMM usw.). Programme haben über ihren Bytecode hinaus keine Daten.

​
Programmabgeleitete Konten (PDAs)

Ein PDA ist ein Datenkonto, dessen Adresse deterministisch von einem Programm und einigen Seeds abgeleitet wird — es existiert kein privater Schlüssel für diese Adresse. Nur das Ableitungsprogramm kann im Namen eines PDA über invoke_signed signieren. Raydium nutzt PDAs umfangreich:
  • Pool-Zustand-PDAs: abgeleitet von [poolTypeDiscriminator, mintA, mintB, ammConfig].
  • Vault-PDAs: abgeleitet von [pool, mint].
  • Observation-Zustand-PDA: abgeleitet von [observationSeed, pool].
PDAs ermöglichen es Raydium, Konten unter vorhersehbaren Adressen zu erstellen, ohne Schlüssel zu verwalten. Jeder kann die PDA-Adresse für einen bekannten Pool berechnen, gegeben die Seeds. Siehe solana-fundamentals/pdas-and-cpis.

​
Transaktionen und Kontobereferenzen

Jede Solana-Transaktion trägt eine explizite Liste von Konten, auf die sie lesen/schreiben wird. Die Runtime erzwingt:
  • Aufgelistete Konten können gelesen oder geschrieben werden (je nach ihrem is_writable-Flag).
  • Nicht aufgelistete Konten können nicht berührt werden.
Bei einem Raydium-Swap enthält die Kontoliste der Transaktion: 
[readonly] CPMM-Programm
[writable] Pool-Zustand
[readonly] AMM-Konfiguration
[readonly] Pool-Autorität (PDA)
[writable] Eingangs-Vault
[writable] Ausgangs-Vault
[writable] Benutzer-Eingangs-ATA
[writable] Benutzer-Ausgangs-ATA
[readonly] Eingangs-Mint
[readonly] Ausgangs-Mint
[readonly] Eingangs-Token-Programm
[readonly] Ausgangs-Token-Programm
[writable] Observation-Zustand
[signer,writable] Benutzer
Diese explizite Auflistung ist der Grund, warum Solana-Transaktionen schnell und parallelisierbar sind — die Runtime kann nicht-konfliktierende Txs im Voraus bestimmen.

​
Kontogröße und Datenlayout

Jedes Raydium-Konto hat eine feste oder begrenzte Größe. Das Layout wird im Code definiert (Rust-Structs mit #[repr(C)]) und ist dokumentiert in sdk-api/anchor-idl. Anchor-Programme stellen jedem Konto, das sie erstellen, einen 8-Byte-Diskriminator voran, abgeleitet von hash("account:<StructName>")[0..8]. Dies lässt Clients die Art eines Kontos bestimmen, indem sie nur die ersten 8 Bytes lesen — essentiell für getProgramAccounts-Scans, die alle Konten eines Typs aufzählen.

​
Einen Raydium-Pool-Zustand lesen

Über das SDK: 
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
Über Raw-RPC + Layout: 
const accountInfo = await connection.getAccountInfo(poolId);
const data = accountInfo.data;
// Erste 8 Bytes (Diskriminator) überspringen, dann nach Struct-Layout parsen.
const poolState = CpmmPoolStateLayout.decode(data.slice(8));
Das Layout befindet sich in src/raydium/cpmm/layout.ts in der SDK-Quelle.

​
Praktisches Beispiel: Lesen eines Token-Kontos

Lassen Sie uns das USDC-Guthaben eines Benutzers lesen. 
import { Connection, PublicKey } from "@solana/web3.js";
import { getAssociatedTokenAddressSync, AccountLayout } from "@solana/spl-token";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const user       = new PublicKey("YourUserWallet...");
const usdcMint   = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");

// 1. Berechne die ATA-Adresse (PDA-artige Ableitung).
const ata = getAssociatedTokenAddressSync(usdcMint, user);

// 2. Lese das Konto.
const accountInfo = await connection.getAccountInfo(ata);
if (!accountInfo) {
  console.log("ATA existiert noch nicht (Benutzer hat noch nie USDC gehalten).");
  return;
}

// 3. Verifiziere, dass der Besitzer das SPL-Token-Programm ist.
console.assert(accountInfo.owner.toBase58() === "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA");

// 4. Dekodiere die Daten.
const parsed = AccountLayout.decode(accountInfo.data);
console.log("Guthaben (kleinste Einheiten):", parsed.amount.toString());
console.log("Mint:",                         new PublicKey(parsed.mint).toBase58());
console.log("Besitzer:",                    new PublicKey(parsed.owner).toBase58());
Dieses Muster — Adresse ableiten, Konto abrufen, Besitzer verifizieren, dekodieren — gilt für jeden On-Chain-Lesevorgang, einschließlich Raydium-Pools.

​
Warum das für Raydium wichtig ist

Das Account-Modell prägt Raydiums Design:
  • Pool-Zustand ist ein einzelnes Konto — alles über einen Pool (Mints, Reserven, Gebühren, Admin) lebt in einem Konto, das vom Pool-Programm besessen wird.
  • LP-Token sind Standard-SPL-Token-Konten — Raydium delegiert Tokenisierung an das SPL-Token-Programm.
  • Tick-Arrays sind gechunked — CLMM kann kein einzelnes wachsales Array von Ticks haben, da Konten feste zugeordnete Größe haben; stattdessen verwendet es gechunkee TickArray-PDAs.
  • Positions-NFTs sind Metaplex-NFTs — CLMM-Positionen sind Standard-NFTs pro Metaplex; der Positions-Zustand ist ein separater PDA.
Das Verständnis dafür lässt Sie die Frage „Wo lebt X?” korrekt beantworten:
  • „Wo sind die Pool-Reserven?” → zwei Vault-Konten (Token-Konten), die vom SPL-Token-Programm besessen werden, mit Autorität delegiert an einen PDA des Pool-Programms.
  • „Wo sind die Tick-Daten für CLMM?” → eine Serie von TickArray-PDAs, jede mit 60 aufeinanderfolgenden Ticks.
  • „Wo ist mein Farm-Einsatz?” → ein UserLedger-PDA, abgeleitet von [user, farmId], besessen vom Farm-Programm.

​
Verweise

Quellen: