Umfassende Post-Mortem des KelpDAO-Vorfalls: Aave wurde nicht gehackt – warum geriet es dann in eine Krise?
Umfassende Post-Mortem des KelpDAO-Vorfalls: Aave wurde nicht gehackt – warum geriet es dann in eine Krise?
Am 18. April 2026 entwickelte sich eine ungewöhnliche Transaktion von rund 116.500 rsETH zu einem realweltlichen Stresstest für die Risikoszenarien von DeFi. Die Kern-Smart Contracts von Aave waren nicht kompromittiert, dennoch befand sich das Protokoll im Zentrum eines Liquiditätsschocks und einem planerischen „Moment der Wahrheit“: Kann ein führender dezentraler Kreditmarkt widerstandsfähig bleiben, wenn die von ihm akzeptierten Sicherheiten extern – und schnell – beeinträchtigt werden? (governance.aave.com)
Dieser Artikel ist eine originäre, strukturierte Zusammenfassung, inspiriert von öffentlichen Offenlegungen und Diskussionen in der Community rund um den Vorfall (einschließlich Kommentaren unter der italienischen Schlagzeile „Come l’exploit di Kelp DAO su rsETH ha messo Aave davanti al suo ‘moment of truth’”). (governance.aave.com)
1) Die Akteure: KelpDAO, rsETH und warum DeFi betroffen war
rsETH wird üblicherweise als Liquid Restaking Token (LRT) diskutiert: ein Derivat, das ETH-basierte Ertragsstrategien in einem übertragbaren Vermögenswert bündelt – oft über Ketten hinweg mittels Bridging und Messaging-Schichten genutzt. Diese Komponierbarkeit macht rsETH attraktiv als Sicherheit wertvolle Sicherheiten... und verstärkt die Auswirkungen, wenn etwas schiefläuft. (finance.yahoo.com)
Aave ist aus einem einfachen Grund relevant: Als einer der größten Kreditmarktplätze in DeFi ist es der Ort, an dem Nutzer typischerweise ertragbringende Vermögenswerte hinterlegen, um liquide Token wie WETH und Stablecoins zu leihen. Dies schafft eine systemische Kopplung zwischen „Ertrags-Wrappern“ (LSTs / LRTs) und Märkten für „Basis-Liquidität“. (forbes.com)
2) Was am 18. April 2026 geschah: die entscheidende Zeitlinie
Schritt A: Ein Cross-Chain-Fehler erzeugte „verunreinigtes“ rsETH
Mehrere Berichte liefen auf denselben Kernpunkt hinaus: Der Vorfall ereignete sich außerhalb von Aave und war mit verdächtigen Cross-Chain-Aktivitäten im Zusammenhang mit rsETH und dessen Bridging-/Messaging-Pfad verbunden. Praktisch bedeutet dies, dass rsETH so erstellt oder freigegeben wurde, dass es nicht ordnungsgemäß gedeckt war (oder zumindest nicht mehr auf die gleiche Weise sicher einlösbar war wie zuvor). (support.token.im)
Mehrere Berichte deuteten auf einen gefälschten oder missbrauchten Nachrichtenpfad hin, der LayerZero EndpointV2-Mechanismen involvierte, was mit dem breiteren Risikoprofil von Cross-Chain-Verifizierung und Konfiguration übereinstimmt. (forbes.com)
Schritt B: Der Angreifer (oder der kontaminierte Fluss) erreichte Aave über die Sicherheiten
Sobald rsETH in großem Umfang bewegt werden konnte, war der Spielplan einfach: rsETH als Sicherheit bei Aave hinterlegen, dann reale Liquidität (insbesondere WETH) dagegen leihen – und damit das Risiko auf die Bilanz von Aave verlagern, falls die Sicherheit unverwertbar werden sollte. (forbes.com)
Schritt C: Aave reagierte – schnell – aber der Markt geriet trotzdem in Panik
Die Risikomanager von Aave reagierten schnell. Laut Aave-Governance-Mitteilungen wurde ab 18:52 Uhr UTC am 18. April 2026 der Aave Guardian eingefroren rsETH und wrsETH Märkte über alle Bereitstellungen hinweg, auf denen sie gelistet waren, und entsprechende Schutzmaßnahmen wurden auch auf Aave V4 angewendet. (governance.aave.com)
Kurz darauf beschrieben Aave-Governance-Updates auch zusätzliche Vorsichtsmaßnahmen, einschließlich des Einfrierens von WETH in mehreren Bereitstellungen, um eine weitere Eskalation zu begrenzen, während die Überwachung fortgesetzt wurde. (governance.aave.com)
Selbst mit dieser Reaktion waren die Sekundäreffekte unmittelbar: Spitzen bei der Auslastung, Benutzer, die zur Auszahlung drängten, und ein Narrativ-Umschwung, der das Vertrauen in DeFi-Kredite erschütterte. (forbes.com)
3) „Aave wurde nicht ausgenutzt“ – woher kam also die Krise?
Das ist die zentrale Erkenntnis: Ein Kreditprotokoll kann auf Smart-Contract-Ebene zahlungsfähig sein und dennoch auf der Sicherheiten-Ebene in eine Krise geraten.
Aaves Verträge taten, was sie tun sollten:
- genehmigte Sicherheiten akzeptieren,
- Kredite gemäß den konfigurierten Parametern ermöglichen,
- unterbesicherte Positionen liquidieren.
Wenn jedoch eine Sicherheit extern beeinträchtigt wird – weil ihre Brücken-, Minting-, Deckungs- oder Rücknahmeannahmen versagen – können Liquidationen die Zahlungsfähigkeit nicht wiederherstellen. So entstehen faule Schulden ohne jeden Fehler in Aave selbst. (forbes.com)
In mehreren öffentlich berichteten Schätzungen wurde die Lücke in einer breiten Spanne diskutiert (oft um die 177 Mio. – 200 Mio. US-Dollar), was widerspiegelt, wie schnell sich Positionen verschoben und wie schwierig es sein kann, beeinträchtigte Sicherheiten während eines aktiven Vorfalls zu bewerten. (forbes.com)
Übersetzung für Nutzer: „Blue-Chip“-Smart Contracts von DeFi eliminieren nicht das Asset-Risiko – insbesondere für überbrückte oder abgeleitete Sicherheiten.
4) Warum Bridges und Cross-Chain-Messaging weiterhin systemische Risiken darstellen
Cross-Chain-Systeme fügen nicht nur „eine weitere Abhängigkeit“ hinzu. Sie fügen eine andere Kategorie von Abhängigkeit hinzu: Konfiguration, Verifizierungskomitees, Nachrichtenbibliotheken, Ausführer und Sicherheitsschwellenwerte, die auf Arten versagen können, die Benutzer nicht einkalkulieren.
Die Dokumentation von LayerZero V2 hebt die Kernarchitektur hervor: Ein Endpoint ist der Ein-/Ausstiegspunkt, und die Zustellung ruft nach der Verifizierung schließlich lzReceive auf der Zielanwendung auf. Der Verifizierungsstapel stützt sich auf konfigurierte Regeln und außerbörsliche Akteure (z. B. DVNs / Ausführer), die sich wie angenommen verhalten. (docs.layerzero.network)
Die unbequeme Realität ist, dass viele DeFi-Nutzer Sicherheiten wie folgt bewerten:
- „Es ist ETH-bezogen“
- „Es generiert Ertrag“
- „Es ist auf großen Protokollen“
- „Es ist liquide“
...aber nicht so:
- „Wie viele unabhängige Prüfer sichern den Cross-Chain-Pfad?“
- „Was sind die Fehlermodi des Bridge-Adapters?“
- „Kann der Vermögenswert über verschiedene Ketten hinweg angehalten, auf die schwarze Liste gesetzt oder eingefroren werden?“
- „Verfügt das Protokoll über zuverlässige Proof-of-Reserve / Proof-of-Backing Haken?“
Diese Lücke in der Due Diligence von Benutzern (und manchmal Governance) ist der Grund, warum Vorfälle wie dieser systemisch und nicht isoliert werden. (governance.aave.com)
5) Der „Moment der Wahrheit“ für die Aave-Governance: Risikolisting statt Code-Risiko
Die Diskussion in der Aave-Community konzentrierte sich schnell auf harte Fragen, die über die Reaktion auf den Vorfall hinausgehen:
5.1 Sind LRTs als Sicherheiten geeignet – im großen Maßstab?
Liquid Restaking Tokens können produktive Vermögenswerte sein, aber sie sind auch gestapelte Risikoprodukte:
- Smart Contract Risiko,
- Oracle Risiko,
- Rücknahme-/Warteschlangenrisiko,
- Governance-Risiko,
- und oft Bridge-/Messaging-Risiko.
Wenn eine Schicht versagt, kann die Qualität der Sicherheiten schneller zusammenbrechen, als die Liquidationssysteme reagieren können. (governance.aave.com)
5.2 Sind Obergrenzen und Parameter konservativ genug?
Ein wiederkehrendes Thema im Aave-Governance-Thread war die Parametrisierung: Einzahlungsobergrenzen, Kreditvergabegrenzen, LTV, und ob die Governance bei der Aufnahme komplexer Vermögenswerte zu aggressiv vorgegangen ist. (governance.aave.com)
5.3 Können Menschen mit „Mempool-Geschwindigkeit“ reagieren?
Aaves Guardian und Sicherheitsprozesse haben zwar schnell gehandelt – aber die Debatte in der Community offenbarte immer noch die Lücke zwischen menschlicher Reaktionszeit und der Geschwindigkeit der gegnerischen Ausführung, was Ideen wie automatisierte Risikomanager, zeitgewichtete Kreditgrenzen oder Asset-spezifische Notabschaltungen, die ohne manuelle Koordination ausgelöst werden, motivierte. (governance.aave.com)
6) Kontext, der zählt: rsETH hatte bereits 2025 eine Vorwarnung
Dies war nicht das erste Mal, dass rsETH in den Risikokommunikationen von Aave auftauchte.
Am 30. April 2025 diskutierte die Aave-Governance ein vorsorgliches Einfrieren im Zusammenhang mit einem rsETH-Smart-Contract-Infrastrukturfehler, der zu unerwarteten Überzügen unter einem privilegierten Logikpfad führte. Aave erklärte, dass das Protokoll zu diesem Zeitpunkt nicht betroffen war, und beschrieb, wie Schutzlogiken (einschließlich Notabschaltungsverhalten bei Wechselkursaktualisierungen) halfen, breitere Schäden zu verhindern. (governance.aave.com)
Der Vorfall von 2026 unterschied sich in Form und Schweregrad, aber die gemeinsame Linie ist klar: Wenn Sicherheiten komplex sind, sind „Randfälle“ keine Randfälle – sie sind die Hauptrisikofläche. (governance.aave.com)
7) Was Benutzer mitnehmen sollten (praktisch, nicht theoretisch)
Wenn Sie auf DeFi-Geldmärkten leihen
- Betrachten Sie „hochwertige Sicherheitenlisten“ als Ausgangspunkt, nicht als Garantie.
- Verfolgen Sie Governance-/Risikokanäle auf Einfrierungen und Parameteränderungen (Aave Governance-Threads sind oft das schnellste offizielle Signal).
- Beobachten Sie die Auslastung und Auszahlungsbedingungen während eines Vorfalls; Liquidität kann auch ohne direkten Protokoll-Hack knapp werden. (governance.aave.com)
Wenn Sie gegen Ertrags-ETH-Derivate leihen
- Vermeiden Sie eine Überoptimierung des Hebels auf überbrückte Derivate; der Liquidationspfad kann brechen, wenn die Preisgestaltung oder die Einlösbarkeit der Sicherheiten versagt.
- Bevorzugen Sie Sicherheiten, deren Deckung unabhängig verifiziert werden kann und deren Fehlerquellen Sie verstehen. (support.token.im)
Wenn Sie LRTs / überbrückte Assets langfristig halten
- Trennen Sie „Marktrisiko“ von „Mechanismusrisiko“. Ertrag ist kein Ausgleich für unbekannte Cross-Chain-Annahmen.
- Fragen Sie: Wenn die Bridge pausiert, kann ich dann immer noch aussteigen? Wenn der Nachrichtenstapel angegriffen wird, was wird dann ungedeckt? (docs.layerzero.network)
8) Wo OneKey in dieses Gespräch passt (und wo nicht)
Eine Hardware-Wallet wird keine Kollaps der Sicherheiten stoppen oder faule Schulden auf einem Kreditmarkt verhindern. Aber sie adressiert eine andere Fehlerquelle, die während ereignisreicher Phasen der Volatilität ansteigt: die Sicherheit von Anwenderschlüsseln und die Sorgfalt bei Transaktionen.
Wenn Sie aktiv mit DeFi interagieren (einzahlen, leihen, Sicherheiten anpassen, Freigaben unterschreiben), kann die Verwendung von OneKey Ihnen helfen:
- private Schlüssel von potenziell kompromittierten Desktops/Browsern zu isolieren,
- Transaktionen auf einem dedizierten Gerät zu überprüfen und zu bestätigen,
- die Wahrscheinlichkeit zu verringern, dass aus panischen Aktionen irreversible Schlüsselverlustereignisse werden.
Das Schlüsselprinzip ist die Trennung von Zuständigkeiten: Risikomanagement von Protokollen ist Governance und Smart-Contract-Engineering; Self-Custody-Sicherheit ist operative Disziplin. In Wochen wie der des 18. April 2026 benötigen Sie beides.
Weiterführende Lektüre (autoritative Sprungbretter)
- Aave Governance: „rsETH incident — 2026-04-18“ (governance.aave.com)
- Aave Governance (historischer Kontext): „rsETH precautionary freezing 30/04/2025“ (governance.aave.com)
- LayerZero Docs (Architektur & Zustellungsmodell): LayerZero Protocol Architecture (V2) (docs.layerzero.network)
- LayerZero Docs (Integration und Empfangsfluss): Integration Checklist (EndpointV2 →
lzReceive) (docs.layerzero.network) - TVL und Marktkontext: Aave auf DeFiLlama (defillama.com)
- Umfassende Berichterstattung (Marktauswirkungen & Mechanik): Forbes-Berichterstattung über den Vorfall (forbes.com)
- Berichterstattung über Verhandlungen / Reaktionszeitplan: Yahoo Finance Zusammenfassung (finance.yahoo.com)
