Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Audits finden einige Fehlerklassen (bekannte Angriffsmuster, Zugriffskontrolle-Fehler, Integer-Überläufe) und übersehen andere (ökonomische Designmängel, spieltheoretische Manipulation, Integrationsfehler mit anderen Programmen). Raydi­ums Programme haben mehrere Audit-Runden durchlaufen; diese Seite listet sie auf und erörtert, was jedes Audit tatsächlich verifiziert hat.

​
Audit-Tabelle nach Programm

ProgrammPrüferDatumBericht
Order-book AMMKudelski SecurityQ2 2021Ansehen
Concentrated liquidity (CLMM)OtterSecQ3 2022Ansehen
Updated order-book AMMOtterSecQ3 2022Ansehen
StakingOtterSecQ3 2022Ansehen
Order-book AMM & OpenBook-MigrationMadShieldQ2 2023Ansehen
Constant-product AMM (CPMM)MadShieldQ1 2024Ansehen
Burn & Earn (Liquiditäts-Locker)HalbornQ4 2024Ansehen
LaunchLabHalbornQ2 2025Ansehen
CPMM (Update)Sec3Q3 2025Ansehen
CLMM-Update — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Ansehen
Mitglieder des Neodyme-Teams haben auch umfangreiche Überprüfungen über Bug-Bounty-Vereinbarungen durchgeführt. Alle Audit-Berichte für Raydium-Programme werden unter github.com/raydium-io/raydium-docs/audit/ gespiegelt. Jeder Prüfer veröffentlicht auch auf seiner eigenen Website.

​
Was Audits abdecken

Ein typischer Raydium-Audit (~3–6 Wochen, 2 Prüfer) behandelt:
  • Zugriffskontrolle — ist jede privilegierte Operation ordnungsgemäß geschützt?
  • Arithmetik — Überläufe, Unterläufe, Rundungsrichtung, Festkomma-Genauigkeit.
  • Account-Validierung — hat jedes Account den korrekten Owner, die korrekte Mint, die korrekte Authority?
  • Reentrancy-ähnliche Muster — aktualisiert sich der Status vor oder nach einem CPI?
  • PDA-Ableitung — sind die Seeds konsistent an allen Stellen?
  • Fehlercodes und Nachrichten — setzen sich Fehlerbedingungen sauber durch?
  • Code-Qualität — idiomatisches Rust, toter Code, unerreichbare Branches.

​
Was Audits nicht abdecken

  • Ökonomische Spieltheorie — z. B. „kann ich 1000 Pools kostenlos erstellen und damit den Router grippefen?”
  • MEV / Reihenfolge — Sandwich-Attacken, Front-Running via Validator-Kooperation.
  • Off-Chain-Infrastruktur — RPC-Zuverlässigkeit, Indexer-Korrektheit, Frontend.
  • Integrationen mit anderen Programmen — Fehler, die nur bei Komposition mit bestimmten Lending-, Options- oder Aggregator-Kontrakten auftreten.
  • Emergente Verhaltensweisen über Zeit — was passiert nach 10 Millionen Positionen? Audits schauen sich kleine Testfälle an.
Deshalb bedeutet Audit ≠ Sicherheitsgarantie. Raydium ergänzt Audits durch Bug-Bounties, Monitoring und defensives Engineering.

​
Status der Behebung von Findings

Jeder Audit erzeugt eine Findings-Liste (kritisch / hoch / mittel / niedrig / informativ) mit Schweregrad-Zählungen und Status pro Finding (Behoben / Zur Kenntnis genommen / Wird nicht behoben). Detaillierte Aufschlüsselungen pro Finding werden hier nicht dupliziert — lesen Sie jeden Bericht direkt über die Tabelle oben.

​
Nachaudits nach bedeutenden Änderungen

Wenn ein Programm ein bedeutendes Update ausliefert (neue Anweisung, neues Account-Feld, neue Extension-Unterstützung), beauftragt Raydium einen Nachaudit. Die Sec3-Überprüfung vom Q3 2025 für CPMM und die Sec3-Überprüfung vom Q2 2026 für CLMM (Limit Order, Dynamic Fee, Single Asset Fee) in der obigen Tabelle sind beide Nachaudits dieser Art. Der Nachaudit-Umfang ist enger (nur das Diff), aber es ist ein echter Nachaudit — nicht nur eine Code-Überprüfung. Berichte für Nachaudits werden an den Hauptaudit-Bericht angehängt.

