> ## 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.

# Account-Modell

> Solanas kontobasierte Architektur — Konten speichern den Zustand, Programme ist zustandsloser Code, der auf Konten operiert. Rent, Eigentümerschaft, Programmkonten vs. Datenkonten, und was das für das Lesen des Pool-Zustands von Raydium bedeutet.

<Info>
  **Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.**

  [Englische Version ansehen →](/solana-fundamentals/account-model)
</Info>

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

| Konto                      | Größe     | Rent        |
| -------------------------- | --------- | ----------- |
| 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 |
| ATA                        | 165 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`](/de/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`](/de/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:

```ts theme={null}
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
```

Über Raw-RPC + Layout:

```ts theme={null}
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.

```ts theme={null}
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

* [`solana-fundamentals/programs-and-anchor`](/de/solana-fundamentals/programs-and-anchor) — wie Programme Konten verarbeiten.
* [`solana-fundamentals/pdas-and-cpis`](/de/solana-fundamentals/pdas-and-cpis) — PDA-Ableitung und CPI.
* [`solana-fundamentals/transactions-and-fees`](/de/solana-fundamentals/transactions-and-fees) — wie Konten in Transaktionen referenziert werden.
* [`sdk-api/anchor-idl`](/de/sdk-api/anchor-idl) — Kontolayouts für Raydiums Programme.

Quellen:

* [Solana Account-Dokumentation](https://docs.solana.com/developing/programming-model/accounts).
* [SPL-Token-Programm](https://spl.solana.com/token) — wo Token-Konten leben.