Am 10. März führte eine technische Fehlkonfiguration in der Aave-Oracle-Infrastruktur zu Zwangsliquidationen und stellte die Abhängigkeit von DeFi vom automatisierten Risikomanagement auf die Probe.
Das 21,7-Millionen-Dollar-Liquidationsereignis auf Aave
Aave-Nutzer erlitten am 10. März Liquidationen in Höhe von etwa 21,7 Millionen US-Dollar, nachdem eine On-Chain-Beschränkung im Wrapped stETH (wstETH)-Risiko-Agent dazu führte, dass Kollateralwerte zu niedrig angesetzt wurden. Insgesamt wurden 34 Konten liquidiert, weil das Protokoll wstETH etwa 2,85 % unter seinem tatsächlichen Marktpreis bewertete.
Das Protokoll erlitt letztendlich keine uneinbringlichen Schulden und entschädigte betroffene Nutzer. Das Ereignis legte jedoch strukturelle Schwachstellen offen, wie automatisiertes Risikomanagement im DeFi (Dezentralisierte Finanzen)-Bereich Änderungen ohne menschliches Eingreifen ausführt. Es zeigte auch, wie schnell ein falsch konfigurierter Parameter zu groß angelegten Liquidationen ansonsten gesunder Positionen führen kann.
Laut Daten nach dem Vorfall erschienen Nutzer, die wstETH als Sicherheiten gegen WETH-Schulden hielten, nur aufgrund der falschen Bewertung unterbesichert. Darüber hinaus wären ihre Positionen zu tatsächlichen Marktpreisen sicher geblieben, was unterstreicht, dass der Fehler infrastrukturell und nicht marktgetrieben war.
Die Mechanik des CAPO-Fehlers
Der Vorfall hatte seinen Ursprung in Aaves CAPO (Correlated Asset Price Oracle)-System, das entwickelt wurde, um vor Manipulation von Vermögenswerten mit korrelierten Preisen wie wstETH und stETH zu schützen. CAPO ruft das wstETH/stETH-Verhältnis von Lido ab, wendet eine Schutzgrenze durch den WstETHPriceCapAdapter an und multipliziert dann das Ergebnis mit dem ETH-Preis, um eine USD-Bewertung zu erhalten.
Um 12:47 UTC am 10. März empfahl Chaos Labs' Off-Chain-Edge Risk-Engine, den CAPO-Höchstpreis auf 1,1933947 wstETH/ETH zu aktualisieren. In diesem Moment lag das tatsächliche Marktverhältnis bei 1,2285, was bedeutete, dass die vorgeschlagene Obergrenze bereits deutlich unter den vorherrschenden Preisen lag.
BGDs AgentHub führte diese Empfehlung einen Block später über sein Oracle Automation-System aus, ohne Prüfungspuffer zwischen der Off-Chain-Empfehlung und der On-Chain-Implementierung. Das heißt, diese sofortige Pipeline ist genau das, was einen Konfigurationsfehler in ein unmittelbar nutzerwirksames Ereignis verwandelte.
Die resultierende 2,85 %-Fehlausrichtung führte dazu, dass das Protokoll wstETH-Kollateralwerte unterbewertete. Infolgedessen wurden Konten, die laut echten Marktdaten sicher hätten sein sollen, als unterbesichert gekennzeichnet und liquidiert. Die Kaskade verarbeitete 10.938 wstETH über 34 Konten und generierte etwa 512 ETH an Liquidationsboni für Liquidatoren, bevor das Problem erkannt und rückgängig gemacht wurde.
Technische Grundursache: Snapshot-Fehlanpassung
Der technische Fehler stammte von einer Parameterinkongruenz zwischen snapshotRatio und snapshotTimestamp innerhalb von CAPO. Chaos Labs' Off-Chain-Risiko-Agent berechnete ein Zielverhältnis von etwa 1,2282, verankert an einem 7 Tage alten Snapshot. Das On-Chain-System begrenzte jedoch, wie schnell sich das Verhältnis bewegen konnte.
Unter den Schutzregeln von CAPO konnte der vorherige On-Chain-Wert von etwa 1,1572 nur alle 3 Tage um 3 % steigen. In der Praxis bedeutete dies, dass das Verhältnis bei einer einzelnen Aktualisierung nur auf etwa 1,1919 steigen konnte, selbst wenn das Off-Chain-Ziel höher gedriftet war. Darüber hinaus glich die Aktualisierung diese Beschränkungen nicht mit der Zeitstempel-Logik ab.
Der snapshotTimestamp wurde so eingestellt, als ob der On-Chain-Anker bereits das 7 Tage alte Off-Chain-Verhältnis von 1,2282 widerspiegelte. Dies schuf eine kritische Inkonsistenz zwischen Zeit- und Preisreferenzen. Folglich berechnete CAPO einen maximalen Wechselkurs von etwa 1,1939, etwa 2,85 % unter dem wahren Marktkurs von 1,2285.
Dieser Vorfall markierte die erste automatisierte Aktualisierung, die seit seiner Bereitstellung von Chaos Labs' CAPO-Risiko-Agent On-Chain durchgeführt wurde. Das heißt, die Tatsache, dass die erste Ausführung Nutzerliquidationen hervorbrachte, machte die Fehlkonfiguration sowohl für die Governance als auch für die Nutzer besonders alarmierend.
Die automatisierte Ausführungskette von Edge Risk zu AgentHub
Edge Risk ist Chaos Labs' proprietäre Off-Chain-Risiko-Engine, die Parameteränderungen von einer festgelegten Adresse vorbereitet und pusht. AgentHub, entwickelt von BGD, hört auf diese Änderungen mittels Oracle Automation und propagiert sie dann an das Protokoll.
Die fehlerhafte Parameteränderung bewegte sich durch Chaos Labs' automatisierten Risiko-Stack in einer Zwei-Transaktions-Sequenz. Zunächst empfahl die Edge Risk-Engine, die Obergrenze in Transaktion 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95 auf 1,191926 wstETH/ETH zu ändern. Dann führte AgentHub die Änderung einen Block später über Transaktion 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e aus.
Tägliche Liquidationen auf Aave waren im Februar relativ bescheiden und überstiegen selten 5 Millionen US-Dollar, da die Marktbedingungen stabil blieben. Der Anstieg am 10. März auf 21,6 Millionen US-Dollar sticht als isolierter Ausreißer hervor, etwa ein 4-facher Sprung von typischen Niveaus. Darüber hinaus kehrten die Liquidationsvolumina nach der Korrektur schnell zur Basislinie zurück, was bestätigte, dass der Stress vom Oracle-Pfad kam und nicht von einer umfassenderen Protokollinsolvenz.
Dieses Verhalten verstärkte die Schlussfolgerung, dass das wstETH-Preisproblem ein diskreter Konfigurationsfehler war. Es war kein Symptom für sich verschlechternde Sicherheitenqualität, Liquiditätsprobleme oder systemisches Deleveraging innerhalb des Aave-Ökosystems.
Erkennung, Eindämmung und Liquidationsentschädigungsplan
Die Fehlkonfiguration wurde innerhalb von Minuten erkannt, was eine beschleunigte Vorfallreaktion vom Aave-Team und seinen Risikoanbietern auslöste. Um weitere Exposition einzudämmen, wurden die wstETH-Kreditobergrenzen sowohl bei Aave Core als auch bei Aave Prime umgehend auf 1 reduziert, wodurch neue Kreditaktivitäten gegen diesen Vermögenswert effektiv eingefroren wurden.
Durch manuelle Risk Steward-Intervention glich das Team das snapshotRatio mit dem Live-snapshotTimestamp ab und stellte den Oracle-Feed auf seinen korrekten Wert wieder her. Eine Oracle-Korrektur wurde über Transaktion 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d durchgeführt, während die Änderungen der Kreditobergrenze zur Festlegung der wstETH-Kreditkapazität auf 1 wstETH über Transaktion 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8 ausgeführt wurden.
Trotz des erzwungenen Verkaufs erlitt das Protokoll keine uneinbringlichen Schulden und veröffentlichte eine detaillierte Post-Mortem-Analyse in den Aave-Governance-Foren. Allerdings erforderten Nutzerverluste durch Liquidationen eine separate politische Reaktion, die letztendlich zu einem strukturierten Liquidationsentschädigungsplan führte.
Um betroffene Konten zu entschädigen, holte Aave 141,5 ETH an Liquidationsboni durch BuilderNet-Rückerstattungen zurück. Das DAO-Treasury deckte dann die verbleibende Lücke ab, wobei die gesamte Nutzerentschädigung auf 358 ETH begrenzt war. Wichtig ist, dass der Plan über einen direkten Aave Improvement Proposal (AIP) umgesetzt wurde, wodurch sichergestellt wurde, dass betroffene Nutzer trotz des in der Infrastruktur entstandenen Fehlers eine vollständige Entschädigung erhielten.
Marktkontext rund um den Vorfall vom 10. März
Cross-Chain-Aktivitäten auf Aave zeigten während des Februar-März-Fensters ein robustes Nutzerwachstum. Zum Beispiel verzeichnete Avalanche am 10. Februar 38.445 einzahlende Nutzer, während Base am 6. März, nur vier Tage vor dem oracle-getriebenen Liquidationsereignis, 31.763 einzahlende Nutzer verzeichnete.
Diese Spitzen unterstreichen das wachsende Nutzerengagement über von Aave unterstützte Netzwerke hinweg, selbst als das Protokoll einen komplexen technischen Vorfall bewältigte. Darüber hinaus blieben Aaves Gesamteinlagen und -kredite während des frühen 2026 stabil, was darauf hindeutet, dass das Vertrauen in das Kerndesign des Protokolls nach dem Ereignis nicht wesentlich geschwächt wurde.
Die Stabilität der Einlagen, kombiniert mit der raschen Normalisierung der Liquidationen, unterstreicht, dass die wstETH-Fehlbewertung aus Konfigurationsproblemen entstand, nicht aus fundamentalem Stress in den Sicherheitenmärkten. Das heißt, das Konzentrationsrisiko bei Automatisierungsanbietern und Oracle-Pfaden bleibt ein strukturelles Anliegen für DeFi-Plattformen in Aaves Größenordnung.
Governance, Transparenz und die Zukunft der automatisierten Oracle-Ausführung
Der Vorfall vom 10. März veranschaulicht die Governance-Kompromisse, die durch automatisierte Oracle-Ausführung in großen DeFi-Kreditprotokollen geschaffen werden. Chaos Labs' Edge Risk empfahl eine Obergrenze unter dem Markt, BGDs AgentHub führte sie einen Block später aus, und Liquidationen folgten innerhalb von Minuten, was fast keine Zeit für menschliches Eingreifen ließ.
Aave reagierte mit schneller Erkennung, entscheidenden Korrekturmaßnahmen und vollständiger Nutzerentschädigung, die teilweise vom DAO-Treasury finanziert wurde. Die Episode offenbarte jedoch Unzulänglichkeiten in der Pre-Execution-Validierung und hob die Risiken einer übermäßigen Abhängigkeit von einer einzigen, proprietären Risiko-Engine hervor. Insbesondere begrenzt die geschlossene Natur der Chaos Labs Edge Risk-Berechnungen die unabhängige Überprüfung und platziert erhebliche operative Kontrolle in die Hände externer Dienstleister.
Da mehr DeFi-Protokolle automatisierte CAPO-Risiko-Agent-Frameworks und ähnliche Systeme übernehmen, zeigt der Vorfall, dass Governance robuste Tests, explizite Überprüfungsfenster und transparente Aufsicht integrieren muss. Darüber hinaus wird die breitere Aave-Oracle-Architektur wahrscheinlich zusätzliche Sicherheitsebenen benötigen, wie Multi-Source-Cross-Checks oder gestaffelte Rollout-Mechanismen, um sicherzustellen, dass zukünftige technische Fehler sich nicht direkt in Nutzerverluste übersetzen.
Zusammenfassend waren die Liquidationen vom 10. März keine Marktkrise, sondern ein Governance- und Infrastruktur-Stresstest. Die Kombination aus Automatisierung, schneller Ausführung und undurchsichtigem Risikomodellierung unterstreicht, warum DeFi-Protokolle Effizienz mit transparenten, überprüfbaren Schutzmaßnahmen ausbalancieren müssen, um Nutzer zu schützen.
Quelle: https://en.cryptonomist.ch/2026/03/23/aave-oracle-liquidations/
