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änger-Besitzer auf PoolState.pool_creator und beschränkt beide Ziele auf die kanonischen ATAs des 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 bewegen, Gebühren ändern oder einen bestehenden Pool anfassen. 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 Operationsrolle. Sie existiert, damit ein Off-Chain-Keeper gefüllte Orders abwickeln kann, ohne dass der Order-Besitzer online sein muss. Der Keeper-Schlüssel ist heiß (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 Miete zurückzufordern (Miete 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 hinbewegen, als der Besitzer sie bereits autorisiert hat.
Farm v6
Einzelne Farms haben keinen Protokoll-Admin — jede Farm wird nur von ihrem Ersteller kontrolliert, 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 für kein Programm 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. Für Benutzer, die eine unveränderliche Alternative wünschen, ist das ältere AMM-v4-Programm seit seinem letzten Audit stabil; null Upgrades in 18 Monaten. Dieser Code-Pfad ist effektiv eingefroren, obwohl die Autorität noch existiert.AmmConfig-Autorität
Jede neue AmmConfig-Erstellung ist genehmigungspflichtig — das 3/5 Treasury Multisig autorisiert neue Gebührentarife und Tick-Abstände. Bestehende Pools referenzieren ihre AmmConfig nach PDA; der Pool-Gebührentarif 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 sie die Wirtschaft aller Pools, die diese Config verwenden, stillschweigend ändern. Die Protokoll-Richtlinie ist, 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ühren-Empfä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 ihre LP-Balance dadurch nie ändern — es ist der vorab zugewiesene Anteil des Protokolls, nicht LP-Geld.Farm-Ersteller-Autorität
Farms v6 geben dem Ersteller die Befugnis zu:- Den Reward-Vault finanzieren (mehr Token hinzufügen).
- Den Zeitplan verlängern (Endzeit später verschieben).
withdrawRewardnach Endzeit aufrufen, um ungenutzten Vault-Saldo 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 inspiziert 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 einem 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 in 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 unter reference/program-addresses.
Für AmmConfig / Pool-Admin-Rollen das On-Chain-Konto abrufen und dekodieren:
Historische Autoritätswechsel
Ü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.
- Timelock-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. Annehmen, 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 Ersteller die Farm früh beenden und den Reward-Vault zurückfordern (vorausgesetzt, kein Benutzer hat bereits gestakt). Sobald Benutzer gestakt 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 BPF Loader Docs — Upgrade-Mechanismus.