Skip to main content
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

​
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 bestehende Pools 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 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 schieben.
  • CloseLimitOrder — das Konto einer vollständig abgewickelten Order schließen, um Miete zurückzufordern (Miete geht an den Order-Besitzer).
Sie kann 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 — 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

Launches haben keinen Protokoll-Admin, der Kurven ändern oder aufgebrachte Gelder beschlagnahmen kann.

​
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 handhabbar ist. Die vier Autoritäten sind unabhängig, luftgekapselte Cold-Device-Unterzeichner, die von Kernteammitgliedern 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. 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ührenstufen und Tick-Abstände. Bestehende Pools referenzieren ihre AmmConfig nach PDA; die Pool-Gebührenstufe 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 Wirtschaftlichkeit aller Pools, die diese Konfiguration 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 die Konfiguration 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 Konfiguration) 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).
  • withdrawReward nach Endzeit aufrufen, um ungenutzten Vault-Saldo zurückzufordern.
Farm-Ersteller können nicht:
  • Benutzer-LP abheben.
  • Den Staking-Mint ändern.
  • Emissionsraten rückwirkend ändern (nur vorwärts via setRewards).
  • Benutzer-Harvests einfrieren.
Ein böswilliger Farm-Ersteller kann im schlimmsten Fall den Vault unterfinanzieren, sodass die Farm austrocknet; der Benutzer-Haupteinsatz ist immer sicher.

​
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 gibt, zu reagieren.
  • 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 + physische Schlüssel-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.
Das Treasury Multisig hat keinen Timelock — sein Umfang ist enger und Routineoperationen (Erstellen von AmmConfigs, Abwickeln von Gebühren) müssen am selben Tag landen. Das Treasury Multisig hält auch die begrenzte Programm-Admin-Autorität, die in den obigen Pro-Programm-Tabellen aufgeführt ist; dies ist eine vorübergehende Regelung und wird regelmäßig mit den Sicherheitspartnern des Projekts überprüft.

​
Autorität on-chain überprüfen

Der einfachste Weg, die aktuelle Upgrade-Autorität eines Programms zu überprüfen:
Die Ausgabe enthält:
Wenn 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 rufen Sie das On-Chain-Konto ab und dekodieren Sie:

​
Historische Autoritätswechsel

​
Überlegungen auf Benutzerseite

Was sollten Sie als Benutzer/LP/Integrator tun?
  1. Upgrade-Autorität vor großen Zuweisungen überprüfen. Bestätigen Sie, dass sie dem dokumentierten Multisig entspricht.
  2. Multisig-Aktivität überwachen. Squads UI zeigt ausstehende Transaktionen; ein geplantes Upgrade gibt Ihnen 24 Stunden Zeit, um sich abzuwickeln, wenn Sie der Änderung nicht zustimmen.
  3. Timelock-bewusste Rückzugsstrategien. Wenn Sie einen Auto-Compounder betreiben, stellen Sie sicher, dass Ihr Unwinding-Pfad keine Anweisung erfordert, die geändert wird.
  4. 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 Sie reference/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 Konfigurationsliste regelmäßig neu abrufen (stündlich ist in Ordnung).

​
3. Farm-Ersteller-Griefing-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 eingesetzt). Sobald Benutzer eingesetzt haben, werden Pro-Rata-Ansprüche vom Programm erzwungen; Rückforderung erhält nur den Überschuss nach rationalem Ende.

​
Verweise

Quellen: