Admin-Schlüssel und Multisig

Die Autoritätsfläche über Raydium-Programme — was jeder Admin tun kann, wie das Multisig strukturiert ist, und wie man on-chain überprüft, wer derzeit jede Rolle innehat.

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

Rolle	Autoritätsadresse	Was sie tun kann
Programm-Upgrade	Squads Multisig (3/4)	Neuen Programm-Bytecode bereitstellen
Pool-Admin	Treasury Multisig (3/5)	Pool-Status umschalten, Gebühren auf bestehenden Pools aktualisieren

​

CPMM

Rolle	Autoritätsadresse	Was sie tun kann
Programm-Upgrade	Squads Multisig (3/4)	Neuen Programm-Bytecode bereitstellen
AmmConfig-Admin	Treasury Multisig (3/5)	Neue AmmConfigs erstellen (Gebührenstufen); bestehende umschalten
Pool-Erstellungsgebühren-Empfänger	Treasury Multisig (3/5)	Die einmalige Pool-Erstellungsgebühr erhalten
Permission-PDA-Ersteller	Programm-admin oder ein dedizierter Permission-PDA-Besitzer (unterschiedlicher Wert auf Mainnet vs. Devnet)	CreatePermissionPda aufrufen, um einer Autorität Zugriff auf InitializeWithPermission zu gewähren. Seit dem Upgrade 2026-09 kann der dedizierte Besitzer auch ClosePermissionPda aufrufen, gewährt also sowohl als auch widerruft; vor diesem Upgrade war der Widerruf nur für den Admin möglich.

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 dieses Erstellers. Ein Aufrufer kann fehlende ATAs finanzieren und die Erfassung auslösen, kann aber die Gebühren nicht umleiten.

​

CLMM

Rolle	Autoritätsadresse	Was sie tun kann
Programm-Upgrade	Squads Multisig (3/4)	Neuen Programm-Bytecode bereitstellen
AmmConfig-Admin	Treasury Multisig (3/5)	AmmConfigs erstellen/ändern
DynamicFeeConfig-Admin	Treasury Multisig (3/5)	CreateDynamicFeeConfig / UpdateDynamicFeeConfig — kalibrieren Sie die dynamischen Gebührenstufen, die ein CreateCustomizablePool-Aufruf wählen kann
Überschüssige-Lamports-Sammler	Programm-admin oder eine dedizierte Collect-Lamports-Wallet (unterschiedlicher Wert auf Mainnet vs. Devnet)	CollectExcessLamports: Lamports über dem Rent-Exempt-Minimum von einem Pool’s PoolState und Vaults sammeln, plus alle übergebenen CLMM-eigenen PDAs. Verschiebt nur Lamports, niemals Token-Guthaben, und kann Konten nicht schließen. Hinzugefügt 2026-09-30.
limit_order_admin (programmweit)	Off-Chain-Operationale Hot Wallet, kein Multisig	Limit Orders im Namen ihrer Besitzer abwickeln und schließen. Der Keeper-Schlüssel ist eine einzelne programmweite Konstante (unterschiedlicher Wert auf Mainnet vs. Devnet), überprüft via signer == limit_order.owner || signer == limit_order_admin::ID auf SettleLimitOrder / CloseLimitOrder. Die Ausgabe landet immer in der ursprünglichen ATA des Besitzers; der Keeper kann Gelder nicht umleiten, Orders nicht ändern oder neue öffnen.

Das Erstellen zusätzlicher Pools für ein Paar unter einer seed_index-abgeleiteten Adresse (CreateCustomizablePoolV2) erfordert keine Rolle. Vor dem Upgrade 2026-10-22 war eine Permission PDA erforderlich, die von einem dedizierten permission_pda_admin-Schlüssel ausgestellt wurde; diese Rolle, das Permission-Konto und seine zwei Admin-Anweisungen wurden entfernt.

Der limit_order_admin ist eine bewusst enge operative Rolle. Sie existiert, damit ein Off-Chain-Keeper gefüllte Orders sammeln kann, ohne dass der Besitzer der Order 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).

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 wohin verschieben, als wohin der Besitzer sie bereits autorisiert hat.

​

Farm v6

Rolle	Autoritätsadresse	Was sie tun kann
Programm-Upgrade	Squads Multisig (3/4)	Neuen Programm-Bytecode bereitstellen
Farm-Ersteller (pro Farm)	Die Wallet des Farm-Erstellers	Reward-Vaults finanzieren, Zeitpläne verlängern, ungenutzte Rewards zurückfordern

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

Rolle	Autoritätsadresse	Was sie tun kann
Programm-Upgrade	Squads Multisig (3/4)	Neuen Programm-Bytecode bereitstellen
Programm-Admin	Gemeinsamer Raydium-Admin	GlobalConfig-Konten erstellen und aktualisieren; andere Admin-Only-Pfade betreiben
Delegierter Config-Ersteller	Dedizierte Cluster-spezifische Autorität	Eine neue GlobalConfig erstellen; kann eine bestehende Config nicht aktualisieren
Plattform-Admin	PDA-Seed-Autorität für eine PlatformConfig	Plattformeinstellungen aktualisieren und PlatformAllowConfig-Konten dieser Plattform erstellen oder schließen
Launch-Ersteller (pro Launch)	Die Wallet des Launch-Erstellers	Bonding-Curve-Creator-Gebühren beanspruchen; erhält CPMM-Creator-Fee-Rechte nur, wenn die Plattform platform_cp_creator nicht überschreibt

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, luftgekoppelte 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 nach 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 untätig ist:

Programm	Zuletzt bereitgestellt (Mainnet)
LaunchLab	2026-09-02
CPMM / CLMM / AMM Routing	2026-08-17
AMM v4	2026-07-22
Stable AMM	2026-06-22
Lock (Burn & Earn)	2025-08-23
Farm v6	2024-05-13

(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 Wirtschaftlichkeit 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ü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 angesammelten 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).
• Nach Endzeit withdrawReward aufrufen, um ungenutztes Vault-Guthaben zurückzufordern.

Farm-Ersteller können nicht:

• Gestaktes 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 inspiziert werden.

Multisig	Schwellenwert	Timelock	Umfang
Programm-Upgrade	3/4	24 Stunden	Alleinige Autorität für die Bereitstellung neuen Programm-Bytecodes für AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap und die Legacy-Farm/Staking-Programme. Ansicht unter app.squads.so/.../FytDr…ceZQK.
Treasury	3/5	keine	Treasury-Vermögenswerte, Protokoll-Einnahmen, Betriebsausgaben. Hält auch Rayidums begrenzte Programm-Admin-Autorität (Erstellen von AmmConfigs, Erfassen von Protokollgebühren, Konfigurieren von Pool-Parametern) vorerst. Ansicht unter v3.squads.so/dashboard/RVha…dHdtYz09.

Operative Eigenschaften 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.
• Luftgekoppeltes Cold-Device-Signieren. 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.

Das Treasury Multisig hat keinen Timelock — sein Umfang ist enger und Routine-Ops (Erstellen von AmmConfigs, Erfassen 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.

​

Überprüfung der Autorität On-Chain

Die einfachste Möglichkeit, die aktuelle Upgrade-Autorität eines Programms zu überprüfen:

solana program show <PROGRAM_ID>

Die Ausgabe enthält:

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

Falls 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 rufen Sie das On-Chain-Konto ab und dekodieren Sie es:

import { CpmmConfigInfoLayout } from "@raydium-io/raydium-sdk-v2";

const info = await connection.getAccountInfo(configPda);
const config = CpmmConfigInfoLayout.decode(info!.data);
console.log("protocol owner:", config.protocolOwner.toBase58());
console.log("fund owner:",     config.fundOwner.toBase58());

AmmConfig hat kein admin-Feld — der Programm-Admin ist ein öffentlicher Schlüssel, der in das Programm kompiliert ist (crate::admin::ID), und die pro-Konfiguration operativen Autoritäten sind protocolOwner / fundOwner. Die BPF-Upgrade-Autorität ist eine separate, auf Loader-Ebene liegende Angelegenheit; lesen Sie sie mit solana program show.

​

Historische Autoritätswechsel

Datum	Programm	Änderung
2022-12	AMM v4	Upgrade-Autorität nach Incident von Single-Sig zu 3/4-Multisig migriert
2023-02	Alle Programme	Alle operativen Rollen unter 3/5-Treasury-Multisig vereinheitlicht
2023-11	CLMM	Zweite Multisig für reine Reward-Operationen hinzugefügt, um Risiko zu reduzieren
2024-05	CPMM	Initiales Deployment mit Multisig-Autorität von Anfang an

​

Überlegungen auf Benutzerseite

Was sollten Sie als Benutzer / LP / Integrator tun?

1. Überprüfen Sie die Upgrade-Autorität vor großen Zuweisungen. Bestätigen Sie, dass sie der dokumentierten Multisig entspricht.
2. Überwachen Sie die Multisig-Aktivität. Die Squads UI zeigt ausstehende Transaktionen an; ein geplantes Upgrade gibt Ihnen 24 Stunden Zeit, um Ihre Position abzubauen, falls Sie mit der Änderung nicht einverstanden sind.
3. Time-Lock-bewusste Rückzugsstrategien. Falls Sie einen Auto-Compounder betreiben, stellen Sie sicher, dass Ihr Rückzugspfad keine Instruktion erfordert, die gerade geändert wird.
4. Nehmen Sie nicht an, dass Programme unveränderlich sind. Jedes Raydium-Programm kann aktualisiert werden; planen Sie entsprechend.

​

Fallstricke für Integratoren

​

1. Caching von Autoritätsadressen

Falls Sie die Upgrade-Autorität oder die Admin-Multisig-Adresse in Ihrem Code hardcodieren und diese später rotiert wird, 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 ausreichend).

​

3. Farm-Creator-Griefing-Vektoren

Falls Sie in einen Farm mit niedriger Reputation einzahlen, könnte der Creator den Farm vorzeitig beenden und den Reward-Vault zurückfordern (vorausgesetzt, kein Benutzer hat bereits gestaked). Sobald Benutzer gestaked haben, werden anteilige Ansprüche vom Programm durchgesetzt; die Rückforderung erhält nur den Überschuss nach rationalem Ende.

​

Verweise

• reference/program-addresses — kanonische Autoritätsadressen.
• security/attack-vectors — wie sich Admin-Kompromisse manifestieren.
• ray/treasury — Treasury- und Gebührensammeladressen.
• security/disclosure — Meldung vermuteter Admin-Probleme.

Quellen:

• Squads Protocol — Multisig UI.
• Solana program & loader docs — der Upgrade-Mechanismus und wie das Widerrufen der Upgrade-Autorität ein Programm unveränderlich macht.