​
On-Chain-Verifizierung

Der Hash des eingesetzten Programms sollte dem Hash des geprüften Codes entsprechen. Jeder kann dies überprüfen: 
# Rufen Sie den eingesetzten Programm-Bytecode ab.
solana program dump <PROGRAM_ID> program.so

# Bauen Sie das Repo beim geprüften Commit.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# Vergleichen.
sha256sum program.so target/deploy/raydium_cp_swap.so
Die Anchor-verifizierbaren Builds erzeugen deterministischen Bytecode; Hashes sollten exakt übereinstimmen. Wenn nicht, ist das eingesetzte Programm nicht das geprüfte — eskalieren Sie. Raydium veröffentlicht die erwarteten Hashes pro Bereitstellung im Releases-Bereich des Repos.

​
Wie man einen Audit-Bericht liest

Ein kurzer Leitfaden für Nicht-Prüfer:
  1. Springen Sie zur Findings-Zusammenfassung — eine Tabelle mit Schweregrad-Zählungen. Wenn die „Kritisch”-Zahl >0 ist und Sie „Open”-Status sehen, schauen Sie nach.
  2. Lesen Sie die Beschreibung und den Status jedes Findings. „Behoben in Commit XYZ” bedeutet gelöst; „Zur Kenntnis genommen” bedeutet das Team akzeptiert das Risiko; „Teilweise behoben” lohnt sich näher anzusehen.
  3. Lesen Sie den Scope-Bereich. Wenn der Audit die Anweisung oder das Account nicht abdeckte, das Sie interessiert, ist die Abwesenheit von Findings dort kein Beweis für Sicherheit.
  4. Überfliegen Sie den Empfehlungsbereich des Prüfers. Oft nützlicher als die Findings — bringt „wir konnten das formal nicht beweisen, aber wir sind unwohl” Notizen hervor.

​
Bug-Bounty-Integration

Audits laufen vor der Bereitstellung; Bug-Bounties laufen kontinuierlich nach der Bereitstellung. Raydi­ums Bounty-Programm (security/disclosure) deckt alles ab, was Audits tun, plus:
  • Ökonomische Attacken, die Audits nicht abdecken.
  • Fehler in neuen Integrationen.
  • Implementierungsfehler in SDKs und Off-Chain-Komponenten.
Ein Whitehat-Finding im Bounty-Programm wird typischerweise schneller bezahlt als auf den nächsten Audit-Zyklus zu warten; die Anreize sind ausgerichtet auf schnelle Offenlegung. Das aktive Programm wird auf Immunefi gehostet: immunefi.com/bug-bounty/raydium/information.

​
Historische Vorfälle

Raydi­ums Programme hatten zwei bemerkenswerte Vorfälle in der realen Welt:

​
Pool-Authority-Exploit (Dezember 2022)

Was: Der private Schlüssel der AMM-v4-Pool-Authority wurde kompromittiert, was einem Angreifer ermöglichte, mehrere Pools zu leeren. Umfang: Operatives Schlüsselmanagement, nicht ein Programm-Bug. Der Audit hatte den Code nicht gekennzeichnet, da der Code korrekt war; der Schlüsselmanagement-Prozess war das Versäumnis. Behebung: Multisig-Migration (alle Authority-Rollen wurden zu Squads Multisig verschoben); zusätzliche operative Kontrollen. Lektion: Audits decken Schlüsselmanagement nicht ab. Siehe security/admin-and-multisig.

​
OpenBook-Integrations-Freeze (Januar 2023)

Was: Ein OpenBook-Programm-Update änderte Account-Semantik; AMM v4s MonitorStep-Crank konnte PnL nicht abrechnen, bis ein AMM-v4-Patch ausgeliefert wurde. Umfang: Integrations-Bug — kein Programm war isoliert falsch. Behebung: AMM-v4-Patch und koordinierte Bereitstellung. Lektion: Audits von Programm A fangen Fehler in der Integration von Programm A mit Programm B nicht auf. Das richtige Werkzeug ist Integrations-Testing + gestaffelte Rollouts.

​
Verweise

Quellen: