50 Millionen USDT wurden gegen 35.000 USD AAVE getauscht: Wie kam es zu dieser Katastrophe? Wem sollen wir die Schuld geben?

Dieser Artikel stammt von: @Ehsan1579

Zusammengestellt von: Ethan, Odaily Planet Daily

Wenn man nur den Titel der Veranstaltung betrachtet, könnte man fälschlicherweise annehmen, dass es sich um einen Angriff zur Ausnutzung einer Sicherheitslücke handelt.

Der Kern der Sache ist: Jemand hat USDT im Wert von 50,4 Millionen Dollar gegen AAVE im Wert von nur 35.900 Dollar getauscht.

Ich war wirklich schockiert, als ich zum ersten Mal davon hörte. Daher habe ich das gesamte Geschehen gründlich überprüft: Transaktionsverfolgung, Solver-Pfade, Vertragsaufrufe, historische Reserven, Abrechnungsdaten, Adapterprozesse, den Aave-Schnittstellencode, das CoW-Flash-Loan-SDK sowie den Routing-Code, der bestimmt, ob das Angebot „angemessen“ ist.

Das ist kein Hackerangriff. Das Kernprotokoll von Aave hat keinen Fehler gemacht. Die CoW-Abteilung hat keinen Fehler gemacht. Uniswap hat keinen Fehler gemacht. SushiSwap hat keinen Fehler gemacht. Die Transaktion war gültig, die Unterschrift war gültig, und alle Verträge wurden streng nach den Vorschriften ausgeführt. Allerdings ging fast der gesamte wirtschaftliche Wert verloren, einfach weil die Route, die man ihm zugestanden hatte, absurd unvernünftig war.

Die öffentliche Blockchain hatte kein Problem; das Problem lag beim Routing.

Meiner Ansicht nach ist es weder objektiv noch seriös, diesen Vorfall als bloßen „Bedienungsfehler“ abzutun. Zwar hat der Nutzer die Order unterzeichnet, doch das gesamte Softwaresystem ließ zu, dass ein Vorgang mit Sicherheiten in Höhe von fast 50 Millionen Dollar die Angebotserstellung, die Unterzeichnung, die Routing-Planung und die endgültige Ausführung durchlief, wobei alle Schritte auf einen Liquiditätspool mit einem Bestand von nur etwa 331 AAVE hinwiesen. Das hätte eigentlich völlig unmöglich sein müssen und hätte zumindest vom System entschieden abgefangen und abgelehnt werden müssen, bevor die Abwicklungsphase eingeleitet wurde.

Kerninformationen zur Transaktionsverfolgung

Der Hash dieser ungewöhnlichen Transaktion lautet: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, bestätigt am 12. März 2026 bei Blockhöhe 24643151 im Ethereum-Mainnet, mit Transaktionsindex 1, einem Verbrauch von 3.780.570 Gas-Einheiten und erfolgreicher Ausführung der Transaktion. Die Wallet-Adresse der Bestellung beginnt mit 0x98b9, während die Adresse des tatsächlich ausführenden Solvers (Transaktionsabsenders) mit 0x3980 beginnt und in den CoW-Wettbewerbsdaten als „tsolver“ gekennzeichnet ist.

Zunächst einmal ist es wichtig zu verstehen, dass es sich hierbei nicht um einen einfachen Umtausch von USDT in AAVE auf Wallet-Ebene handelt. Der verkaufte Token ist aETHUSD, das verzinsliche USDT-Einlagenzertifikat auf der Aave-Plattform. Der gekaufte Token ist aEthAAVE, das verzinsliche AAVE-Einlagenzertifikat auf der Aave-Plattform. Es handelt sich also um einen Sicherheiten-Swap von Aave, der über das Abwicklungssystem des CoW-Protokolls und dessen Flash-Loan-Adapter-Prozess abgewickelt wird.

Vor der Transaktion enthielt die Wallet etwa 50.432.693,075254 aETHUSDT und 0 aETHAAVE. Nach der Transaktion blieben nur noch 4,980399 aEthUSDT übrig, und es wurden 327,241335505966487788 aEthAAVE erhalten. Tatsächlich hat das Wallet fast seine gesamte Position verkauft.

Aus den Metadaten geht deutlicher hervor, dass die Weiterleitung bereits vor der Ausführung „schädlich“ war. Der Auftrag kam vom Prozess „aave-v3-interface-collateral-swap“. Die API von CoW zeigte dies als unterzeichnete Verkaufsauftrag an, während die Anwendungsmetadaten es als Collateral Swap im Market-Stil mit 121 Basispunkten Smart Slippage kennzeichneten. Der vereinbarte Verkaufspreis belief sich auf 50.432.688,41618 aETH/USDT. Der vereinbarte Mindestkaufbetrag betrug 324,949260918413591035 aEthAAVE. Der tatsächlich gezahlte Ausgleichsbetrag belief sich auf 327,241335505966487788 aEthAAVE.

Das ist ein äußerst wichtiger Punkt. Bei der Bestellung war nicht damit gerechnet worden, Tausende von AAVE zu erhalten, nur um dann auf halbem Weg irgendwie vernichtet zu werden. Von Anfang an basierte es auf einem Ergebnis von über dreihundert AAVE.

Vollständiger Link zum Routing-Menü einklappen

Sobald man der Transaktionsverfolgung folgt, ist der gesamte Vorgang denkbar einfach.

Der Kapitalfluss auf oberster Ebene basiert auf dem Abwicklungsvertrag „GPv2Settlement“ des CoW-Protokolls, der mit 0x9008 beginnt. Zunächst schließt der HooksTrampoline-Vertrag mit der Adresse 0x60bf den Autorisierungsvorgang für aEthUSDT ab, wodurch der CoW-Treasury-Relayer die Vermögenswerte des Nutzers ohne separate Transaktionsautorisierung abrufen kann; anschließend überträgt der GPv2VaultRelayer-Vertrag mit der Adresse 0xc92e 50.432.688,41618 aEthUSDT aus der Wallet des Nutzers in den Abwicklungsprozess. Bis zu diesem Punkt entsprechen alle Vorgänge der üblichen Logik.

Der Abwicklungsvertrag erteilt daraufhin einem nicht verifizierten Hilfsvertrag, dessen Adresse mit 0xd524 beginnt, die Berechtigung zur Ausführung von aETHUSDT-Transaktionen und initiiert einen Aufruf über den Funktionsselektor 0x494b3137; dieser Hilfsvertrag überträgt die Ausführungsberechtigung anschließend an einen nicht verifizierten Ausführungsvertrag, dessen Adresse mit 0x699c beginnt, wodurch der gesamte Ablauf der abnormalen Transaktionsweiterleitung vollständig offengelegt wird.

Der erste effektive Aufruf verweist auf den Aave-Liquiditätspool-Vertrag, der mit 0x87870 beginnt, und vernichtet aETHUSD über die „withdraw“-Funktion (Selektor 0x69328dec), um das zugrunde liegende native USDT einzulösen; anschließend springt das Routing zum Uniswap V3 Deep-Handelspool für USDT/WETH, beginnend mit 0x4e68, und tauscht alle 50.432.688,41618 USDT gegen 17.957,810805702142342238 WETH um.

Die Transaktion verläuft zum jetzigen Zeitpunkt völlig normal: Der Wechselkurs liegt bei etwa 2808,4 USDT für 1 WETH, was dem damaligen Marktkurs entspricht; es gibt weder Probleme mit der Liquidität noch Abweichungen bei der Berechnung; der Link zur ersten Transaktionsstufe weist keine Auffälligkeiten auf.

Das Problem tritt beim zweiten Schritt auf; sobald man die Liquiditätsreserven sieht, ist der weitere Verlauf vorhersehbar.

Nachdem der Vollstrecker 17.957,810805702142342238 WETH erhalten hat, überweist er den gesamten Betrag an den SushiSwap V2 AAVE/WETH-Handelspool unter der Adresse 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Ich habe mir die historischen Daten zur Liquiditätsreserve dieses Handelspools kurz vor dem Auftreten der ungewöhnlichen Transaktion (Blockhöhe 24643150) angesehen, und der Pool verfügte lediglich über:

331,631982538108027323 AAVE, 17,653276196397688066 WETH

Das ist kein Eingabefehler, sondern eine unumstößliche Tatsache.

Durch diese Transaktionsweiterleitung flossen fast 17.958 WETH vollständig in einen Mikro-Handelspool, der lediglich 17,65 WETH vorhält, was einem Gesamtbestand von nur 331,63 AAVE entspricht, wobei das eingezahlte WETH-Volumen etwa das 1017-Fache der WETH-Reserven des Pools beträgt.

Hier handelt es sich nicht um ein gängiges Problem wie „hohe Slippage“ oder „leicht eingeschränkte Liquidität“, sondern um einen äußerst absurden Ausführungsweg für Marktorders, der damit gleichzusetzen ist, einen sehr kleinen AMM-Pool mit konstantem Produkt zu zwingen, eine Transaktion abzuwickeln, deren Umfang das Tausendfache seiner eigenen Kapazität übersteigt.

Der AMM-Handelspool führte den Vorgang gemäß dem festgelegten Algorithmus durch und schöpfte dabei fast die gesamten AAVE-Reserven im Pool aus.

Das SushiSwap-Handelspaar löste das zentrale Swap-Ereignis aus: Der Ausführende übertrug 17.957,810805702142342238 WETH und erhielt dafür nur 331,305315608938235428 AAVE zurück. Nach der Transaktion belief sich die verbleibende Liquidität im Pool auf etwa:

0,326666929169791895 AAVE, 17.975,464081898540030304 WETH

Einfach ausgedrückt wurden etwa 99,9 % der AAVE-Reserven im Pool in einem einzigen Schritt abgezogen.

Auf der Grundlage der Reserven vor der Transaktion lag der implizite AAVE-Preis im Pool bei etwa 149,50 $. Der tatsächliche Ausführungspreis des Nutzers lag bei etwa 154.114,66 USDT für 1 AAVE. Das ist mehr als das 1000-Fache des Kassakurses vor der Transaktion.

Anschließend wurden diese AAVE unter Verwendung des Selektors 0x617ba037, d. h. supply(address,uint256,address,uint16), wieder in den Aave-Liquiditätspool eingezahlt. Das Ergebnis war, dass die neu geschaffenen aEthAAVE zurück an den Siedlungskontrakt gesendet wurden. Im Rahmen des Vergleichsvertrags wurden dem Nutzer schließlich 327,241335505966487788 aEthAAVE übertragen. Etwa 4,06398010297174764 aEthAAVE verblieben im Abrechnungsvertrag als Überschuss gegenüber dem vom Nutzer gezahlten Betrag.

Der Vergleich hat also nicht plötzlich ein gutes Vollstreckungsergebnis in ein schlechtes verwandelt. Es hat lediglich das Ergebnis bestätigt, das die Routenführung bereits ermittelt hatte.

Dies ist ein wichtiger Punkt, der klar herausgestellt werden sollte: Das katastrophale Ergebnis war bereits vor der Ausführung in der Routing-Konfiguration „vorgegeben“.

In den in das Routing eingebetteten Daten zum Aufruf des Nebenvertrags betrug der angestrebte Kaufbetrag auf der Käuferseite etwa 331,272185078031026739, der vom Nutzer vereinbarte Mindestkaufbetrag lag bei 324,949260918413591035, und der tatsächliche Abrechnungsbetrag lag bei 327,241335505966487788, wobei alle Kernwerte vor der Abrechnung auf einem Niveau von über dreihundert AAVE festgeschrieben waren.

Diese Routenführung war von Anfang an schlecht.

Wo liegt der Fehler?

Die Antwort lautet: Jede Ebene des Verifizierungsmechanismus des Systems überprüft die falsche Dimension.

Auf allen Ebenen wird lediglich geprüft, ob die Transaktion ausführbar ist, ob die Signatur gültig ist und ob der Betrag ungleich Null ist; es gibt jedoch fast keine grundlegende Überprüfung, ob die Transaktionsführung wirtschaftlich sinnvoll ist, was die eigentliche Ursache für das Versagen des Mechanismus darstellt.

Codefehler im Pfad der Aave-Schnittstellenadapter-Anfrage

Der erste offensichtliche Hinweis auf eine Code-Anomalie findet sich im CoW-Adapter-Angebotsprozess der Aave-Schnittstelle: Die Funktion, die ursprünglich dazu diente, adapterspezifische Anwendungsdaten bei der Anforderung eines Angebots anzuhängen, wurde direkt deaktiviert.

Quelle: rates.helpers.ts:93 und adapters.helpers.ts:194

Das bedeutet, dass die Aave-Schnittstelle, wenn sie eine Kursanfrage an CoW sendet, nicht die Metadaten zum Flash-Kredit und zum Hook beifügt, die bei der Platzierung eines Auftrags tatsächlich enthalten wären. Mit anderen Worten: Was dort steht, entspricht nicht ganz dem, was tatsächlich ausgeführt wird. In den Code-Kommentaren wird sogar darauf hingewiesen, dass der Zweck dieser Hilfsfunktion darin besteht, die Angaben des Adapters genauer zu machen, dennoch wurde diese Funktion zwangsweise deaktiviert.

Fehlerhafte Plausibilitätsprüfung in der CoW-Quotenvergleichslogik (grundlegender Fehler)

Das zweite und schwerwiegendste Problem liegt in der Logik des CoW-Protokolls zur Angebotskonkurrenz: In seinem öffentlichen Code gilt ein Angebot als „angemessen“, solange die Gasgebühr für das Angebot positiv ist und der Ausgabebetrag ungleich Null ist.

Quelle: quote.rs:31

Für ein Routingsystem, das achtstellige Bestellungen verarbeitet, ist dies eine erschreckend schwache Definition von „Angemessenheit“.

Das System verfügte weder über Orakel zur Überprüfung der Preisangemessenheit, noch über einen Mechanismus zur Erkennung von „Kursnotierungen, die um mehr als das 500-Fache vom Kassakurs abweichen“, noch über eine Risikobewertung für „Routing, das Liquiditätspools vollständig erschöpft“, noch über eine Warnung bei „erheblicher Diskrepanz zwischen der Liquidität am letzten Hop und dem Auftragsvolumen“; Es verlangte lediglich, dass der Solver einen ausführbaren, von Null verschiedenen Routing-Plan zurückgab, der vom System akzeptiert wurde – dies ist der zentrale Fehler dieses Vorfalls.

Fehler in der Logik der Liquiditätsmodellierung nach dem Vorbild von Uniswap V2

Das dritte Problem liegt im Modellierungsansatz für Liquiditätspools nach dem Vorbild von Uniswap V2: Der Code verwendet lediglich den Standardalgorithmus des konstanten Produkts und lehnt lediglich mathematisch unmögliche Situationen wie Nullreserven, Unterlauf und Überlauf ab, ohne dabei die wirtschaftliche Machbarkeit zu prüfen.

Quelle: pool_fetching.rs:118 und pool_fetching.rs:153

Dieser Codeabschnitt prüft nicht, ob die Größe des Liquiditätspools ausreicht, um die entsprechende Routing-Transaktion abzuwickeln; er überprüft lediglich, ob der Swap-Vorgang rechnerisch gültig ist. Daher würde selbst ein Mikro-Pool mit nur 331 AAVE-Reserven als geeigneter Ort für die Abwicklung eines Kaufauftrags über 17.957 WETH angesehen werden, einfach weil der Algorithmus des konstanten Produkts ein Ergebnis ungleich Null liefern kann, wobei der katastrophale Vermögensverlust, den dieses Ergebnis verursachen würde, völlig außer Acht gelassen wird.

Sekundärer Ausfall des Flash-Loan-SDK und des Mechanismus zur Auftragsüberprüfung

Anschließend hat das Flash-Loan-SDK dieses ungültige Angebot direkt in die Order- und Hook-Ausführungsdaten integriert, ohne dass ein sekundäres Risiko abgefangen wurde.

Dann:

Quelle: index.js:484 und index.js:591

Deshalb habe ich immer gesagt, dass diese Streckenführung „von Anfang an schlecht“ ist. Die Adapterschicht hat während der Ausführung keinen neuen fehlerhaften Wert „entdeckt“. Es hat den bereits genannten falschen Wert in die Hook-Daten und die ermittelte Instanzadresse serialisiert. Sobald ein fehlerhaftes Zitat vorliegt, geben die übrigen Mechanismen es unverändert weiter.

Selbst die Logik zur Auftragsüberprüfung von CoW bot dem Nutzer hier keinen wirklichen Schutz, da sie lediglich prüft, ob der Auftrag den Marktpreis zum Zeitpunkt der Kursstellung übersteigt, ohne zu überprüfen, ob die Kursstellung selbst im Verhältnis zur tatsächlichen Liquidität absurd ist.

Quelle: order_validation.rs:694

Dies ist eine Konsistenzprüfung. Selbst wenn das Zitat an sich schon Unsinn ist, kann der Antrag dennoch angenommen werden.

Der Warnmechanismus im UI-Frontend ist unwirksam

Die Aave-Benutzeroberfläche verfügt zwar über Warnungen bei starken Kursschwankungen, es handelt sich jedoch nicht um einen Hard Circuit Breaker. Wenn der Wertverlust 20 % übersteigt, wird das Kontrollkästchen zu einem Bestätigungsfeld.

Sobald der Benutzer das Kontrollkästchen aktiviert, wird die Sperre aufgehoben:

Quelle: helpers.ts:24 und HighPriceImpactWarning.tsx:35

Selbst wenn diese Transaktion den gesamten Vermögenswert fast vollständig aufbrauchen würde, stufte das System sie daher lediglich als einen Vorgang ein, der einer Bestätigung durch den Nutzer bedarf, und nicht als risikoreiche Transaktion, die vom System strikt abgelehnt werden muss; der Warnmechanismus verlor somit vollständig seine Funktion zur Risikoabwehr.

Angesichts all dieser Systemfehler stimme ich der abwertenden Schlussfolgerung, dass „es sich lediglich um Benutzerfehler handelt“, absolut nicht zu. Der Benutzer hat die Signatur zwar vervollständigt, doch das gesamte Softwaresystem hatte unzählige Gelegenheiten, diese Katastrophe abzuwenden. Dennoch führte jede Ebene lediglich grundlegende Prüfungen durch, stellte fest, dass die Datei „nicht null, ausführbar und signiert“ war, und gab sie direkt frei, was letztendlich zu verheerenden Folgen führte.

Die Weiterleitung wurde nicht manipuliert

Dieser Abschnitt ist entscheidend, da er eine Vielzahl falscher Spekulationen direkt ausschließt: Der offizielle Aave-Interface-Prozess, der „aave-v3-interface-collateral-swap“ entspricht, berechnet in Zeile 139 der Datei „useSwapOrderAmounts.ts“ den um Slippage bereinigten Kaufbetrag, wobei er den Kurs, die Netzwerkgebühren, die Partnergebühren und die Flash-Loan-Gebühren zusammenfasst; In Zeile 331 wird dieser Wert in den buyAmountBigInt-Wert umgewandelt; anschließend wird dieser Betrag in Zeile 191 der Datei CollateralSwapActionsViaCoWAdapters.tsx präzise signiert.

Nachfolgende Adapterverträge überprüfen, ob die Felder des signierten Auftrags vollständig mit den in Zeile 141 der Datei „AaveV3BaseAdapter.sol“ gespeicherten Werten übereinstimmen; der CoW-Abrechnungsvertrag setzt die in Zeile 337 der Datei „GPv2Settlement.sol“ festgelegten Regeln für das vereinbarte Limit durch. Daher überschritt das Ergebnis der On-Chain-Ausführung nicht die in der unterzeichneten Order festgelegten Grenzen, und die Vermögenswerte, die der Nutzer tatsächlich erhielt, lagen sogar über dem in der Unterzeichnung vereinbarten Mindestbetrag.

Dies reicht aus, um zu beweisen: Die Katastrophe ereignete sich vor der Abwicklungsphase und nicht während des Abwicklungsprozesses; der fatale Fehler in der Routenführung hatte den Ausgang bereits vorbestimmt.

Wo ist der verschwundene Wert geblieben?

Die nächste Transaktion im selben Block (Hash beginnend mit 0x45388b0f) schloss eine Back-Run-Arbitrage gegen den kompromittierten SushiSwap-AAVE/WETH-Pool ab. Nachdem die ungewöhnliche Transaktion den Pool mit einer riesigen Menge an WETH gefüllt und den Großteil des AAVE abgezogen hatte, verkaufte der Arbitrageur das AAVE sofort wieder in den Pool zurück und sicherte sich so den durch das Liquiditätsungleichgewicht entstandenen Mehrwert.

Durch diese Back-Run-Arbitrage wurden etwa 17.929,770158685933 WETH erzielt; anschließend wurden etwa 13.087,73 ETH an den Block-Builder und etwa 4.824,31 ETH an die Adresse für die Arbitrage-Ausführung gezahlt.

Der gesamte wirtschaftliche Wertverlust für den Nutzer wurde letztendlich fast augenblicklich in MEV-Arbitragegewinne und Gewinne für Block-Builder innerhalb desselben Blocks umgewandelt.

Darüber hinaus bestätigt die Überprüfung der Zeitabfolge auf Blockebene: Niemand hat den SushiSwap-Handelspool in böswilliger Absicht manipuliert, um den Nutzern eine Falle zu stellen; das Handelspaar AAVE/WETH war als erstes von dieser anomalen Transaktion betroffen (Transaktionsindex 1); die unmittelbar darauf folgende Transaktion (Transaktionsindex 2) schloss den ersten Gegenlauf zur durch diese Transaktion verursachten Preisverzerrung ab; auch Transaktionsindex 3 betraf dieses Handelspaar während des Marktkorrekturprozesses. Der zeitliche Ablauf belegt eindeutig: Diese ungewöhnliche Transaktion führte zu einer extremen Preisverzerrung, und nachfolgende Transaktionen nutzten diesen verzerrten Gewinn direkt aus.

Wessen Schuld ist es also?

Wenn man fragt, ob das Kernprotokoll von Aave V3 zusammengebrochen ist, lautet die Antwort: Nein. Der Aave-Liquiditätspool führte die Vorgänge vollständig gemäß den Anweisungen durch und schloss den Rückkauf von USDT sowie die Einzahlung von AAVE erfolgreich ab.

Wenn Sie fragen, ob der GPv2Settlement-Vertrag der CoW gescheitert ist, lautet die Antwort: Nein. Im Rahmen des Vergleichs wurde ein gültiger, unterzeichneter Auftrag vollstreckt und ein Betrag gezahlt, der über dem in der Unterzeichnung vereinbarten Mindestbetrag lag.

Wenn man fragt, ob die Kontrakte des Handelspaares von Uniswap V3 oder SushiSwap zusammengebrochen sind, lautet die Antwort ebenfalls nein. Beide Arten von Handelspools haben die Preisgestaltung der Transaktionen nach ihren eigenen algorithmischen Regeln vorgenommen.

Das eigentliche systemische Versagen trat auf den übergeordneten Ebenen der Weiterleitung und der Risikokontrolle auf:

Die Hauptverantwortung liegt bei den Modulen für Routing, Kursberechnung und Orderabwicklung des CoW-Protokolls: Die Kriterien des gesamten Systems zur Bestimmung eines „angemessenen Routings“ sind zu lasch, sodass Aufträge im Wert von mehreren Millionen Dollar letztendlich in Pools mit extrem geringer Liquidität gelangen können. Solange das Routing ausführbar ist und nicht gleich Null ist, wird es akzeptiert, wobei die extreme Unangemessenheit auf wirtschaftlicher Ebene völlig außer Acht gelassen wird.

Die sekundäre verantwortliche Stelle ist die Aave-Frontend-Schnittstelle: Sie hat bei der Anforderung von Adapter-Quotes die mit dem Hook verbundenen Anwendungsdaten nicht angehängt, wodurch fehlerhafte Ergebnisse direkt in den Signaturprozess gelangten, und sich ausschließlich auf Warnmeldungen verlassen, ohne über einen Mechanismus zur zwingenden Ablehnung zu verfügen. Bei derart umfangreichen Transaktionen reichen diese Maßnahmen zur Risikokontrolle bei weitem nicht aus, um Risiken zu vermeiden.

Dies ist ein eklatanter Versager der Transaktionsweiterleitung und der Risikokontrollmechanismen, der eine rechtmäßige und vorschriftsmäßige Sicherheiten-Swap-Transaktion unmittelbar in einen katastrophalen Vermögensverlust verwandelt hat.