Das Dezentralisierungsdilemma: Kaskadierendes Risiko und Notfallmacht in der KelpDAO-Krise

Am 18. April 2026 wurde die rsETH-Cross-Chain-Bridge von KelpDAO für rund 290 Millionen US-Dollar kompromittiert, was den größten DeFi-Sicherheitsvorfall des Jahres darstellt. Erste Attributionen deuten auf die Lazarus-Gruppe hin, einen staatlich unterstützten Akteur mit einer gut dokumentierten Geschichte der Angriffe auf Krypto-Infrastrukturen [1]. Der Angriff nutzte keine Schwachstelle in einem Smart Contract aus. Stattdessen wurde die RPC-Infrastruktur, die einen einzelnen Knoten des Decentralized Verifier Network (DVN) zugrunde liegt, vergiftet, wodurch gefälschte Cross-Chain-Nachrichten gesendet wurden, die rsETH-Token freigaben, ohne dass eine entsprechende Sperrung auf der Quellkette erfolgte.

Der Exploit selbst wurde von LayerZero [1] und KelpDAO [2] detailliert behandelt. Dieser Artikel verfolgt einen anderen Ansatz. Anstatt den Angriff nachzuerzählen, untersuchen wir, was nach dem Exploit geschah: wie eine einzige Infrastrukturabhängigkeit eine Kaskade ermöglichte, die Milliarden von Liquidität über fünf Ketten hinweg einfror, und wie diese Kaskade dezentrale Governance-Frameworks dazu zwang, zentralisierte Notfallbefugnisse vor aller Öffentlichkeit auszuüben.

Der Vorfall bei KelpDAO zeichnet eine kausale Kette nach, die drei Ebenen des "dezentralen" Stacks durchzieht: Eine einzelne DVN-Abhängigkeit machte den Exploit möglich; die Komponierbarkeit von DeFi (auch bekannt als "DeFi Lego"), die Eigenschaft, die es Protokollen ermöglicht, wie Bausteine miteinander verbunden zu werden, verwandelte diesen Brückenexploit dann in eine systemweite Liquiditätskrise; und das Ausmaß der Krise zwang wiederum die Governance-Frameworks, die darin eingebetteten zentralisierten Notfallbefugnisse offenzulegen.

Hintergrund: Der KelpDAO-Exploit im Überblick

KelpDAO ist der Emittent von rsETH, einem Liquid Restaking Token (LRT), der gestakte ETH-Positionen über mehrere Betreiber repräsentiert. Um die Cross-Chain-Bewegung von rsETH zu ermöglichen, integrierte sich KelpDAO in das Messaging-Protokoll von LayerZero, das auf DVN (Decentralized Verifier Networks) angewiesen ist – unabhängige Prüfer, die bestätigen, dass Cross-Chain-Nachrichten legitim sind, bevor sie auf der Zielkette ausgeführt werden.

Die kritische Konfigurationswahl: Die rsETH OApp von KelpDAO verwendete ein 1-von-1 DVN-Setup, wobei das von LayerZero Labs betriebene DVN der einzige Prüfer war. Das bedeutete, dass die gesamte Cross-Chain-Sicherheit von rsETH von einer einzigen Verifizierungseinheit abhing. Die Integrationsdokumentation von LayerZero empfiehlt ausdrücklich Multi-DVN-Konfigurationen mit Redundanz, und LayerZero gibt an, KelpDAO vor dem Vorfall über diese Best Practice informiert zu haben [1]. KelpDAO seinerseits beharrt darauf, dass das 1/1-Setup "die in der LayerZero-Dokumentation dokumentierte Konfiguration war und als Standard für jede neue OFT-Bereitstellung ausgeliefert wurde" und dass "Standards während ihrer L2-Expansion als angemessen bestätigt wurden" [2].

