DeFi-Risiken bewerten

Bevor ein Fonds, eine Treasury, ein Verwahrer oder eine Bank ein DeFi-Protokoll nutzt, muss jemand eine einfache Frage beantworten: Wie könnten wir hier Geld verlieren, und wie viel? Diese Lektion führt die Mechanismen der vorangegangenen vier Lektionen zu einer strukturierten Bewertung zusammen und zeigt anhand realer Vorfälle, wie die einzelnen Risiken aussehen, wenn sie eintreten.

Smart-Contract-Risiko und was Audits tatsächlich aussagen

Das unmittelbarste Risiko ist ein Fehler im Code. Ein Audit ist eine zeitlich begrenzte Überprüfung einer bestimmten Codeversion (identifiziert durch einen Commit-Hash) durch ein externes Unternehmen. Sie endet mit einem Bericht, der die Feststellungen nach Schweregrad auflistet und angibt, ob sie behoben wurden. Ein Audit ist ein wertvoller Nachweis, aber keine Garantie. Audits übersehen subtile Rechen- und Interaktionsfehler, sie decken keinen Code ab, der nach der Überprüfung bereitgestellt wird, und das Verhalten des Protokolls im Zusammenspiel mit anderen Protokollen wird nur selten geprüft.

Zwei Vorfälle aus dem Jahr 2025 verdeutlichen das:

• Cetus (Sui, 22. Mai 2025): Ein Angreifer nutzte eine fehlerhafte Überlaufprüfung in einer vom DEX verwendeten Mathematikbibliothek aus, um mit fast keinen Token riesige Liquiditätspositionen zu prägen und dabei etwa 223 Millionen US-Dollar zu erbeuten. Die Sui-Validatoren blockierten anschließend etwa 162 Millionen US-Dollar der gestohlenen Gelder on-chain. Das begrenzte die Verluste, zeigte aber auch, dass die Validatoren eines vermeintlich dezentralisierten Netzwerks sich koordinieren können, um Vermögenswerte einzufrieren.
• Balancer V2 (3. November 2025): Ein Rundungsfehler in der Skalierungslogik der Composable Stable Pools ermöglichte es einem Angreifer in Verbindung mit gebündelten Swaps, etwa 128 Millionen US-Dollar über mehrere Chains hinweg abzuziehen. Der Code war mehrfach auditiert worden und seit Jahren im Einsatz.

Stärkere Nachweise ergeben sich aus einer Kombination von mehreren unabhängigen Audits des bereitgestellten Codes, formaler Verifikation kritischer Invarianten, einem substanziellen Bug-Bounty-Programm, einer längeren Zeit im Produktivbetrieb mit erheblichen gefährdeten Werten, Echtzeitüberwachung und der Möglichkeit, das Protokoll im Notfall anzuhalten. Auch diese Möglichkeit ist eine zu bewertende administrative Befugnis.

Oracle- und wirtschaftliche Manipulation

Ein Angreifer, der den Preis beeinflussen kann, den ein Protokoll abruft, kann Kredite gegen überbewertete Sicherheiten aufnehmen oder ungerechtfertigte Liquidationen auslösen. Die Schutzmaßnahmen sind bekannt: Preise ausschließlich aus liquiden Märkten, Aggregation über mehrere Quellen, zeitgewichtete Durchschnitte, Obergrenzen dafür, wie stark sich ein Preis pro Aktualisierung ändern darf, und Angebotsobergrenzen für Vermögenswerte mit geringer Liquidität. Bei der Prüfung sollte festgestellt werden, welche Oracles das Protokoll verwendet, welche Märkte jedes Oracle berücksichtigt und was passiert, wenn es keine Aktualisierungen mehr liefert. Der Fall Mango Markets aus der Lektion Kreditvergabe, Kreditaufnahme und Liquidationen ist das maßgebliche Beispiel.

Das Risiko des wirtschaftlichen Designs ist umfassender: Das Protokoll funktioniert genau wie programmiert, aber die Anreize versagen. Beispiele sind Reward-Token, die Renditen nur so lange aufrechterhalten, wie neues Kapital zufließt, Sicherheiten, deren Wert vom Protokoll selbst abhängt (Reflexivität), die Diskrepanz zwischen der den Einlegern versprochenen sofortigen Liquidität und den dahinterstehenden illiquiden Vermögenswerten sowie rekursive Hebelwirkung, die eine kleine Preisbewegung in eine Liquidationskaskade verwandelt. Der Zusammenbruch des algorithmischen Stablecoins UST im Jahr 2022, der in der Lektion Stablecoins in der Marktinfrastruktur behandelt wird, ist das größte Beispiel.

Governance, Admin-Schlüssel und Upgradefähigkeit

Die meisten Protokolle sind nicht unveränderlich. Sie verwenden Proxy-Verträge, mit denen ein Administrator den Code hinter einer festen Adresse austauschen kann, und verfügen über privilegierte Funktionen, um Vermögenswerte zu listen, Parameter zu ändern, Oracles festzulegen oder das Protokoll anzuhalten. Wer diese Befugnisse besitzt, kann im schlimmsten Fall alles an sich nehmen. Bei der Bewertung sollte Folgendes festgestellt werden:

• Welche Funktionen privilegiert sind und wer sie aufrufen kann: ein einzelner Schlüssel, ein Multisig (mit welcher Schwelle und welchen Unterzeichnern) oder eine Token-Governance.
• Ob Änderungen über einen Timelock laufen, also eine verpflichtende Verzögerung, die Nutzern Zeit gibt, eine Änderung zu sehen und auszusteigen, bevor sie wirksam wird.
• Ob Notfallbefugnisse (etwa die eines Sicherheitsrats) den Timelock umgehen und wie eng sie begrenzt sind.

