Gemeinsame Infrastruktur

​

Was „gemeinsam” hier bedeutet

• Konventions-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 der gleiche Datensatz über viele Pools hinweg (die globale Authority-PDA in CPMM, die AmmConfig-Konten).
• Off-Chain-Sharing. Eine REST-API und ein TypeScript-SDK bedienen alle vier Programme. Integratoren interagieren mit einem HTTP-Host und einem NPM-Paket, unabhängig davon, welches Programm sie letztendlich aufrufen.

​

1. Authority-PDAs

• Für CPMM und CLMM ist die Authority-PDA ein globales Konto — jeder Pool dieses Typs nutzt es. Wenn Sie in CPMM CPI-en, benötigen Sie es einmal, nicht pro Pool.
• Für Pro-Pool- / Pro-Farm-Authorities leiten Sie die PDA aus 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 — Gelder transferieren. Es gibt keine Admin-Ü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,        // gate new pool creation in this tier
    pub index: u16,                       // tier index
    pub trade_fee_rate: u64,              // fraction of trade going to fees
    pub protocol_fee_rate: u64,           // fraction of trade fee to protocol
    pub fund_fee_rate: u64,               // fraction of trade fee to fund
    pub create_pool_fee: u64,             // one-time per-pool creation fee
    pub protocol_owner: Pubkey,           // signer for CollectProtocolFee
    pub fund_owner: Pubkey,               // signer for CollectFundFee
    pub padding: [u64; 16],
}

• Gebühren-Tiers sind global. Wenn ein Pool sagt „das ist ein 0,25%-Pool”, bedeutet das, dass er sich an die AmmConfig bindet, deren trade_fee_rate bei der Erstellung 0,25% war. Es gibt keine Pro-Pool-Rate-Überschreibung.
• Eine Config kann geändert werden, aber Pools folgen nicht. Wenn die Config-Authority eine AmmConfig bearbeitet, übernimmt jeder bestehende Pool, der an diese Config gebunden ist, sofort den neuen Satz. Dies ist ein Feature, kein Bug; so propagieren sich wirtschaftliche Änderungen auf Protokollebene ohne Pro-Pool-Migrationen.
• disable_create_pool ist der Deprecation-Hebel. Wenn eine Gebühren-Tier eingestellt wird, setzt das Protokoll-Multisig dieses Flag — bestehende Pools funktionieren weiter, aber keine neuen Pools können die Tier wählen.
• protocol_owner / fund_owner sind die Unterzeichner für Gebührensammlungsaufrufe. Sie auf ein Multisig zu setzen ist das, was die Gebührenabhebung kontrolliert. Sie sind NICHT die Zieladressen für die Gebühren selbst; das ist protocol_fee_destination / fund_fee_destination auf dem gleichen Konto.

​

3. Die Protokoll- / Fonds- / Creator-Gebührenaufteilung

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. Handelsgebühr sammelt sich im Pool an. Die Gebühr wird von der Eingabeseite des Swaps entfernt und der Betrag nach Gebühr ist das, was die Constant-Product-Mathematik sieht. Das ist das, was „die LP verdient die Gebühr” bedeutet — k steigt und damit auch der implizite 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-Status (protocol_fees_token{0,1}, fund_fees_token{0,1}, usw.) bis jemand die entsprechende Sammlungsanweisung aufruft. Sie verlassen die Vaults des Pools nicht bis dahin; aus Swap-Perspektive sind sie immer noch „im Pool”.
3. Sammlung bewegt sie raus. Protokoll- und Fonds-Pfade erfordern den jeweiligen protocol_owner / fund_owner Unterzeichner aus AmmConfig. CPMM Creator-Gebühren verwenden entweder den vom Creator unterzeichneten CollectCreatorFee-Pfad oder CollectCreatorFeePermissionless, den jeder Zahler auslösen kann, aber der die Ziele auf die kanonischen ATAs des Creators fixiert.

• Die Aufteilungsprozentsätze sind von der Handelsgebühr, nicht vom Handel. Eine 0,25%-Handelsgebühr mit einem 12%-Protokoll-Anteil bedeutet, dass das Protokoll 0,25% × 12% = 0,03% des Handels erhält — 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 denjenigen weitergeleitet wird, der das Token gestartet hat, konfiguriert bei Initialize und unveränderlich.
• AMM v4 teilt nur auf zwei Wegen auf, hartcodiert 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 die längerfristige Treasury. Die Aufteilung zwischen den beiden ist selbst eine abstimmbare.

​

4. Observation-Konten (TWAP-Ringpuffer)

// CPMM ObservationState (gekürzt)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // next slot to overwrite
    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,  // sum of (price × dt) since init
    pub cumulative_token_1_price_x32: u128,
}

• Jeder Swap ruft update_observation auf. Das Programm liest den aktuellen Preis, multipliziert mit den verstrichenen Sekunden seit der vorherigen Observation und addiert ihn zum kumulativen Zä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, die das gewünschte Fenster einklammern, und dividieren.
• Raydium selbst verwendet den TWAP nicht für Preisgestaltung. Die AMM-Mathematik liest die Spot-Reserven 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 wünschen, müssen einen aus der Log-Historie off-chain berechnen.

​

5. REST-API + SDK + IDL

• REST-API — https://api-v3.raydium.io. Eine Read-Mostly-indizierte Ansicht aller On-Chain-States 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-Aktualisierungen.
• IDL-Registry — Anchor-IDLs für jedes veröffentlichte Programm leben im raydium-idl Repo (eine JSON pro Programm: CPMM, CLMM, LaunchLab). Das TypeScript-SDK verbraucht diese IDLs intern; nachgelagerte Rust- / Python-Clients regenerieren aus den gleichen Dateien.

​

6. Indexer und Price Feeds

• Der Indexer ist das einzige, das „über” Cross-Program-State „weiß”. Einen CPMM-Pool seinem CLMM-Gegenstück zuordnen, eine 24h-Volume-Zahl über Programmversionen hinweg berechnen, eine Farm abholen, die mit einem LP-Mint verbunden ist — all das ist Indexer-Arbeit. Programme selbst tun es nicht.
• Indexer-Ausfallzeit ist API-Ausfallzeit. Wenn die API veraltete oder leere Daten zurückgibt, ist der Indexer der Verdächtige. Der On-Chain-State ist unbeeinträchtigt; Integratoren mit ihrem eigenen RPC und SDK können weiter transagieren.

​

Was nicht gemeinsam ist

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

​

Verweise

• protocol-overview/architecture — das kanonische Diagramm, das zeigt, wie diese Teile zusammengesetzt werden.
• protocol-overview/versions-and-migration — wie sich die Konventionen über Programmversionen hinweg 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 Registry — Anchor-IDLs.
• Produktspezifische Accounts-Seiten, die oben inline zitiert werden.