Die Angreifer kompromittierten zwei RPC-Knoten, die vom LayerZero Labs DVN verwendet wurden, und ersetzten deren Binärdateien durch bösartige Versionen, die gefälschte Chain-State-Daten ausschließlich an die IP-Adresse des DVN zurückgaben, während sie für alle anderen Beobachter, einschließlich der eigenen Überwachungsinfrastruktur von LayerZero, normal erschienen. Ein gleichzeitiger DDoS-Angriff auf unkompromittierte RPC-Knoten zwang zu einem Failover auf die vergifteten Knoten. Das Ergebnis: Das DVN bestätigte eine Cross-Chain-Nachricht, die auf der Quellkette nie stattgefunden hatte, und gab 116.500 rsETH aus dem Ethereum-seitigen Adapter (0x85d4...8ef3) frei, ohne eine entsprechende Sperrung auf der Quellseite [1, 3]. Die Freigabetransaktion ist 0x1ae232...db4222. Die On-Chain-Beweise sind eindeutig: Der Ethereum-Zielendpunkt akzeptierte die Nonce 308, während der Unichain-Quellendpunkt immer noch eine maximale ausgehende Nonce von 307 meldet [10].

KelpDAO entdeckte die Anomalie und pausierte alle relevanten Verträge innerhalb von 46 Minuten. Diese Intervention blockierte einen anschließenden Versuch, weitere 40.000 rsETH (~95 Mio. $) ins Visier zu nehmen [2]. Zu diesem Zeitpunkt hatte der Angreifer jedoch bereits die nächste Phase eingeleitet: die Umwandlung gestohlener rsETH in geliehene Vermögenswerte über DeFi-Kreditprotokolle.

Von gefälschten Token zu geliehenen Vermögenswerten

Der Angreifer verkaufte die gestohlenen rsETH nicht einfach. Die 116.500 Token wurden auf sieben Zweig-Wallets verteilt und über mehrere Kanäle monetarisiert, darunter direkte Swaps zu ETH über Aggregatoren, Compound V3-Anlagepositionen und erneutes Bridging nach Arbitrum [10]. Der folgenreichste Weg führte jedoch über Aave: Der Angreifer hinterlegte 89.567 rsETH (ca. 221 Mio. $) in Aave-Kreditmärkten auf zwei Ketten: Ethereum Core und Arbitrum. Unter Nutzung des E-Mode von Aave, einer Funktion zur Kapitaleffizienz, die höhere Kredit-zu-Wert-Verhältnisse für korrelierte Vermögenswerte ermöglicht, lieh sich der Angreifer 82.620 WETH und 821 wstETH gegen die hinterlegten rsETH [3].

Die Positionen waren maximal gehebelt. Die Gesundheitsfaktoren über die sieben Adressen des Angreifers reichten von 1,01 bis 1,03, kaum über der Liquidationsschwelle [3]. Dies war möglich, da Aaves E-Mode LTV für rsETH bei 93 % lag, mit einer Liquidationsschwelle von 95 %, was einen Sicherheitsspielraum von nur 2 Prozentpunkten ließ.

Die Aufschlüsselung nach Adresse auf beiden Märkten:

Quelle: On-Chain-Daten aggregiert von Etherscan, Arbiscan und DeBank mit Stand vom 22.04.2026, 16:51 UTC. USD-Werte spiegeln die Token-Preise zum Zeitpunkt jeder Transaktion wider.

Die Kaskade: Wie ein Brückenexploit WETH über fünf Ketten hinweg einfror

Die folgende Abbildung fasst die gesamte Kaskade zusammen. Die Schritte 1 und 2 (Brückenexploit und Aave-Kollateralhinterlegung) werden im obigen Hintergrundabschnitt behandelt. Der Rest dieses Abschnitts untersucht die Schritte 3 bis 5 im Detail: warum WETH eingefroren werden musste, welche Parameter die Schwere der Kaskade bestimmten und was das Einfrieren tatsächlich kostete.

Warum WETH eingefroren werden musste

Am 19. April fror der Protocol Guardian von Aave alle rsETH- und wrsETH-Märkte über Aave V3 und V4 ein, was neue Einlagen und Kredite gegen rsETH-Kollateral verhinderte [8]. Dies war die erwartete erste Reaktion.

Der unerwartete zweite Schritt erfolgte am 20. April: Aave fror WETH-Reserven auf Ethereum, Arbitrum, Base, Mantle und Linea ein [3, 8].

Warum WETH einfrieren, einen Vermögenswert, der nicht kompromittiert wurde und nichts mit Cross-Chain-Brücken zu tun hat? Weil der Angreifer rsETH hinterlegt hatte, das ohne entsprechende Quellketten-Deckung geprägt wurde. Aaves Orakel bewertete diese Token weiterhin zum vollen Marktwert und behandelte sie als legitimes Kollateral, das von ordnungsgemäß gebrücktem rsETH nicht zu unterscheiden war. Der Angreifer nutzte diese Informationsasymmetrie aus, um echtes WETH gegen Kollateral zu leihen, das auf Systemebene ungedeckte Verbindlichkeiten darstellte. Dies leerte die Kreditpools an WETH und trieb die Auslastung in den betroffenen Märkten auf 100 %. Bei voller Auslastung können bestehende WETH-Einleger keine Auszahlungen mehr vornehmen, und Liquidatoren können nicht die zugrunde liegende Anlage erhalten, die zur Ausführung von Liquidationen erforderlich ist. Der Liquidationsmechanismus, die primäre Verteidigung des Protokolls gegen schlechte Schulden, war effektiv paralysiert [3].

Wenn die WETH-Kreditvergabe geöffnet geblieben wäre, könnten die verbleibenden Pool-Liquiditäten auf anderen Ketten über denselben Mechanismus geleert werden: rsETH hinterlegen, WETH leihen, abhauen. Das Einfrieren von WETH war keine Option. Es war der einzige Weg, den Schaden zu begrenzen.

Drei Parameter, die die Kaskade prägten

Die Schwere dieser Kaskade war kein Zufall. Drei Protokollparameter bestimmten sowohl den direkten Schaden als auch den Umfang des daraus resultierenden Einfrierens.

1. LTV: Wie viel gesunde Vermögenswerte jede Einheit kontaminierten Kollaterals extrahieren kann

Der E-Mode LTV von Aave für rsETH lag bei 93 %, was bedeutet, dass für jeden hinterlegten Dollar kontaminierten rsETH 0,93 $ WETH geliehen werden konnten. Zum Vergleich: Spark Protocol setzte den rsETH LTV im gleichen Zeitraum auf 72 % und Fluid auf etwa 75 % [3]. Der Parameter von Aave war der aggressivste auf dem Markt.

Dies war eine bewusste Designentscheidung, kein Versehen. Im Januar 2026 erhöhte die Aave-Governance den E-Mode LTV für rsETH von 92,5 % auf 93 % und verringerte damit den ohnehin schon dünnen Sicherheitsspielraum von 2,5 % auf 2 % [3]. Der Basis-LTV (nicht E-Mode) wurde bewusst nahe Null (0,05 %) angesetzt, was alle signifikanten rsETH-Kreditnahmen praktisch durch den E-Mode-Pfad mit hohem LTV erzwang.

2. Pool-Tiefe: Wie anfällig jeder Markt für Liquiditätsabfluss ist

Der gleiche Dollarbetrag an Kreditaufnahme hat unterschiedliche Auswirkungen, je nach Tiefe des Zielpools.

Der Angreifer hinterlegte rsETH nur in Aave V3-Märkten. Aave V4 (nur Ethereum, gestartet am 30.03.2026) war ebenfalls vom präventiven rsETH-Einfrieren betroffen [8], ist aber in dieser Tabelle nicht enthalten. WETH-Reservendaten von LlamaRisk [3]; Angreifer-Kreditaufnahme abgeleitet aus der obigen Aufschlüsselung nach Adresse.

Der Angreifer konzentrierte die Kreditaufnahme auf Ethereum Core und Arbitrum. Entscheidend ist jedoch, was mit Ketten geschah, die der Angreifer nie berührt hat. Da rsETH auf Mantle, Base und Linea als Kollateral akzeptiert wurde, trugen alle bestehenden Benutzerpositionen, die durch rsETH auf diesen Ketten gesichert waren, ein latentes Risiko von schlechten Schulden, sobald die zugrunde liegende Brückenabsicherung kompromittiert war. Aaves Entscheidung, WETH präventiv auf allen fünf Ketten einzufrieren, war eine rationale Reaktion: Offenlassen dieser Märkte hätte sie demselben Abflussmechanismus ausgesetzt, den der Angreifer bereits auf Ethereum und Arbitrum demonstriert hatte [3, 8].

3. Anzahl der Cross-Chain-Bereitstellungen: Wie weit sich das Einfrieren ausbreitet

rsETH war auf 11 von 23 Aave V3-Märkten als Kollateral gelistet, wobei 7 davon eine materielle Exposition zeigten [3]. Der Angreifer operierte nur auf 2 Ketten. Das präventive WETH-Einfrieren betraf jedoch mindestens 5 Ketten, darunter Märkte, auf denen der Angreifer keinen einzigen Token hinterlegt hatte. Der LTV bestimmt, wie viel pro Kette extrahiert wird; die Pool-Tiefe bestimmt, wie stark jeder Markt belastet wird. Aber die Anzahl der Ketten, auf denen rsETH als Kollateral akzeptiert wurde, entschied letztlich, wie weit sich das Einfrieren ausbreitete.

Diese Parameter sind nicht statisch. Neun Tage vor dem Exploit, am 9. April, erhöhte Aaves Risk Steward die rsETH-Angebotsgrenzen: Ethereum Core von 480.000 auf 530.000 und Mantle von 52.000 auf 70.000 [3]. Auch wenn dies keine Kausalität impliziert (die Vorbereitungszeitlinie des Angreifers liegt wahrscheinlich vor diesen Änderungen), unterstreicht es, wie routinemäßige Parameteranpassungen unbeabsichtigt den Wirkungsbereich eines zukünftigen Vorfalls erweitern können.

Die tatsächlichen Auswirkungen des Einfrierens

Das Ergebnis: Ein Brückenexploit von 290 Mio. $ führte zu WETH-Liquiditätseinfrierungen auf fünf Ketten, die Märkte mit Gesamtreserven von über 6,7 Milliarden Dollar betrafen.

Die direkten Verluste beschränkten sich auf die Kreditaufnahme des Angreifers. Aber im DeFi-Kreditwesen ist ein Einfrieren keine geringfügige Betriebsbehinderung. Es sperrt Benutzerliquidität, verhindert Auszahlungen, stört aktive Positionen und beeinträchtigt die Liquidationsmechanismen, die das Protokoll vor schlechten Schulden schützen. Die überwiegende Mehrheit der betroffenen Nutzer hatte nie mit rsETH, KelpDAO oder einer Cross-Chain-Bridge interagiert. Sie waren WETH-Einleger und -Kreditnehmer auf Aave, Teilnehmer an dem, was sie vernünftigerweise als unkomplizierten Kreditmarkt verstanden.

WETH ist der grundlegendste Liquiditätswert in DeFi. Das Einfrieren von WETH ist gleichbedeutend mit der Sperrung von Auszahlungen bei der größten Bank der Stadt, weil eine andere Finanzinstitution, die ein Produkt verwendet, von dem die meisten Einleger noch nie gehört haben, betrogen wurde.

Der Vorfallbericht von LlamaRisk [3] modellierte zwei Szenarien mit schlechten Schulden und prognostizierte die Kosten pro Kette und lieferte damit die detaillierteste verfügbare Analyse der Risikoverbreitung. Aber selbst diese Analyse konzentrierte sich auf potenzielle schlechte Schulden, nicht auf die breiteren Betriebskosten des Einfrierens selbst, einschließlich gesperrter Auszahlungen, gestörter Positionen und beeinträchtigter Liquidationskapazität auf allen betroffenen Märkten. Eine umfassende Quantifizierung der gesamten kaskadierenden Auswirkungen bleibt eine offene Frage.

Wenn die Angriffskaskade komplex war, hat sich die Wiederherstellung nicht als einfacher erwiesen. Die Komponierbarkeit schränkt die Reparatur ebenso ein wie sie den Schaden ermöglicht. Aave konnte nicht einfach "alles wieder einfrieren". Jeder Markt musste unabhängig bewertet werden, mit unterschiedlichen Risikoprofilen je nach lokaler rsETH-Exposition, WETH-Auslastungsgrad und Angreiferaktivität. Die Zeitlinie erzählt die Geschichte:

• 19. April: Der Protocol Guardian fror alle rsETH- und wrsETH-Reserven auf Aave V3 und V4 ein [8].
• 20. April: WETH wurde auf Ethereum, Arbitrum, Base, Mantle und Linea eingefroren [3, 8].
• 21. April: WETH wurde nur auf Ethereum Core V3 wieder freigegeben, wobei der LTV aus Vorsichtsgründen bei 0 blieb. WETH auf Ethereum Prime, Arbitrum, Base, Mantle und Linea blieb eingefroren [8].

Vier Tage nach dem Exploit sind fünf von sechs betroffenen Märkten immer noch eingefroren. Der Wiederherstellungsweg spiegelt die Komplexität des Angriffspfades wider: von Protokoll zu Protokoll, von Kette zu Kette, wobei jeder Schritt Governance-Koordination und Risikobewertung erfordert.

Die Reaktion: Wie Arbitrum 30.766 ETH ohne Unterschrift bewegte

Während Aave die Kreditkaskade verwaltete, entfaltete sich auf Arbitrum eine parallele Reaktion. Am 21. April kündigte der Arbitrum Security Council an, Notfallmaßnahmen ergriffen zu haben, um 30.766 ETH des Angreifers auf Arbitrum One einzufrieren [6]. Die Gelder wurden auf eine zwischenzeitlich eingefrorene Adresse (0x...0DA0) transferiert, die nur durch spätere Arbitrum-Governance-Maßnahmen zugänglich ist [7].

Die Governance-Maßnahme

Das Arbitrum Security Council ist eine formale Komponente der Governance-Struktur von Arbitrums DAO, kein externer Akteur oder Ad-hoc-Ausschuss. Die Notfallmaßnahme wurde öffentlich über das Arbitrum Governance Forum angekündigt [7], unter Einbeziehung von Strafverfolgungsbehörden bezüglich der Identität des Angreifers [6] und mit vollständigen Transaktionsdetails dokumentiert. Der Sicherheitsrat handelte im Rahmen seines etablierten Mandats und wog "seinen Einsatz für die Sicherheit und Integrität der Arbitrum-Gemeinschaft, ohne die Auswirkungen auf Arbitrum-Nutzer oder -Anwendungen zu beeinträchtigen" [6].

Dies war keine Hinterzimmerentscheidung. Es war eine von der Governance sanktionierte Notfallmaßnahme, transparent ausgeführt und mit On-Chain-Beweisen für jedermann überprüfbar.

Der technische Mechanismus

Was diese Maßnahme bemerkenswert macht, ist nicht die Governance-Entscheidung, sondern wie sie On-Chain umgesetzt wurde. Basierend auf der Phalcon-Trace-Analyse von BlockSec [9] setzte der Arbitrum Security Council einen atomaren Dreischritt-Ansatz ein:

1. Der Upgrade Executor aktualisierte vorübergehend den Ethereum Inbox Contract (DelayedInbox) und fügte eine neue Funktion namens sendUnsignedTransactionOverride hinzu.

2. Diese Funktion wurde verwendet, um eine Cross-Chain-Nachricht zu erstellen, die die Adresse des Angreifers nachahmte. Die Nachricht wurde über Bridge.enqueueDelayedMessage mit kind=3 injiziert, was im Arbitrum Nitro Stack der L1MessageType_L2Message entspricht. Dieser Nachrichtentyp ermöglicht die Ausführung von L2MessageKind_UnsignedUserTx auf L2. Entscheidend ist, dass dieser Pfad keine Signaturprüfung erfordert. Der Senderparameter wurde vom Standardpfad msg.sender auf eine vom Aufrufer kontrollierte Eingabe verschoben und durch L1→L2-Adressaliasing transformiert, um den Kontext der Angreiferadresse zu tragen.

3. Nach der Ausführung des Transfers auf L2 wurde der Inbox Contract auf seine ursprüngliche Implementierung zurückgesetzt.

Die L1-Transaktion [4] und die resultierende L2-Transaktion [5] sind beide öffentlich im Phalcon Explorer einsehbar. Was die L2-Transaktion als "vom Angreifer an 0x...0DA0" anzeigt, ist keine normale, vom Benutzer signierte Überweisung. Es handelt sich um einen erzwungenen Zustandsübergang auf Chain-Ebene, eine Transaktion, die Vermögenswerte ohne den privaten Schlüssel des Eigentümers verschoben hat und über Governance-Infrastruktur-Upgrade-Befugnisse ausgeführt wurde.

Das Dilemma

Der Mechanismus ist im Prinzip einfach: upgradefähige Verträge gewähren unbegrenzte Möglichkeiten. Wenn ein Vertrag aktualisiert werden kann, kann sein Verhalten geändert werden, um alles zu tun, einschließlich der Übertragung von Vermögenswerten ohne die Signatur des Inhabers. Diese Fähigkeit ist inhärent in jedem System, das auf upgradefähigen Verträgen basiert. Die 30.766 ETH befinden sich nun in einer eingefrorenen Adresse. Nur eine spätere Arbitrum-Governance-Abstimmung kann über ihre Verfügung entscheiden. Das atomare Upgrade-Execute-Restore-Muster hinterließ keine dauerhafte Änderung am Inbox Contract, und keine anderen Benutzer oder Anwendungen waren betroffen [6].

Die Maßnahme des Arbitrum Security Council war nach den meisten vernünftigen Einschätzungen die richtige Entscheidung. Der Angreifer wurde als staatlich unterstützter Akteur identifiziert. Strafverfolgungsbehörden waren beteiligt. Der Governance-Prozess war öffentlich. Und 71 Millionen US-Dollar an gestohlenen Vermögenswerten wurden zurückgewonnen oder zumindest daran gehindert, weiter gewaschen zu werden.

Die Fähigkeit, die dies ermöglichte, geht jedoch über diesen speziellen Fall hinaus. Derselbe Upgrade-Execute-Restore-Mechanismus könnte im Prinzip verwendet werden, um jedes von einer beliebigen Adresse auf Arbitrum One gehaltene Vermögen zu verschieben. Die Befugnis des Security Council ist nicht auf Angreiferadressen oder gestohlene Gelder beschränkt. Es handelt sich um eine Allzweckfunktion, die durch Governance-Normen und nicht durch Code eingeschränkt ist.

Das ist das Dilemma. Nutzer interagieren mit L2s unter einem impliziten mentalen Modell: "Meine Vermögenswerte werden von meinem privaten Schlüssel kontrolliert und niemand kann sie ohne meine Unterschrift bewegen." Die KelpDAO-Reaktion zeigt, dass dieses Modell unvollständig ist. Auf Arbitrum und auf jedem L2 mit upgradefähigen Brückenverträgen und einem Security Council können Vermögenswerte durch Governance-Ebene-Maßnahmen bewegt werden, die Signaturprüfungen vollständig umgehen.

Arbitrum ist hierin nicht einzigartig. Die Markteinfrierungen von Aave sind ebenfalls Governance-gesteuerte Notfallmaßnahmen. Während des KelpDAO-Vorfalls übten mehrere Protokolle gleichzeitig zentralisierte Notfallbefugnisse aus: Aave fror Märkte auf fünf Ketten ein, Arbitrums Security Council führte eine erzwungene Überweisung durch und KelpDAO pausierte Verträge global. Die Krisenreaktion des "dezentralen" Ökosystems war praktisch eine koordinierte Ausübung zentralisierter Autorität.

Die Frage ist nicht, ob Notfallbefugnisse existieren sollten. Der Fall KelpDAO liefert ein überzeugendes Argument dafür, dass sie es sollten. Die Frage ist, ob die Grenzen, Auslösebedingungen und Rechenschaftsmechanismen für diese Befugnisse ausreichend transparent sind. Nutzer, die Vermögenswerte auf einem L2 hinterlegen, sollten eine einfache Frage beantworten können: Unter welchen Umständen kann das Security Council meine Gelder bewegen und welche Rechtsmittel habe ich?

Aktueller Status der gestohlenen Gelder

Unabhängige On-Chain-Nachverfolgung (vollständige Visualisierung auf MetaSleuth [11]) zeigt, wie der Angreifer die 116.500 rsETH auf sieben Adressen der ersten Ebene verteilt, den Großteil davon als Kollateral auf Aave (Ethereum Core und Arbitrum) hinterlegt, um WETH und wstETH zu leihen, und die Erlöse auf beiden Ketten in einer gemeinsamen Adresse 0x5d39...7ccc konsolidiert (Ethereum / Arbitrum). Mit Stand vom 22.04.2026, 05:42 UTC, befinden sich die gestohlenen Gelder in vier verschiedenen Zuständen:

Etwa 31 % der Erlöse sind eingefroren oder abgefangen, 23 % verbleiben inaktiv auf einer einzigen ruhenden Ethereum-Adresse und 46 % wurden über 103 First-Hop-Adressen verteilt oder werden derzeit verteilt. rsETH, das als Aave-Kollateral hinterlegt wurde, bleibt eingezahlt, und das geliehene WETH und wstETH wurden nicht zurückgezahlt – der Angreifer hat die Kreditposition aufgegeben.

Fazit

Der Vorfall bei KelpDAO zeichnet eine kausale Kette nach, die drei Ebenen des "dezentralen" Stacks durchzieht.

Es begann mit einer einzigen Abhängigkeit. KelpDAOs 1-von-1 DVN-Konfiguration reduzierte die Cross-Chain-Verifizierung auf eine einzige Entität, wodurch die gesamte Brücke über eine kompromittierte Infrastrukturkomponente ausnutzbar wurde. Die Architektur unterstützte die Dezentralisierung; die Konfiguration tat es nicht.

Die Komponierbarkeit verwandelte dann einen Brückenexploit in eine systemweite Liquiditätskrise. Ein einziger Angriff frierte WETH, den grundlegendsten Vermögenswert von DeFi, über fünf Ketten ein und beeinträchtigte Milliarden von Liquidität, die von Nutzern gehalten wurde, die keinerlei Verbindung zu rsETH oder KelpDAO hatten. Die Reichweite der Kaskade wurde durch messbare Parameter geprägt: aggressive LTV-Einstellungen, geringe Liquiditätspools und breite Cross-Chain-Kollateraleinsätze.

Das Ausmaß der Krise zwang wiederum die dezentrale Governance dazu, zentralisierte Notfallbefugnisse auszuüben. Das Arbitrum Security Council bewegte 30.766 ETH ohne Unterschrift des Inhabers durch ein von der Governance sanktioniertes atomares Vertragsupgrade. Aave fror Märkte über mehrere Ketten hinweg durch Governance-gesteuerte Notfallmaßnahmen ein. Die Reaktion war effektiv, transparent und wohl notwendig. Sie war auch ein Beweis dafür, dass "erlaubnisfrei" praktische Grenzen hat.

