Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Jedes Raydium-Programm hat mindestens eine privilegierte Rolle — einen Schlüssel, der das Programm aktualisieren, neue Konfigurationen erstellen oder Protokollgebühren abheben kann. Die Minimierung dessen, was diese Rollen tun können (und deren Absicherung hinter Multisigs mit Verzögerungen), ist die primäre Verteidigung gegen einen kompromittierten Admin. Diese Seite katalogisiert die Rollen und wie sie in der Praxis gesichert sind.
Rollen nach Programm
AMM v4
CPMM
Die Erfassung von Creator-Gebühren führt keine privilegierte Rolle ein.
CollectCreatorFeePermissionless akzeptiert jeden Zahler, beschränkt den Empfängerbesitzer auf PoolState.pool_creator und beschränkt beide Ziele auf die kanonischen ATAs dieses Creators. Ein Aufrufer kann fehlende ATAs finanzieren und die Erfassung auslösen, kann aber die Gebühren nicht umleiten.
CLMM
Das Halten einer
Permission PDA ermöglicht ihrer Autorität, CreatePermissionedPool aufzurufen — zusätzliche Pools für ein Paar zu erstellen, das bereits ein kanonisches hat, jeweils unter einer unterschiedlichen seed_index-abgeleiteten Adresse. Die Berechtigung ist auf Pool-Erstellung beschränkt: Sie kann keine Gelder verschieben, Gebühren ändern oder einen bestehenden Pool berühren. Das Widerrufen (ClosePermissionPda) hindert die Autorität daran, weitere Pools zu erstellen, lässt aber bereits erstellte Pools unverändert.
Der limit_order_admin ist eine bewusst enge Operational-Rolle. Sie existiert, damit ein Off-Chain-Keeper gefüllte Orders erfassen kann, ohne dass der Order-Besitzer online sein muss. Der Keeper-Schlüssel ist hot (lebt auf der Keeper-VM) und wird unabhängig von den obigen Multisigs rotiert. Konkret ist die Keeper-Autorität begrenzt auf:
SettleLimitOrder— die gefüllte Ausgabe einer Order zum Besitzer’s ATA zum Limit-Preis der Order pushen.CloseLimitOrder— ein vollständig abgewickeltes Order-Konto schließen, um Rent zurückzufordern (Rent geht an den Order-Besitzer).
OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder nicht aufrufen, kein Pool-Feld mutieren oder für eine andere Anweisung signieren — diese Überprüfungen werden on-chain durch die Seed- und has_one-Constraints in der Accounts-Struktur der Anweisung erzwungen. Ein kompromittierter Keeper kann im schlimmsten Fall nicht verfügbar sein (Orders bleiben geparkt, bis der Besitzer sie selbst abwickelt) oder legitim füllbare Orders außer der Reihe abwickeln/schließen; er kann Benutzergelder nicht woanders verschieben, als der Besitzer sie bereits autorisiert hat.
Farm v6
Einzelne Farms haben keinen Protokoll-Admin — jeder Farm-Ersteller kontrolliert nur ihre Farm, und die Befugnisse des Erstellers sind begrenzt (können Benutzer-Stakes nicht beschlagnahmen, können Staking-Mint nicht ändern).
LaunchLab
Die Plattform-Admin-Allowlist ist selbstbeschränkend: Sie begrenzt, welche
GlobalConfig-Konten Launches unter dieser Plattform verwenden dürfen. Sie gewährt keine Autorität über andere Plattformen oder bestehende Launch-Gelder. Kanonische delegierte Autoritätsadressen befinden sich in reference/program-addresses.
Programm-Upgrade-Autorität
Raydium-Programme verwenden den Standard-Solana-BPF Loader v3-Upgrade-Mechanismus. Die Upgrade-Autorität für alle Programme ist das 3/4 Squads Multisig. Warum 3/4: Genug Unterzeichner, dass ein einzelner Kompromiss unzureichend ist; wenig genug, dass die Koordination eines legitimen Upgrades machbar ist. Die vier Autoritäten sind unabhängig, luftgekapselte Cold-Device-Unterzeichner, die von Core-Team-Mitgliedern gehalten werden. Sequenzielles Signieren verhindert parallele Genehmigungen auf derselben Transaktion; Transaktionen haben ein festes Ablauf-Fenster. Multisig-Operationen werden regelmäßig in Partnerschaft mit Solanas STRIDE-Programm (Asymmetric Research) überprüft.Upgrade-Autorität entfernen
Raydium hat die Upgrade-Autorität keines Programms auf null gesetzt. Das Protokoll arbeitet unter dem Prinzip, dass Programme aktualisierbar sein müssen (um Bugs zu beheben, Erweiterungen wie Token-2022 hinzuzufügen, Integrationsdrift zu beheben). Kompromiss: Benutzer vertrauen darauf, dass das 3/4 Multisig nur gut überprüfte Upgrades bereitstellt. Kein Raydium-Programm ist derzeit eingefroren oder langsam genug, um als unveränderliche Alternative behandelt zu werden — AMM v4, historisch das statischste davon, wurde selbst am 2026-07-22 erneut bereitgestellt. Der zuletzt bereitgestellte Slot für jedes Programm ist öffentlich; lesen Sie ihn, bevor Sie davon ausgehen, dass einer von ihnen inaktiv ist:
(Aus dem
ProgramData-Konto jedes Programms; solana program show <PROGRAM_ID> meldet denselben Slot.)
AmmConfig-Autorität
Jede neue AmmConfig-Erstellung ist genehmigungspflichtig — das 3/5 Treasury Multisig autorisiert neue Gebührenstufen und Tick-Abstände. Bestehende Pools referenzieren ihre AmmConfig nach PDA; die Gebührenstufe des Pools ist das, was die AmmConfig sagt. Können Admins eine bestehende AmmConfig ändern? Ja, technisch.updateAmmConfig kann vom Admin aufgerufen werden. In der Praxis werden Änderungen an bereitgestellten AmmConfigs vermieden, da dies die Wirtschaft aller Pools, die diese Config verwenden, stillschweigend ändert. Die Protokollrichtlinie besteht darin, eine neue AmmConfig für jede Änderung zu erstellen und zu migrieren.
Können Admins Protokollgebühren über Config stehlen? Nein — die AmmConfig enthält Gebührenparameter, aber nicht den Protokollgebührenempfänger; das ist eine separate unveränderliche Adresse pro Pool.
Protokollgebühren-Anspruch
Ein Teil der Swap-Gebühren (typischerweise 3–12 bps von 25 bps Swap-Gebühr, je nach Config) sammelt sich in einem Protokollgebühren-Vault an. Das Multisig kann diese aufgelaufenen Gebühren abheben. Benutzer sehen ihren LP-Saldo dadurch nie ändern — es ist der vorab zugewiesene Anteil des Protokolls, nicht LP-Geld.Farm-Creator-Autorität
Farms v6 geben dem Creator die Befugnis zu:- Den Reward-Vault finanzieren (mehr Token hinzufügen).
- Den Zeitplan verlängern (Endzeit später verschieben).
withdrawRewardnach Endzeit aufrufen, um ungenutztes Vault-Guthaben zurückzufordern.
- Gestakete Benutzer-LP abheben.
- Den Staking-Mint ändern.
- Emissionsraten rückwirkend ändern (nur vorwärts via
setRewards). - Benutzer-Harvests einfrieren.
Squads Multisig-Konfiguration
Raydium betreibt zwei separate Squads Multisigs für unterschiedliche Risikoflächen. Beide können on-chain über die Squads Protocol UI überprüft werden.
Betriebseigenschaften des Upgrade-Multisigs:
- 24-Stunden-Timelock auf jede Transaktion. Ein heute genehmigtes Upgrade wird frühestens 24 Stunden später ausgeführt, was Benutzern Zeit zum Reagieren gibt.
- Luftgekapselte Cold-Device-Signierung. Cold Devices haben physisch entfernte Netzwerkkarten; sie verbinden sich nur mit einer Hardware-Wallet und lesen Transaktionsdaten via QR-Code von einem separaten Hot-Device.
- Sequenzielles Signieren. Erst nachdem ein Cold-Device eine Transaktion generiert und signiert hat, kann das nächste Cold-Device seinen Signierungsprozess beginnen — verhindert widersprüchliche oder parallele Signaturen auf derselben Transaktion.
- Transaktionsablauf. Jede Transaktion hat ein festes Ablauf-Fenster, sodass alte Transaktionen automatisch ungültig werden.
- TOTP + Physical-Key-Erzwingung auf den Hot-Devices, die für Transaktionsinitiierung und On-Chain-Broadcast verwendet werden.
- Öffentliche Transaktionswarteschlange. Jeder kann ausstehende Upgrades auf der Squads UI überwachen.
Autorität on-chain überprüfen
Der einfachste Weg, die aktuelle Upgrade-Autorität eines Programms zu überprüfen:Authority nicht die erwartete Squads Multisig-Adresse ist, stimmt etwas nicht. Raydium veröffentlicht die erwarteten Autoritätsadressen auf reference/program-addresses.
Für AmmConfig / Pool-Admin-Rollen das On-Chain-Konto abrufen und dekodieren:
AmmConfig hat kein admin-Feld — der Programm-Admin ist ein Pubkey, der in das Programm kompiliert ist (crate::admin::ID), und die Pro-Config-Operational-Autoritäten sind protocolOwner / fundOwner. Die BPF-Upgrade-Autorität ist eine separate, Loader-Level-Angelegenheit; lesen Sie sie mit solana program show.
Historische Autoritätsänderungen
Überlegungen auf Benutzerseite
Was sollten Sie als Benutzer/LP/Integrator tun?- Upgrade-Autorität vor großen Zuweisungen überprüfen. Bestätigen Sie, dass sie dem dokumentierten Multisig entspricht.
- Multisig-Aktivität überwachen. Squads UI zeigt ausstehende Transaktionen; ein geplantes Upgrade gibt Ihnen 24 Stunden Zeit zum Abwickeln, wenn Sie der Änderung nicht zustimmen.
- Time-Lock-bewusste Rückzugsstrategien. Wenn Sie einen Auto-Compounder betreiben, stellen Sie sicher, dass Ihr Abwicklungspfad keine Anweisung erfordert, die geändert wird.
- Nehmen Sie nicht an, dass Programme unveränderlich sind. Jedes Raydium-Programm kann aktualisiert werden; planen Sie dafür.
Fallstricke für Integratoren
1. Autoritätsadressen cachen
Wenn Sie die Upgrade-Autorität oder Admin-Multisig-Adresse in Ihrem Code hardcodieren und sie später rotiert, schlägt Ihre Überprüfung fehl. Rufen Siereference/program-addresses zur Laufzeit ab oder aktualisieren Sie regelmäßig.
2. Annahme, dass AmmConfigs stabil sind
Eine neue AmmConfig kann jederzeit erstellt werden. Ihr Aggregator/Router sollte die vollständige Config-Liste regelmäßig neu abrufen (stündlich ist in Ordnung).3. Farm-Creator-Grief-Vektoren
Wenn Sie in eine Farm mit niedriger Reputation einzahlen, könnte der Creator die Farm früh beenden und den Reward-Vault zurückfordern (vorausgesetzt, kein Benutzer hat bereits gestaked). Sobald Benutzer gestaked haben, werden Pro-Rata-Ansprüche vom Programm erzwungen; Rückforderung erhält nur das Übrige nach rationalem Ende.Verweise
reference/program-addresses— kanonische Autoritätsadressen.security/attack-vectors— wie sich Admin-Kompromisse manifestieren.ray/treasury— Treasury- und Gebührenerfassungsadressen.security/disclosure— Meldung verdächtiger Admin-Probleme.
- Squads Protocol — Multisig UI.
- Solana Program & Loader Docs — der Upgrade-Mechanismus und wie das Widerrufen der Upgrade-Autorität ein Programm unveränderlich macht.