Admin-Schlüssel und Multisig

Die Berechtigungsstruktur der Raydium-Programme – welche Admin-Rollen was tun können, wie das Multisig aufgebaut ist und wie Sie on-chain nachprüfen, wer aktuell welche Rolle innehat.

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

Englische Version ansehen →

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.

Die Rolle 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

Einzelne Farms haben keinen Protokoll-Admin — der Ersteller einer Farm kontrolliert ausschließlich seine eigene Farm, und seine Befugnisse sind begrenzt (kann keine Nutzer-Stakes einziehen, kann das Staking-Mint nicht ändern).

​

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

Launches verfügen über keinen Protokoll-Admin, der Kurven ändern oder eingesammelte Gelder einziehen könnte.

​

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.

Betriebliche Eigenschaften des Upgrade-Multisigs:

• 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>

Die Ausgabe enthält:

Program Id:          CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner:               BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority:           <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes

Wenn 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?

1. Upgrade-Authority vor größeren Allokationen prüfen. Bestätigen Sie, dass sie mit dem dokumentierten Multisig übereinstimmt.
2. 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.
3. Timelock-bewusste Ausstiegsstrategien. Wenn Sie einen Auto-Compounder betreiben, stellen Sie sicher, dass Ihr Ausstiegspfad keine Instruction erfordert, die gerade geändert wird.
4. 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

• reference/program-addresses — kanonische Authority-Adressen.
• security/attack-vectors — wie sich Admin-Kompromittierungen auswirken.
• ray/treasury — Treasury- und Gebühreneinzugsadressen.
• security/disclosure — Meldung vermuteter Admin-Probleme.

Quellen:

• Squads Protocol — Multisig-Oberfläche.
• Solana BPF Loader Dokumentation — Upgrade-Mechanismus.