Die Einzelpunktabhängigkeit ermöglichte den Exploit; die Komponierbarkeit verstärkte den Schaden; der Schaden enthüllte die zentralisierte Macht, die immer vorhanden war, eingebettet in upgradefähige Verträge und Governance-Frameworks. Die Bewältigung dieser verbundenen Dynamiken erfordert Maßnahmen von allen Beteiligten:

Für Protokolle: Die Gesamtsicherheit eines Protokolls wird durch sein schwächstes Glied bestimmt, das in diesem Fall die DVN-Infrastruktur und nicht die Smart Contracts war [10]. Effektive Sicherheit erfordert systematische Abdeckung über mehrere Dimensionen hinweg, einschließlich Code-Sicherheit, Infrastruktur-Sicherheit, Schlüsselverwaltung und Betriebssicherheit. Umfassende Bewertungen und Penetrationstests sollten den gesamten Stack testen, nicht einzelne Komponenten isoliert. On-Chain-Überwachung ermöglicht Notfallreaktionen innerhalb von Minuten statt Stunden, und eine schnelle Cross-Chain-Geldverfolgung ist unerlässlich für die Koordinierung von Einfrierungen und die Maximierung der Wiederherstellung. Für Kreditprotokolle im Besonderen sollten Kollateralien aus Cross-Chain-Synthetik-Assets gegen ein "Total Collateral Compromise"-Szenario anhand der drei oben diskutierten Parameter getestet werden: LTV, Pool-Tiefe und Anzahl der Cross-Chain-Bereitstellungen.

Für L2-Governance und DAOs: Notfallbefugnisse sollten transparent und rechenschaftspflichtig sein. Die meisten großen L2s verfügen bereits über diese Möglichkeiten, aber sie sind oft in technischer Dokumentation vergraben, anstatt in benutzersichtbaren Materialien. Governance-Frameworks sollten Auslösebedingungen, Umfangsbeschränkungen, Zeitlimits und Anforderungen an die Rechenschaftspflicht nach der Maßnahme kodifizieren.

Für Benutzer: Verstehen Sie das systemische Risiko, das der DeFi-Komponierbarkeit innewohnt. In diesem Vorfall wurden WETH-Einleger, die rsETH nie berührt hatten, ihre Liquidität über fünf Ketten hinweg eingefroren gesehen. Das Risiko einzelner Positionen ist nur ein Teil des Gesamtbildes; die Protokolle, Pools, Kollateraltypen und Ketten, mit denen Ihre Vermögenswerte interagieren, bilden alle eine vernetzte Risikooberfläche.

Referenzen

[1] LayerZero Core, "KelpDAO Incident Statement": https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context": https://x.com/KelpDAO/status/2046332070277091807

[3] LlamaRisk, "rsETH Incident Report" (20. April 2026): https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[4] BlockSec Phalcon Explorer, L1 Transaction (Arbitrum Security Council Action): https://app.blocksec.com/phalcon/explorer/tx/eth/0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770

[5] BlockSec Phalcon Explorer, L2 Transaction (Arbitrum Forced Transfer): https://app.blocksec.com/phalcon/explorer/tx/arbitrum/0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b

[6] Arbitrum, "Security Council Emergency Action": https://x.com/arbitrum/status/2046435443680346189

[7] Arbitrum Governance Forum, "Security Council Emergency Action 21/04/2026": https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803

[8] Aave, rsETH Incident Updates (19.-21. April 2026): https://x.com/aave/status/2045593585966252377

[9] BlockSec Phalcon, "Arbitrum Security Council Freeze Analysis": https://x.com/Phalcon_xyz/status/2046467830498173088

[10] banteg, "Kelp rsETH Unichain → Ethereum Path Investigation": https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62

[11] MetaSleuth, KelpDAO Exploit Trace: https://metasleuth.io/result/eth/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222?source=600c61cd-f0cd-4dff-8687-14e02f6ccd24