Gemeinsame Infrastruktur

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.

​

Was „gemeinsam” hier bedeutet

• Convention Sharing. Jedes Programm verwendet das gleiche PDA-Ableitungsmuster, die gleiche Gebührenaufteilungsform und die gleiche Observation-Account-Idee — aber jedes implementiert sie in seinem eigenen Programm mit seinen eigenen Seeds.
• Account Sharing. Eine Handvoll Konten sind buchstäblich derselbe Datensatz über viele Pools hinweg (die globale Authority-PDA in CPMM, die AmmConfig-Konten).
• Off-Chain Sharing. Eine REST-API und ein TypeScript SDK fronten alle vier Programme. Integratoren interagieren mit einem HTTP-Host und einem NPM-Paket, unabhängig davon, welches Programm sie am Ende aufrufen.

​

1. Authority-PDAs

• Für CPMM und CLMM ist die Authority-PDA ein globales Konto — jeder Pool dieses Typs verwendet es. Wenn Sie mit CPI in CPMM gehen, benötigen Sie es einmal, nicht pro Pool.
• Für Pro-Pool- / Pro-Farm-Authorities leiten Sie die PDA von der Pool-/Farm-ID ab. Das SDK macht dies in getPoolKeys / getFarmKeys; wenn Sie direkt integrieren, leiten Sie mit findProgramAddressSync ab.
• Vault-Besitz kann nicht geändert werden. Sobald ein Token-Konto mit der Authority-PDA als Besitzer erstellt wird, kann nur diese PDA — aufgerufen vom Programm — es übertragen. Es gibt keine Administrator-Überschreibung.

​

2. Admin- und Config-Konten

// CPMM AmmConfig (gekürzt — die CLMM-Version ist strukturell ähnlich)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // neue Pool-Erstellung in dieser Stufe sperren
    pub index: u16,                       // Stufenindex
    pub trade_fee_rate: u64,              // Bruchteil des Handels, der zu Gebühren geht
    pub protocol_fee_rate: u64,           // Bruchteil der Handelsgebühr für Protokoll
    pub fund_fee_rate: u64,               // Bruchteil der Handelsgebühr für Fonds
    pub create_pool_fee: u64,             // einmalige Pro-Pool-Erstellungsgebühr
    pub protocol_owner: Pubkey,           // Unterzeichner für CollectProtocolFee
    pub fund_owner: Pubkey,               // Unterzeichner für CollectFundFee
    pub padding: [u64; 16],
}

• Gebührenniveaus sind global. Wenn ein Pool sagt „dies ist ein 0,25%-Pool”, bedeutet das, dass er an die AmmConfig gebunden ist, deren trade_fee_rate bei der Erstellung 0,25% betrug. Es gibt keine Pro-Pool-Rate-Überschreibung.
• Eine Config kann geändert werden, aber Pools folgen nicht. Wenn die Config-Authority eine AmmConfig bearbeitet, nehmen alle bestehenden Pools, die an diese Config gebunden sind, die neue Rate sofort auf. Dies ist eine Funktion, kein Fehler; so propagieren wirtschaftliche Änderungen auf Protokollebene ohne Pro-Pool-Migrationen.
• disable_create_pool ist der Deprecation-Hebel. Wenn eine Gebührenstufe eingestellt wird, setzt das Protokoll-Multisig dieses Flag — vorhandene Pools funktionieren weiter, aber es können keine neuen Pools die Stufe wählen.
• protocol_owner / fund_owner sind die Unterzeichner für Gebührensammlungsaufrufe. Sie auf ein Multisig zu setzen ist, was die Gebührenentnahme sperrt. Sie sind NICHT die Zieladressen für die Gebühren selbst; das sind protocol_fee_destination / fund_fee_destination auf demselben Konto.

​

3. Die Aufteilung von Protokoll- / Fonds- / Creator-Gebühren

                         Gesamte Swap-Gebühr
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP-Pool-Seite    Protokoll         Fonds          Creator
        (erhöht k)       Schatz         Multisig      (LaunchLab-Pools)

1. Handelsgebühr sammelt sich im Pool an. Die Gebühr wird von der Eingabeseite des Swap entfernt und der post-fee Betrag ist das, was die Constant-Product-Mathematik sieht. Das ist, was „die LP verdient die Gebühr” bedeutet — k steigt und damit auch der implizierte Pro-LP-Token-Wert.
2. Protokoll-/Fonds-/Creator-Anteile werden von dieser LP-seitigen Ansammlung in Pro-Pool-Counter-Konten abgezogen. Sie sitzen auf dem Pool-State (protocol_fees_token{0,1}, fund_fees_token{0,1}, etc.), bis jemand CollectProtocolFee / CollectFundFee / CollectCreatorFee aufruft. Sie verlassen die Vaults des Pools erst dann; aus einer Swap-Perspektive sind sie noch „im Pool”.
3. Sammlung bewegt sie raus. Der jeweilige Unterzeichner (die protocol_owner / fund_owner-Schlüssel auf AmmConfig, oder der Launch-Creator für LaunchLab-Pools) ruft die Collect-Anweisung auf und das Programm überträgt aus dem Pool-Vault zu einer Ziel-ATA.

