> ## 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.

# Sicherheit & Risiken

> Audit-Verlauf, Admin-Kontrollen, bekannte Risiken, Angriffsvektoren und verantwortungsvolles Offenlegen von Sicherheitslücken.

<Info>
  **Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.**

  [Englische Version ansehen →](/security/index)
</Info>

## Für wen dieses Kapitel bestimmt ist

Auditor\*innen, Sicherheitsforschende, Risikoabteilungen bei Integratoren und institutionelle Nutzer, die Raydium vor der Bereitstellung von Kapital oder Code evaluieren müssen.

## Inhaltsverzeichnis des Kapitels

<CardGroup cols={2}>
  <Card title="Audits" icon="shield-check" href="/de/security/audits">
    Vollständige Liste der Audits pro Programm mit Audit-Unternehmen, Scope, Berichtslinks und Status der Folgekorrekturen.
  </Card>

  <Card title="Admin-Schlüssel und Multisig" icon="key" href="/de/security/admin-and-multisig">
    Welche Autoritäten pro Programm existieren, was diese ändern können, wie sie kontrolliert werden (Multisig, Timelock) und wie man sie On-Chain verifiziert.
  </Card>

  <Card title="Oracle- und Token-Risiken" icon="triangle-exclamation" href="/de/security/oracle-and-token-risks">
    Oracle-Nutzung und Ausfallszenarien, Token-2022-Erweiterungsrisiken (Freeze Authority, Transfer Hook, Permanent Delegate) und wie Raydium diese mindert.
  </Card>

  <Card title="Angriffsvektoren" icon="bug" href="/de/security/attack-vectors">
    Historische und hypothetische Vektoren: Sandwich/MEV, Preismanipulation, Donation-Angriffe, Token-2022-Hook-Missbrauch, Komposabilitätsrisiken.
  </Card>

  <Card title="Offenlegung" icon="envelope-open-text" href="/de/security/disclosure">
    Richtlinie zur verantwortungsvollen Offenlegung, Bug-Bounty-Scope, Kontaktwege und was *nicht* öffentlich offengelegt werden sollte.
  </Card>
</CardGroup>

## Schreibvorgaben

* Zitieren Sie spezifische On-Chain-Konten/Programm-IDs für jeden Anspruch über Autorität oder Minderung.
* Veröffentlichen Sie hier keine privaten Admin-Verfahren oder operativen Runbooks.
* Halten Sie historische Incident-Darstellungen sachlich und verlinken Sie auf Post-Mortems, wo diese existieren.