50 milionów USDT wymieniono na 35 000 USD AAVE: Jak doszło do tej katastrofy? Kogo powinniśmy za to winić?

Ten artykuł pochodzi od: @Ehsan1579

Opracowanie: Ethan, Odaily Planet Daily

Patrząc tylko na tytuł wydarzenia, można by błędnie pomyśleć, że chodzi o atak polegający na wykorzystaniu luki w zabezpieczeniach.

Najważniejszym punktem wydarzenia jest to, że ktoś wymienił USDT o wartości 50,4 mln dolarów na AAVE warte zaledwie 35 900 dolarów.

Byłem naprawdę zszokowany, kiedy po raz pierwszy o tym usłyszałem. W związku z tym dokładnie przeanalizowałem całe zdarzenie: śledzenie transakcji, ścieżki solwera, wywołania kontraktów, historyczne rezerwy, dane rozliczeniowe, procesy adapterów, kod interfejsu Aave, SDK CoW dla pożyczek błyskawicznych oraz kod routingu, który określa, czy oferta jest „rozsądna”.

To nie jest atak hakerski. Podstawowy protokół Aave nie popełnił błędu. Władze CoW nie popełniły błędu. Uniswap nie popełnił błędu. SushiSwap nie popełnił błędu. Transakcja była ważna, podpis był ważny, a wszystkie umowy zostały zawarte ściśle zgodnie z przepisami. Jednak niemal cała wartość ekonomiczna została zniweczona tylko dlatego, że dopuszczono do tego, by proces ten przebiegał w absurdalnie nieracjonalny sposób.

Problem nie leżał po stronie łańcucha publicznego; problem dotyczył routingu.

Moim zdaniem bagatelizowanie tego incydentu jako zwykłego „błędu operacyjnego użytkownika” nie jest postawą obiektywną ani rzetelną. Co prawda użytkownik złożył podpis pod zleceniem, jednak cały system oprogramowania zezwolił na przeprowadzenie operacji obejmującej zabezpieczenie o wartości prawie 50 milionów dolarów w celu sporządzenia oferty, złożenia podpisu, zaplanowania trasy i ostatecznej realizacji zlecenia, a wszystko to w odniesieniu do puli o niskiej płynności, zawierającej jedynie około 331 AAVE. Powinno to być całkowicie niemożliwe i przynajmniej powinno zostać skutecznie przechwycone i odrzucone przez system przed rozpoczęciem etapu rozliczenia.

Podstawowe informacje dotyczące przebiegu transakcji

Skrót tej nietypowej transakcji to: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, potwierdzona 12 marca 2026 r. w sieci głównej Ethereum na wysokości bloku 24643151, z indeksem transakcji 1, zużywając 3 780 570 jednostek gazu, a transakcja została pomyślnie wykonana. Adres portfela powiązany z zleceniem zaczyna się od 0x98b9, natomiast adres rzeczywistego solwera realizującego zlecenie (nadawcy transakcji) zaczyna się od 0x3980 i jest oznaczony jako „tsolver” w danych konkursu CoW.

Po pierwsze, należy pamiętać, że nie jest to zwykła wymiana USDT na AAVE na poziomie portfela. Sprzedawanym tokenem jest aETHUSD, czyli oprocentowany certyfikat depozytowy USDT na platformie Aave. Zakupiony token to aEthAAVE, czyli oprocentowany certyfikat depozytowy AAVE na platformie Aave. W związku z tym jest to w rzeczywistości transakcja zamiany zabezpieczeń w sieci Aave, realizowana za pośrednictwem systemu rozliczeniowego protokołu CoW oraz jego mechanizmu obsługi pożyczek błyskawicznych.

Przed transakcją w portfelu znajdowało się około 50 432 693,075254 aEthUSDT oraz 0 aEthAAVE. Po transakcji pozostało mu jedynie 4,980399 aEthUSDT, a otrzymał 327,241335505966487788 aEthAAVE. W rzeczywistości portfel sprzedał niemal całą swoją pozycję.

Metadane wyraźniej wskazują, że trasa była już „toksyczna” przed wykonaniem. Zlecenie pochodziło z procesu aave-v3-interface-collateral-swap. Interfejs API CoW wyświetlił to jako zlecenie sprzedaży z ceną określoną, podczas gdy metadane aplikacji oznaczyły je jako transakcję zamiany zabezpieczenia typu rynkowego z wykorzystaniem 121 punktów bazowych inteligentnego poślizgu. Kwota podpisanej transakcji sprzedaży wyniosła 50 432 688,41618 aEthUSDT. Uzgodniona minimalna kwota zakupu wyniosła 324,949260918413591035 aEthAAVE. W ramach ugody wypłacono kwotę 327,241335505966487788 aEthAAVE.

To niezwykle ważny szczegół. W zleceniu nie przewidywano, że uda się zdobyć tysiące AAVE, a jednak w połowie procesu wszystko jakoś się nie udało. Od samego początku opierało się to na wyniku przekraczającym trzysta AAVE.

Zwiń wszystkie linki trasy

Gdy już zaczniesz śledzić transakcję, cały proces jest niezwykle prosty.

Przepływ kapitału na najwyższym poziomie opiera się na kontrakcie rozliczeniowym GPv2Settlement protokołu CoW, którego identyfikator zaczyna się od 0x9008. Najpierw kontrakt HooksTrampoline, którego adres zaczyna się od 0x60bf, finalizuje operację autoryzacji aEthUSDT, umożliwiając relatorowi skarbca CoW pobranie środków użytkownika bez konieczności przeprowadzania oddzielnej autoryzacji transakcji; następnie kontrakt GPv2VaultRelayer, którego adres zaczyna się od 0xc92e, pobiera kwotę 50 432 688,41618 aEthUSDT z portfela użytkownika i przekazuje ją do procesu rozliczeniowego. Jak dotąd wszystkie operacje przebiegają zgodnie z normalną logiką.

Umowa rozliczeniowa przyznaje następnie uprawnienia do obsługi aETHUSDT niezweryfikowanemu kontraktowi pomocniczemu, którego adres zaczyna się od 0xd524, i inicjuje wywołanie za pośrednictwem selektora funkcji 0x494b3137; kontrakt pomocniczy przekazuje następnie uprawnienia wykonawcze niezweryfikowanemu kontraktowi wykonawczemu, którego adres zaczyna się od 0x699c, co pozwala w pełni ujawnić nieprawidłowy przebieg transakcji.

Pierwsze wywołanie kieruje się do kontraktu puli płynności Aave o adresie zaczynającym się od 0x87870, który niszczy aEthUSDT za pomocą funkcji wypłaty (selektor 0x69328dec) w celu wykupienia bazowego natywnego USDT; następnie routing przechodzi do głębokiej puli handlowej USDT/WETH Uniswap V3, zaczynającej się od 0x4e68, wymieniając całe 50 432 688,41618 USDT na 17 957,810805702142342238 WETH.

Transakcja na tym etapie przebiega całkowicie normalnie: kurs wymiany wynosi około 2808,4 USDT za 1 WETH, co jest zgodne z ówczesną sytuacją rynkową; nie odnotowano żadnych problemów z płynnością ani odchyleń w obliczeniach; link transakcji pierwszego przeskoku nie wykazuje żadnych nieprawidłowości.

Problem pojawia się na drugim etapie; gdy tylko dostrzeżesz rezerwy płynności, dalszy rozwój wydarzeń jest nieunikniony.

Po otrzymaniu kwoty 17 957,810805702142342238 WETH wykonawca przekazuje wszystkie środki do puli handlowej SushiSwap V2 AAVE/WETH pod adresem 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Sprawdziłem historyczne dane dotyczące rezerwy płynności tej puli tuż przed wystąpieniem nietypowej transakcji (wysokość bloku 24643150) i okazało się, że pula posiadała jedynie:

331,631982538108027323 AAVE, 17,653276196397688066 WETH

To nie jest błąd w danych, lecz niepodważalny fakt.

W ramach tej transakcji prawie 17 958 WETH trafiło w całości do mikro-puli handlowej, która dysponuje jedynie 17,65 WETH, co odpowiada łącznym zasobom AAVE wynoszącym zaledwie 331,63 AAVE, przy czym wpłacona kwota WETH była około 1017 razy większa od rezerw WETH tej puli.

Nie jest to typowy problem związany z „dużym poślizgiem” czy „nieco ograniczoną płynnością”, lecz skrajnie absurdalny przebieg realizacji zlecenia rynkowego, porównywalny do zmuszania bardzo małej puli AMM typu „stały produkt” do przeprowadzenia transakcji o skali tysiąckrotnie przekraczającej jej możliwości.

Pula handlowa AMM przeprowadziła operację zgodnie z ustalonym algorytmem, niemalnie wyczerpując wszystkie rezerwy AAVE w puli.

Para handlowa SushiSwap spowodowała wystąpienie podstawowego zdarzenia na giełdzie Swap: wykonawca przekazał 17 957,810805702142342238 WETH, otrzymując w zamian jedynie 331,305315608938235428 AAVE. Po przeprowadzeniu transakcji pozostała płynność w puli wynosiła około:

0,326666929169791895 AAVE, 17 975,464081898540030304 WETH

Mówiąc najprościej, około 99,9% rezerw AAVE w puli zostało wyprowadzonych w jednym kroku.

Biorąc pod uwagę rezerwy przed transakcją, implikowana cena AAVE w puli wynosiła około 149,50 USD. Rzeczywista cena realizacji transakcji użytkownika wyniosła około 154 114,66 USDT za 1 AAVE. Różnica ta jest ponad tysiąc razy większa od ceny spotowej sprzed zawarcia transakcji.

Następnie te tokeny AAVE zostały ponownie wprowadzone do puli płynności Aave przy użyciu selektora 0x617ba037, tj. za pomocą funkcji supply(adres, uint256, adres, uint16). W rezultacie nowo wyemitowane aEthAAVE zostały zwrócone do kontraktu rozliczeniowego. W ramach umowy ugody użytkownikowi przekazano ostatecznie 327,241335505966487788 aEthAAVE. W umowie rozliczeniowej pozostała kwota około 4,06398010297174764 aEthAAVE jako nadwyżka w stosunku do kwoty zapłaconej przez użytkownika.

W związku z tym ugoda nie spowodowała nagłego przekształcenia dobrego wyniku egzekucji w zły. Było to jedynie potwierdzeniem wyniku, który wygenerował już system routingu.

Warto wyraźnie podkreślić jedną kluczową kwestię: katastrofalny wynik był już „zaprogramowany” w algorytmie przed jego uruchomieniem.

W danych dotyczących wywołania kontraktu pomocniczego zawartych w trasowaniu docelowa kwota zakupu po stronie kupującej wynosiła około 331,272185078031026739, a minimalna kwota zakupu uzgodniona przez użytkownika wynosiła 324,949260918413591035, a rzeczywista kwota rozliczenia wyniosła 327,241335505966487788, przy czym wszystkie wartości podstawowe zostały zablokowane na poziomie ponad trzystu AAVE przed rozliczeniem.

Ta trasa od początku była skazana na niepowodzenie.

Gdzie tkwi błąd?

Odpowiedź brzmi: każda warstwa mechanizmu weryfikacyjnego systemu sprawdza niewłaściwy wymiar.

Na wszystkich poziomach sprawdza się jedynie, czy transakcja może zostać zrealizowana, czy podpis jest ważny i czy kwota jest niezerowa, ale praktycznie nie ma żadnej kontroli na poziomie podstawowym, która sprawdzałaby, czy przebieg transakcji jest uzasadniony ekonomicznie, co stanowi główną przyczynę niepowodzenia tego mechanizmu.

Błąd w ścieżce wyceny adaptera interfejsu Aave

Pierwsza oczywista nieprawidłowość w kodzie pojawia się w procesie wyceny adaptera CoW w interfejsie Aave: funkcja, która pierwotnie służyła do dołączania danych aplikacyjnych specyficznych dla adaptera podczas żądania wyceny, została bezpośrednio wyłączona.

Źródło: rates.helpers.ts:93 oraz adapters.helpers.ts:194

Oznacza to, że gdy interfejs Aave wysyła zapytanie o wycenę do CoW, nie dołącza do niego danych dotyczących pożyczki błyskawicznej ani metadanych dotyczących haka, które faktycznie byłyby uwzględnione przy składaniu zlecenia. Innymi słowy, to, co jest zapisane w kodzie, nie jest w pełni tym, co zostanie wykonane. W komentarzach do kodu wyraźnie zaznaczono, że celem tej funkcji pomocniczej jest zwiększenie dokładności cudzysłowów stosowanych przez adapter, a mimo to funkcja ta została przymusowo wyłączona.

Niewłaściwe określenie zasadności w logice konkursu ofert CoW (podstawowa wada)

Drugi i najpoważniejszy problem dotyczy logiki konkurencji ofert w protokole CoW: zgodnie z jego kodeksem publicznym, o ile opłata za gaz związana z ofertą jest dodatnia, a kwota wyjściowa niezerowa, oferta ta zostanie uznana za „rozsądną”.

Źródło: quote.rs:31

W przypadku systemu dyspozytorskiego obsługującego zamówienia ośmiocyfrowe jest to zaskakująco wąska definicja „rozsądku”.

System nie posiadał wbudowanych mechanizmów weryfikacji poprawności cen, nie dysponował mechanizmem przechwytywania „notowań odbiegających od ceny spot o ponad 500 razy”, nie przeprowadzał oceny ryzyka w przypadku „trasowania całkowicie wyczerpującego pule płynności” ani nie generował ostrzeżeń o „poważnym niedopasowaniu płynności na ostatnim etapie trasowania do skali zlecenia”; wymagał jedynie, aby solwer zwrócił wykonalny plan routingu o wartości niezerowej, który zostałby zaakceptowany przez system – to jest podstawowa wada tego incydentu.

Błędy w logice modelowania płynności w stylu Uniswap V2

Trzeci problem wynika z podejścia do modelowania pul płynności w stylu Uniswap V2: kod wykorzystuje wyłącznie standardowy algorytm iloczynu stałych, odrzucając jedynie sytuacje matematycznie niemożliwe, takie jak zerowe rezerwy, przepełnienie w dół i przepełnienie w górę, bez przeprowadzania kontroli ekonomicznej wykonalności.

Źródło: pool_fetching.rs:118 i pool_fetching.rs:153

Ten fragment kodu nie sprawdza, czy wielkość puli płynności jest wystarczająca do obsłużenia danej transakcji routingu; sprawdza jedynie, czy operacja zamiany jest matematycznie poprawna. W związku z tym nawet mikropool dysponujący jedynie 331 rezerwami AAVE zostałby uznany za odpowiednie miejsce do zrealizowania zlecenia kupna na 17 957 WETH, po prostu dlatego, że algorytm stałego iloczynu może dać wynik niezerowy, całkowicie pomijając katastrofalną utratę aktywów, jaką taki wynik spowodowałby.

Drugorzędna awaria zestawu SDK pożyczek błyskawicznych oraz mechanizmu weryfikacji zleceń

Następnie zestaw SDK do pożyczek błyskawicznych bezpośrednio uwzględnił tę nieprawidłową ofertę w treści zlecenia i w danych wykonania funkcji hook, bez żadnej dodatkowej kontroli ryzyka.

Wtedy:

Źródło: index.js:484 i index.js:591

Właśnie dlatego zawsze twierdziłem, że ta trasa jest „z góry skazana na niepowodzenie”. Warstwa adaptera nie „wykryła” nowej nieprawidłowej wartości podczas wykonywania. Wpisała już podaną nieprawidłową wartość do danych haka i ustaliła adres instancji. Gdy pojawi się błędny cytat, pozostałe mechanizmy będą go wiernie powielać.

Nawet stosowana tutaj przez CoW logika weryfikacji zleceń nie zapewniała użytkownikowi rzeczywistej ochrony, ponieważ sprawdzała jedynie, czy cena zlecenia przekracza cenę rynkową w momencie wyceny, nie biorąc pod uwagę tego, czy sama wycena jest nieadekwatna w stosunku do rzeczywistej płynności.

Źródło: order_validation.rs:694

To jest kontrola spójności. Nawet jeśli sama oferta jest bezsensowna, zamówienie może zostać przyjęte.

Mechanizm ostrzegania w interfejsie użytkownika jest nieskuteczny

Interfejs Aave wyświetla co prawda ostrzeżenia o znacznym wpływie na cenę, ale nie jest to mechanizm typu „hard circuit breaker”. Gdy spadek wartości przekroczy 20%, pole wyboru zmienia się w pole potwierdzające.

Gdy użytkownik zaznaczy to pole wyboru, blokada zostanie zniesiona:

Źródło: helpers.ts:24 oraz HighPriceImpactWarning.tsx:35

W związku z tym, nawet gdyby transakcja ta niemal całkowicie wyczerpała wartość aktywów, system uznał ją jedynie za operację wymagającą potwierdzenia przez użytkownika, a nie za transakcję wysokiego ryzyka, którą system powinien zdecydowanie odrzucić, przez co mechanizm ostrzegawczy całkowicie stracił swoją funkcję wykrywania zagrożeń.

Biorąc pod uwagę wszystkie powyższe awarie mechanizmów, absolutnie nie zgadzam się z lekceważącym stwierdzeniem, że „to po prostu głupota użytkowników”. Użytkownik wprawdzie podpisał plik, ale cały system oprogramowania miał niezliczone możliwości zapobieżenia tej katastrofie, a mimo to każda warstwa przeprowadzała jedynie podstawowe kontrole, stwierdzając, że plik „nie jest zerowy, jest wykonywalny i podpisany”, po czym bezpośrednio go udostępniała, co ostatecznie doprowadziło do katastrofalnych skutków.

Trasa nie została zmieniona

Ta sekcja ma kluczowe znaczenie, ponieważ pozwala bezpośrednio wykluczyć wiele błędnych spekulacji: proces oficjalnego interfejsu Aave odpowiadający aave-v3-interface-collateral-swap oblicza kwotę zakupu skorygowaną o poślizg cenowy w linii 139 pliku useSwapOrderAmounts.ts, uwzględniając kwotę oferty, opłaty sieciowe, opłaty partnerów oraz opłaty za pożyczki błyskawiczne; w linii 331 przekształca ją na wartość buyAmountBigInt; następnie w linii 191 pliku CollateralSwapActionsViaCoWAdapters.tsx kwota ta jest precyzyjnie podpisywana.

Kolejne kontrakty adapterów będą weryfikować, czy pola podpisanego zlecenia są w pełni zgodne z wartościami zapisanymi w wierszu 141 pliku AaveV3BaseAdapter.sol; kontrakt rozliczeniowy CoW będzie egzekwował zasady dotyczące podpisanych limitów w wierszu 337 pliku GPv2Settlement.sol. W związku z tym wynik realizacji transakcji w łańcuchu bloków nie przekroczył limitów określonych w podpisanym zleceniu, a aktywa faktycznie otrzymane przez użytkownika były nawet wyższe od minimalnego limitu uzgodnionego w podpisie.

To wystarczy, by udowodnić, że: katastrofa miała miejsce przed etapem rozstrzygnięcia, a nie w trakcie procesu rozstrzygającego; fatalna wada trasy z góry przesądziła o wyniku.

Gdzie podziała się ta utracona wartość?

Kolejna transakcja w tym samym bloku (z hash'em zaczynającym się od 0x45388b0f) zakończyła arbitraż typu „back-run” w uszkodzonej puli AAVE/WETH platformy SushiSwap. Gdy nietypowa transakcja zapełniła pulę ogromną ilością WETH i wyczerpała większość AAVE, arbitrażysta natychmiast odsprzedał AAVE z powrotem do puli, czerpiąc zyski z nadwyżki wartości wynikającej z braku równowagi płynności.

W ramach tej arbitrażu typu „back-run” pozyskano około 17 929,770158685933 WETH, a następnie wypłacono około 13 087,73 ETH twórcy bloku oraz około 4 824,31 ETH na adres służący do realizacji arbitrażu.

Cała utracona przez użytkownika wartość ekonomiczna została ostatecznie niemal natychmiast przekształcona w zyski z arbitrażu MEV oraz zyski twórców bloku w ramach tego samego bloku.

Ponadto analiza sekwencji czasowej na poziomie bloków potwierdza, że: nikt nie manipulował w złych zamiarach pulą handlową SushiSwap w celu zastawienia pułapki na użytkowników; ta nietypowa transakcja (indeks transakcji 1) jako pierwsza dotknęła pary handlowej AAVE/WETH; bezpośrednio następująca po niej transakcja (indeks transakcji 2) zakończyła pierwszy ruch korygujący w stosunku do zniekształcenia ceny spowodowanego przez tę transakcję; indeks transakcji 3 również dotknął tej pary handlowej w trakcie procesu korekty rynkowej. Z przebiegu wydarzeń jasno wynika, że ta nietypowa transakcja spowodowała skrajne zniekształcenie cen, a kolejne transakcje pozwoliły bezpośrednio czerpać zyski z tego zniekształcenia.

Więc czyja to wina?

Jeśli zapytasz, czy podstawowy protokół Aave V3 uległ awarii, odpowiedź brzmi: nie. Pula płynności Aave przeprowadziła operacje całkowicie zgodnie z instrukcjami, pomyślnie realizując proces wykupu USDT i wpłaty AAVE.

Jeśli zapytasz, czy kontrakt GPv2Settlement platformy CoW uległ załamaniu, odpowiedź brzmi: nie. W ramach ugody wykonano ważne, podpisane postanowienie i wypłacono kwotę przekraczającą minimalny limit uzgodniony w podpisanej umowie.

Jeśli zapytasz, czy kontrakty na pary walutowe w Uniswap V3 lub SushiSwap uległy załamaniu, odpowiedź również brzmi: nie. Oba rodzaje grup handlowych ustalały ceny transakcji zgodnie z zasadami określonych w ich algorytmach.

Prawdziwa awaria systemowa miała miejsce na wyższych poziomach routingu i kontroli ryzyka:

Główną przyczyną tego stanu rzeczy są moduły protokołu CoW odpowiedzialne za kierowanie zleceń, wycenę i rozliczanie: kryteria całego systemu służące do określenia „rozsądnego kierowania zleceń” są zbyt słabe, co pozwala na to, by zlecenia warte wiele milionów dolarów trafiały ostatecznie do mikropooli o bardzo niskiej płynności – o ile kierowanie zlecenia jest wykonalne i nie wynosi zera, zostaje ono zaakceptowane, przy całkowitym pominięciu skrajnej nieracjonalności tego rozwiązania z ekonomicznego punktu widzenia.

Drugą stroną odpowiedzialną jest interfejs użytkownika Aave: podczas żądania wyceny adaptera nie dołączył on danych aplikacji związanych z hakiem, przekazując błędne wyniki bezpośrednio do procesu podpisywania, a ponadto polegał wyłącznie na komunikatach ostrzegawczych, nie dysponując mechanizmem twardego odrzucenia. W przypadku tak niezwykle dużych transakcji te środki kontroli ryzyka są całkowicie niewystarczające, by zapobiec zagrożeniom.

Jest to rażąca wada systemu kierowania transakcji oraz mechanizmów kontroli ryzyka, która bezpośrednio przekształciła legalną i zgodną z przepisami operację wymiany zabezpieczeń w katastrofalną stratę aktywów.