• Die Split-Prozentsätze sind von der Handelsgebühr, nicht vom Handel. Eine 0,25%-Handelsgebühr mit einer 12%-Protokoll-Anteil bedeutet, das Protokoll erhält 0,25% × 12% = 0,03% des Handels — nicht 12% des Handels.
• Creator-Gebühren existieren nur auf LaunchLab-graduierten Pools. Standard-CPMM/CLMM-Pools haben eine 3-Wege-Aufteilung (LP / Protokoll / Fonds). LaunchLab fügt einen vierten Slot hinzu, der an den weitergeleitet wird, der den Token gestartet hat, konfiguriert bei Initialize und unveränderlich.
• AMM v4 teilt sich nur auf zwei Arten auf, hardcodiert pro Pool: LP und Protokoll. Kein Fonds-Slot, kein Creator-Slot.
• Fonds vs. Protokoll — beide sind Protokoll-Treasury-Ziele, aber sie haben unterschiedliche Unterzeichner und unterschiedliche beabsichtigte Verwendungen. protocol finanziert historisch Operationen; fund ist das längerfristige Treasury. Die Aufteilung zwischen den beiden ist selbst eine tunable.

​

4. Observation-Konten (TWAP-Ringpuffer)

// CPMM ObservationState (gekürzt)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // nächster Slot zum Überschreiben
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // Summe von (Preis × dt) seit init
    pub cumulative_token_1_price_x32: u128,
}

• Jeder Swap ruft update_observation auf. Das Programm liest den aktuellen Preis, multipliziert ihn mit den verstrichenen Sekunden seit der vorherigen Observation und addiert ihn zum Kumulatorzähler. Der neue Eintrag überschreibt den ältesten Slot (Ringpuffer-Stil).
• TWAP über ein Fenster = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Verbraucher wählen zwei Observations aus, die das gewünschte Fenster einrahmen, und dividieren.
• Raydium selbst verwendet den TWAP nicht für Preisbestimmung. Die AMM-Mathematik liest die Spot-Reserves direkt. Observations sind eine Externalität — Raydium zahlt die Kosten für das Schreiben, damit andere Verträge lesen können.
• AMM v4 hat kein Observation-Konto. Es ist älter als das ObservationState-Design; Integratoren, die einen v4-TWAP möchten, müssen einen Off-Chain aus der Log-Historie berechnen.

​

5. REST-API + SDK + IDL

• REST-API — https://api-v3.raydium.io. Eine hauptsächlich lesbare Indexierte Ansicht des gesamten On-Chain-State plus eine Quote-Engine. Ein Host, ein Schema.
• TypeScript SDK — @raydium-io/raydium-sdk-v2 auf NPM. Erstellt und signiert Transaktionen für jedes Programm. Spricht mit der API für Quotes/Metadaten, spricht mit einem Solana RPC für Pre-Sign-State-Refreshs.
• IDL-Registrierung — Anchor IDLs für jedes veröffentlichte Programm befinden sich im raydium-idl Repo (eine JSON pro Programm: CPMM, CLMM, LaunchLab). Das TypeScript SDK konsumiert diese IDLs intern; Downstream-Rust- / Python-Clients regenerieren aus denselben Dateien.

​

6. Indexer und Price Feeds

• Der Indexer ist das einzige, das „über Cross-Programm-State weiß”. Eine CPMM-Pool zu ihrem CLMM-Gegenstück zuordnen, eine 24h-Volume-Zahl über Programmversionen berechnen, eine mit einem LP-Mint verbundene Farm aufgreifen — das ist alles Indexer-Arbeit. Programme selbst tun es nicht.
• Indexer-Ausfallzeiten sind API-Ausfallzeiten. Wenn die API veraltete oder leere Daten zurückgibt, ist der Indexer der Verdächtige. Der On-Chain-State ist unbeeinflusst; Integratoren mit eigenem RPC und SDK können Transaktionen treiben.

​

Was nicht geteilt wird

• Programme rufen sich nicht gegenseitig auf. Ein CPMM-Swap ruft nie CPI in CLMM oder AMM v4 auf. Das einzige Programm, das mehrere AMMs komponiert, ist das AMM Routing-Programm — und das ist selbst dünn, emittiert einfach CPIs in jedes AMM der Reihe nach.
• Keine gemeinsame Upgrade-Authority über Programme. Jedes On-Chain-Programm hat seinen eigenen Programm-Upgrade-Schlüssel (ein 3/4 Multisig plus eine 24h Timelock). Sie sind nicht verlinkt.
• Kein gemeinsamer State zwischen Farms und AMMs. Eine Farm weiß nicht, ob die LP, die sie staked, von einem CPMM-Pool, einem CLMM-Position-NFT-Mint oder einem unabhängigen SPL-Token ist. Das Farm-Programm behandelt den Staking-Mint als opak.
• Keine Oracle-Abhängigkeit. Preisbestimmung ist On-Chain-Reserves. Es gibt kein Pyth/Switchboard-Fallback; das AMM prüft kein Oracle vor der Liquidation.

​

Zeiger

• protocol-overview/architecture — das kanonische Diagramm, das zeigt, wie diese Teile komponieren.
• protocol-overview/versions-and-migration — wie sich die Konventionen über Programmversionen entwickelt haben.
• security/admin-and-multisig — wer die Schlüssel hinter den AmmConfigs kontrolliert.
• reference/fee-comparison — Gebührensatz-Matrix pro Produkt.
• reference/program-addresses — kanonische Programm-IDs.

• Raydium SDK v2 — die Quelle der Wahrheit für PDA Seeds, Account-Layouts und IDL-Definitionen.
• Raydium IDL-Registrierung — Anchor IDLs.
• Oben inline zitierte produktspezifische Accounts-Seiten.