Der Drift-Vorfall vom 1. April 2026 auf Solana zeigt, wie diese Kontrollen gemeinsam versagen können. Über mehrere Wochen brachten Angreifer Mitglieder des Sicherheitsrats von Drift durch Social Engineering dazu, Transaktionen im Voraus zu unterzeichnen. Dabei nutzten sie eine Solana-Funktion (dauerhafte Nonces), mit der unterzeichnete Transaktionen später ausgeführt werden können. Tage vor dem Angriff war der Sicherheitsrat zu einem 2-aus-5-Multisig gewechselt und hatte seinen Timelock entfernt. Mit den vorab unterzeichneten Transaktionen wurde ein wertloser, von den Angreifern erstellter Token als zulässige Sicherheit gelistet und die Auszahlungslimits wurden erhöht. Die Angreifer zahlten den Token zu einem künstlich erhöhten Preis ein und zogen innerhalb weniger Minuten etwa 285 Millionen US-Dollar ab. Blockchain-Analyseunternehmen wie TRM Labs und Elliptic bewerteten nordkoreanische Hacker als wahrscheinlich Verantwortliche. Es lag kein Codefehler vor. Die Governance- und Signaturkontrollen aus den Lektionen Wallet-Stufen, Transaktionsrichtlinien und Signaturabläufe und Governance-Angriffe und Fehlermuster sind unmittelbar relevant.

Bridge-Risiko

Bridges konzentrieren Werte hinter einem einzigen Verifizierungsschritt, wie in DeFi-Grundbausteine erklärt. Ihre Ausfälle stehen ganz oben auf der Liste der größten Verluste.

Die Lehren sind einheitlich: Zählen Sie die unabhängigen Verifizierer und Unterzeichner, prüfen Sie, ob ihre Schlüssel tatsächlich getrennt sind (bei Ronin lagen die fünf Schlüssel bei nur zwei Organisationen), bestätigen Sie, dass Berechtigungen widerrufen werden, sobald sie nicht mehr benötigt werden, und berücksichtigen Sie bei jedem über eine Bridge übertragenen Token zusätzlich zum Risiko des Vermögenswerts auch das Risiko der Bridge.

Sanktionen und Compliance-Risiken

DeFi-Pools stehen allen offen, auch sanktionierten Parteien. Ermittler brachten nordkoreanische Gruppen mit den Angriffen auf Ronin, Drift und Kelp DAO in Verbindung. Gestohlene Gelder fließen häufig durch DEX-Pools, Bridges und Mixer. Für ein reguliertes Unternehmen entstehen dadurch Risiken, die es auf einer geprüften Handelsplattform nicht gibt:

• Gelder entgegenzunehmen, die auf eine Adresse der OFAC-Liste der Specially Designated Nationals (SDN) oder auf bekannte Erlöse aus Exploits zurückzuführen sind.
• Liquidität in einem Pool bereitzustellen, der zum Waschen gestohlener Vermögenswerte verwendet wird, oder Token zu halten, die ein Protokoll später einfriert.
• Eine Benutzeroberfläche oder ein Protokoll zu nutzen, das Sanktionen oder Durchsetzungsmaßnahmen unterliegt. Der Sanktionsfall Tornado Cash wird in der Lektion Marktintegrität, Sanktionen und Durchsetzung behandelt.

Zu den Kontrollen gehören das Screening von Gegenparteien und Pools mittels Blockchain-Analyse vor und nach jeder Interaktion, Wallet-Allowlisten, eine dokumentierte Risikoakzeptanz für jedes Protokoll sowie die in FATF-Standards und die Travel Rule beschriebenen Travel-Rule-Prozesse, wenn Übertragungen virtuelle Vermögensdienstleister betreffen.

Ein Bewertungsrahmen

Ein praktischer Ansatz zum Vergleich von Protokollen besteht darin, jede Risikokategorie mit 1 (stark) bis 5 (schwach) zu bewerten, die Kategorien zu gewichten und auf Grundlage des Ergebnisses Risikolimits festzulegen. Eine typische Struktur:

Gewichtete Bewertungen sollten mit harten Grenzen kombiniert werden, die keine Bewertung außer Kraft setzen kann (zum Beispiel ein Protokoll niemals zu nutzen, wenn sein Admin-Schlüssel zu einem einzelnen extern verwalteten Konto gehört oder Upgrades keinen Timelock haben), mit Konzentrationsgrenzen pro Protokoll und pro Chain sowie mit Überwachungsauslösern, die eine Überprüfung erzwingen: ein Governance-Vorschlag zur Änderung von Admin-Befugnissen, ein plötzlicher Abfluss von TVL, eine Entkopplung eines Sicherheiten-Token oder ein Exploit bei einem Protokoll, von dem das betrachtete Protokoll abhängt. Eine Bewertung ist eine Momentaufnahme; das DeFi-Risiko verändert sich mit jedem Upgrade und jeder Abstimmung.

Prüfungsschwerpunkt: Was ein Audit abdeckt und warum auditierter Code trotzdem versagen kann (Cetus, Mai 2025; Balancer V2, November 2025); Schutzmaßnahmen gegen Oracle-Manipulation und Risiken des wirtschaftlichen Designs; Proxys, Admin-Schlüssel, Multisig-Schwellen und Timelocks sowie die Verbindung von Social Engineering, vorab unterzeichneten Transaktionen und einem entfernten Timelock beim Drift-Angriff (April 2026); die Grundursachen der Bridge-Exploits bei Ronin, Wormhole und Kelp DAO; Sanktionsrisiken durch Interaktionen mit offenen Pools; und der Aufbau eines gewichteten Bewertungsrahmens mit harten Grenzen und Überwachungsauslösern.