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.
Jedes Raydium-Programm besitzt mindestens eine privilegierte Rolle – einen Schlüssel, der das Programm aktualisieren, neue Configs anlegen oder Protokollgebühren abheben kann. Diese Rollen so eng wie möglich zu halten (und sie hinter Multisigs mit Zeitverzögerung zu sichern) ist der wichtigste Schutz gegen einen kompromittierten Admin. Diese Seite dokumentiert alle Rollen und ihre jeweilige Absicherung.
Rollen nach Programm
AMM v4
| Rolle | Authority-Adresse | Befugnisse |
|---|
| Programm-Upgrade | Squads Multisig (3/4) | Neuen Programm-Bytecode deployen |
| Pool-Admin | Treasury Multisig (3/5) | Pool-Status umschalten, Gebühren bestehender Pools aktualisieren |
CPMM
| Rolle | Authority-Adresse | Befugnisse |
|---|
| Programm-Upgrade | Squads Multisig (3/4) | Neuen Programm-Bytecode deployen |
| AmmConfig-Admin | Treasury Multisig (3/5) | Neue AmmConfigs (Fee-Tiers) anlegen; bestehende umschalten |
| Create-Pool-Fee-Empfänger | Treasury Multisig (3/5) | Die einmalige Pool-Erstellungsgebühr empfangen |
CLMM
| Rolle | Authority-Adresse | Befugnisse |
|---|
| Programm-Upgrade | Squads Multisig (3/4) | Neuen Programm-Bytecode deployen |
| AmmConfig-Admin | Treasury Multisig (3/5) | AmmConfigs anlegen/ändern |
| DynamicFeeConfig-Admin | Treasury Multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — kalibriert die dynamischen Fee-Tiers, in die ein CreateCustomizablePool-Aufruf einbuchen kann |
limit_order_admin (programmweit) | Operatives Hot Wallet (off-chain), kein Multisig | Limit Orders im Auftrag ihrer Eigentümer abschließen und schließen. Der Keeper-Schlüssel ist eine einzelne, programmweit gültige Konstante (unterschiedlicher Wert auf Mainnet und Devnet); die Prüfung erfolgt via signer == limit_order.owner || signer == limit_order_admin::ID in SettleLimitOrder / CloseLimitOrder. Der Output landet immer in der ATA des ursprünglichen Eigentümers; der Keeper kann Gelder weder umleiten noch Orders ändern oder neue eröffnen. |
limit_order_admin ist bewusst eng gefasst. Sie ermöglicht es einem off-chain Keeper, abgeschlossene Orders zu verarbeiten, ohne dass der Eigentümer der Order online sein muss. Der Keeper-Schlüssel ist hot (läuft auf der Keeper-VM) und wird unabhängig von den oben genannten Multisigs rotiert. Konkret ist die Keeper-Authority auf Folgendes beschränkt:
SettleLimitOrder — den ausgefüllten Output einer Order zum Limit-Preis in die ATA des Eigentümers übertragen.CloseLimitOrder — das Konto einer vollständig abgewickelten Order schließen, um Rent zurückzufordern (Rent geht an den Order-Eigentümer).
Der Keeper kann weder OpenLimitOrder, IncreaseLimitOrder noch DecreaseLimitOrder aufrufen, kein Pool-Feld verändern oder für eine andere Instruction signieren — diese Prüfungen werden on-chain durch Seed- und has_one-Constraints im Accounts-Struct der Instruction erzwungen. Ein kompromittierter Keeper kann im schlimmsten Fall nicht verfügbar sein (Orders bleiben stehen, bis der Eigentümer sie selbst abwickelt) oder legitim ausführbare Orders außer der Reihe abschließen/schließen; er kann Nutzermittel nicht dorthin bewegen, wohin der Eigentümer sie nicht bereits autorisiert hat.
Farm v6
| Rolle | Authority-Adresse | Befugnisse |
|---|
| Programm-Upgrade | Squads Multisig (3/4) | Neuen Programm-Bytecode deployen |
| Farm-Ersteller (je Farm) | Wallet des Farm-Erstellers | Reward-Vaults befüllen, Zeitpläne verlängern, ungenutzte Rewards zurückfordern |
LaunchLab
| Rolle | Authority-Adresse | Befugnisse |
|---|
| Programm-Upgrade | Squads Multisig (3/4) | Neuen Programm-Bytecode deployen |
| Launch-Ersteller (je Launch) | Wallet des Launch-Erstellers | Creator-Fees nach Graduierung einsammeln; nicht graduierte Kurven-Reste abheben |
Programm-Upgrade-Authority
Raydiums Programme verwenden den standardmäßigen Solana-BPF Loader v3-Upgrade-Mechanismus. Die Upgrade-Authority für alle Programme liegt beim 3/4 Squads Multisig.
Warum 3/4: Genug Unterzeichner, sodass eine einzelne Kompromittierung nicht ausreicht; wenige genug, um ein legitimes Upgrade koordinieren zu können. Die vier Authorities sind unabhängige, air-gapped Cold-Device-Unterzeichner, die von Kernteam-Mitgliedern gehalten werden. Sequenzielles Signieren verhindert parallele Genehmigungen auf derselben Transaktion; Transaktionen haben ein festes Ablaufzeitfenster. Multisig-Operationen werden regelmäßig in Zusammenarbeit mit dem Solana STRIDE Program (Asymmetric Research) geprüft.
Upgrade-Authority entfernen
Raydium hat die Upgrade-Authority keines Programms auf null gesetzt. Das Protokoll folgt dem Grundsatz, dass Programme aktualisierbar bleiben müssen (um Fehler zu beheben, Erweiterungen wie Token-2022 hinzuzufügen und Integrations-Drift zu korrigieren). Der Kompromiss: Nutzer vertrauen darauf, dass das 3/4 Multisig ausschließlich sorgfältig geprüfte Upgrades deployt.
Für Nutzer, die eine unveränderliche Alternative wünschen: Das ältere AMM v4-Programm ist seit seinem letzten Audit stabil; in 18 Monaten wurden null Upgrades durchgeführt. Dieser Code-Pfad ist faktisch eingefroren, auch wenn die Authority noch existiert.
AmmConfig-Authority
Das Anlegen neuer AmmConfigs ist permissioned — das 3/5 Treasury Multisig genehmigt neue Fee-Tiers und Tick-Abstände. Bestehende Pools referenzieren ihre AmmConfig per PDA; der Fee-Tier eines Pools ist das, was die AmmConfig vorgibt.
Können Admins eine bestehende AmmConfig ändern? Technisch ja. updateAmmConfig ist durch den Admin aufrufbar. In der Praxis werden Änderungen an bereits deployten AmmConfigs vermieden, da dies die Konditionen aller Pools, die diese Config nutzen, stillschweigend verändert. Die Protokollrichtlinie sieht vor, für jede Änderung eine neue AmmConfig anzulegen und zu migrieren.
Können Admins Protokollgebühren über die Config stehlen? Nein — die AmmConfig enthält Fee-Parameter, aber nicht den Protokollgebühren-Empfänger; das ist eine separate, unveränderliche Adresse pro Pool.
Protokollgebühren-Abruf
Ein Teil der Swap-Gebühren (typischerweise 3–12 bps von 25 bps Swap-Gebühr, je nach Config) fließt in einen Protokollgebühren-Vault. Das Multisig kann diese aufgelaufenen Gebühren abheben. Nutzer sehen dabei keine Veränderung an ihrem LP-Guthaben — es handelt sich um den vorher festgelegten Protokollanteil, nicht um LP-Kapital.
Farm-Ersteller-Authority
Farms v6 geben dem Ersteller folgende Befugnisse:
- Den Reward-Vault befüllen (weitere Token hinzufügen).
- Den Zeitplan verlängern (Endzeitpunkt nach hinten verschieben).
- Nach Ablauf
withdrawReward aufrufen, um nicht genutztes Vault-Guthaben zurückzufordern.
Farm-Ersteller können nicht:
- Gestakte Nutzer-LP abheben.
- Das Staking-Mint ändern.
- Emissionsraten rückwirkend ändern (nur vorwärtsgerichtet via
setRewards).
- Nutzer-Harvests einfrieren.
Ein bösartiger Farm-Ersteller kann im schlimmsten Fall den Vault unterfüllen, sodass die Farm leer läuft; das Haupt-Stake der Nutzer ist stets sicher.
Squads-Multisig-Konfiguration
Raydium betreibt zwei separate Squads Multisigs für unterschiedliche Risikobereiche. Beide können on-chain über die Squads Protocol-Oberfläche eingesehen werden.
| Multisig | Schwellenwert | Timelock | Geltungsbereich |
|---|
| Programm-Upgrade | 3/4 | 24 Stunden | Alleinige Authority für das Deployen neuen Programm-Bytecodes für AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap und die Legacy Farm/Staking-Programme. Einsehbar unter app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | keine | Treasury-Assets, Protokolleinnahmen, Betriebsausgaben. Hält außerdem Raydiums begrenzte Programm-Admin-Authority (AmmConfigs anlegen, Protokollgebühren einsammeln, Pool-Parameter konfigurieren) bis auf Weiteres. Einsehbar unter v3.squads.so/dashboard/RVha…dHdtYz09. |
- 24-Stunden-Timelock auf jede Transaktion. Ein heute genehmigtes Upgrade wird frühestens 24 Stunden später ausgeführt, sodass Nutzer Zeit haben zu reagieren.
- Air-gapped Cold-Device-Signierung. Cold Devices haben physisch entfernte Netzwerkkarten; sie verbinden sich nur mit einem Hardware-Wallet und lesen Transaktionsdaten per QR-Code von einem separaten Hot Device.
- Sequenzielles Signieren. Erst nachdem ein Cold Device eine Transaktion erstellt und signiert hat, kann das nächste Cold Device seinen Signierprozess beginnen — dies verhindert widersprüchliche oder parallele Signaturen auf derselben Transaktion.
- Transaktionsablauf. Jede Transaktion hat ein festes Ablaufzeitfenster; veraltete Transaktionen werden automatisch ungültig.
- TOTP + Hardkey-Enforcement auf den Hot Devices, die für Transaktionsinitiierung und On-chain-Broadcast verwendet werden.
- Öffentliche Transaktionswarteschlange. Jeder kann ausstehende Upgrades in der Squads-Oberfläche verfolgen.
Das Treasury Multisig hat keinen Timelock — sein Geltungsbereich ist enger und Routineoperationen (AmmConfigs anlegen, Gebühren einsammeln) müssen noch am selben Tag abgewickelt werden. Das Treasury Multisig hält auch die begrenzte Programm-Admin-Authority, die in den programmspezifischen Tabellen oben aufgeführt ist; das ist eine Übergangslösung und wird regelmäßig mit den Sicherheitspartnern des Projekts überprüft.
Authority on-chain verifizieren
Der einfachste Weg, die aktuelle Upgrade-Authority eines Programms zu prüfen:
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority nicht der erwarteten Squads-Multisig-Adresse entspricht, stimmt etwas nicht. Raydium veröffentlicht die erwarteten Authority-Adressen unter reference/program-addresses.
Für AmmConfig-/Pool-Admin-Rollen das On-chain-Konto abrufen und dekodieren:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Erwartet: 3/5 Treasury Multisig.
Historische Authority-Änderungen
| Datum | Programm | Änderung |
|---|
| 2022-12 | AMM v4 | Upgrade-Authority nach einem Vorfall von Single-Sig auf 3/4 Multisig migriert |
| 2023-02 | Alle Programme | Alle operativen Rollen unter dem 3/5 Treasury Multisig vereinheitlicht |
| 2023-11 | CLMM | Zweites Multisig für ausschließlich reward-bezogene Operationen hinzugefügt, um die Angriffsfläche zu reduzieren |
| 2024-05 | CPMM | Initialer Deploy mit Multisig-Authority ab Tag null |
Überlegungen für Nutzer
Was sollten Sie als Nutzer/LP/Integrator tun?
- Upgrade-Authority vor größeren Allokationen prüfen. Bestätigen Sie, dass sie mit dem dokumentierten Multisig übereinstimmt.
- Multisig-Aktivität beobachten. Die Squads UI zeigt ausstehende Transaktionen; ein geplantes Upgrade gibt Ihnen 24 Stunden Zeit, Positionen aufzulösen, falls Sie mit der Änderung nicht einverstanden sind.
- Timelock-bewusste Ausstiegsstrategien. Wenn Sie einen Auto-Compounder betreiben, stellen Sie sicher, dass Ihr Ausstiegspfad keine Instruction erfordert, die gerade geändert wird.
- Keine Unveränderlichkeit annehmen. Jedes Raydium-Programm kann aktualisiert werden; planen Sie entsprechend.
Fallstricke für Integratoren
1. Authority-Adressen cachen
Wenn Sie die Upgrade-Authority oder Admin-Multisig-Adresse fest in Ihrem Code kodieren und sie später rotiert wird, schlägt Ihre Verifizierung fehl. Laden Sie die Adressen zur Laufzeit von reference/program-addresses oder aktualisieren Sie sie regelmäßig.
2. AmmConfigs als stabil annehmen
Eine neue AmmConfig kann jederzeit angelegt werden. Ihr Aggregator/Router sollte die vollständige Config-Liste regelmäßig neu laden (stündlich ist ausreichend).
3. Grief-Vektoren durch Farm-Ersteller
Wenn Sie in eine Farm mit geringer Reputation einzahlen, könnte der Ersteller die Farm vorzeitig beenden und den Reward-Vault zurückfordern (sofern noch kein Nutzer gestaked hat). Sobald Nutzer gestaked haben, werden Pro-rata-Ansprüche durch das Programm erzwungen; der Rückforderungsanspruch betrifft nur den Restbetrag nach rationalem Abschluss.
Weiterführende Links
Quellen:
