50 мільйонів USDT обміняно на 35,000 USD AAVE: Як сталася катастрофа? Кого ми повинні звинувачувати?

Ця стаття з: @Ehsan1579

Складено: Ітан, Odaily Planet Daily

Просто дивлячись на назву події, можна помилково подумати, що це випадок атаки на вразливість.

Суть події: хтось обміняв USDT на суму 50.4 мільйона доларів на AAVE вартістю лише 35,900 доларів.

Я був справді шокований, коли вперше почув про це. Тому я ретельно переглянув всю подію: відстеження транзакцій, шляхи розв'язувачів, виклики контрактів, історичні резерви, дані про розрахунки, процеси адаптерів, код інтерфейсу Aave, SDK позики CoW та код маршрутизації, який визначає, чи є котирування "розумним".

Це не атака хакера. Основний протокол Aave не зробив помилки. CoW розрахунок не зробив помилки. Uniswap не зробив помилки. SushiSwap не зробив помилки. Транзакція була дійсною, підпис була дійсною, і всі контракти виконувалися строго відповідно до коду. Однак майже вся економічна цінність була знищена просто тому, що маршрутизація, яку їй дозволили пройти, була абсурдно нерозумною.

Публічний ланцюг не мав проблем; проблема була в маршрутизації.

На мою думку, зменшення значення цього інциденту до "операційної помилки користувача" не є об'єктивною або суворою позицією. Дійсно, користувач завершив підписання замовлення, але вся програмна система дозволила операцію, що стосується майже 50 мільйонів доларів застави, завершити котирування, підпис, планування маршруту та остаточне виконання, все вказуючи на низький пул ліквідності, що містить лише близько 331 AAVE. Це мало бути абсолютно неможливо, і принаймні це мало бути рішуче перехоплено та відхилено системою до початку етапу розрахунків.

Основна інформація про трасування транзакції

Хеш цієї аномальної транзакції: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, підтверджено 12 березня 2026 року, на висоті блоку основної мережі Ethereum 24643151, з індексом транзакції 1, споживаючи 3,780,570 одиниць газу, і транзакція виконана успішно. Адреса гаманця, що належить замовленню, починається з 0x98b9, тоді як адреса фактичного виконавця (відправника транзакції) починається з 0x3980, позначена як tsolver у даних конкурсу CoW.

По-перше, важливо зрозуміти, що це не простий обмін USDT на AAVE на рівні гаманця. Токен, що продається, є aEthUSDT, який є сертифікатом депозиту USDT з відсотками на платформі Aave. Токен, що купується, є aEthAAVE, який є сертифікатом депозиту AAVE з відсотками на платформі Aave. Отже, це насправді обмін застави Aave, проведений через систему розрахунків протоколу CoW та процес адаптера миттєвих кредитів.

Перед транзакцією гаманець утримував приблизно 50,432,693.075254 aEthUSDT та 0 aEthAAVE. Після транзакції в ньому залишилося лише 4.980399 aEthUSDT і він отримав 327.241335505966487788 aEthAAVE. Насправді, гаманець продав майже всю свою позицію.

Метадані більш чітко вказують на те, що маршрутизація вже була "токсичною" до виконання. Замовлення надійшло з процесу aave-v3-interface-collateral-swap. API CoW відобразив його як підписане замовлення на продаж, тоді як метадані програми позначили його як обмін застави в стилі ринку з використанням 121 базисного пункту розумного зсуву. Підписана сума продажу становила 50,432,688.41618 aEthUSDT. Підписана мінімальна сума покупки становила 324.949260918413591035 aEthAAVE. Фактичний розрахунок склав 327.241335505966487788 aEthAAVE.

Це надзвичайно важлива деталь. Замовлення не очікувало отримати тисячі AAVE, лише щоб бути якимось чином знищеним на півдорозі. З самого початку воно було побудоване навколо результату понад триста AAVE.

Повна ланка колапсу маршрутизації

Як тільки ви слідкуєте за відстеженням транзакцій, весь процес є жорстко простим.

Капітальний потік верхнього рівня залежить від контракту розрахунків GPv2Settlement протоколу CoW, починаючи з 0x9008. По-перше, контракт HooksTrampoline, починаючи з 0x60bf, завершує операцію авторизації aEthUSDT, дозволяючи релейеру скарбниці CoW витягувати активи користувачів без окремої авторизації транзакції; потім контракт GPv2VaultRelayer, починаючи з 0xc92e, витягує 50,432,688.41618 aEthUSDT з гаманця користувача в процес розрахунків. До цього моменту всі операції відповідають нормальній логіці.

Потім контракт розрахунків надає авторитет операцій aEthUSDT неперевіреному допоміжному контракту, починаючи з 0xd524, і ініціює виклик через селектор функції 0x494b3137; цей допоміжний контракт потім передає авторитет виконання неперевіреному контракту виконавця, починаючи з 0x699c, в той момент повна картина аномальної маршрутизації транзакцій повністю розкривається.

Перший ефективний виклик вказує на контракт ліквідності Aave, починаючи з 0x87870, який знищує aEthUSDT через функцію виведення (селектор 0x69328dec), щоб викупити основний рідний USDT; потім маршрутизація переходить до глибокого торгового пулу USDT/WETH Uniswap V3, починаючи з 0x4e68, обмінюючи всі 50,432,688.41618 USDT на 17,957.810805702142342238 WETH.

Транзакція на цьому етапі є абсолютно нормальною: обмінний курс становить близько 2808.4 USDT за 1 WETH, що відповідає ринку на той момент, без проблем з нестачею ліквідності та без відхилень у розрахунках; перше посилання транзакції не має аномалій.

Проблема виникає на другому переході; як тільки ви бачите резерви ліквідності, решта історії є неминучою.

Після того, як виконавець отримує 17,957.810805702142342238 WETH, він передає всі кошти до торгового пулу SushiSwap V2 AAVE/WETH за адресою 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Я перевірив історичні дані резервів ліквідності цього торгового пулу безпосередньо перед тим, як сталася аномальна транзакція (висота блоку 24643150), і пул утримував лише:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

Це не помилка введення даних, а залізний факт.

Ця маршрутизація транзакцій вливала майже 17,958 WETH повністю в мікро торговий пул, який резервує лише 17.65 WETH, що відповідає загальному запасу AAVE лише 331.63 AAVE, при цьому обсяг введеного WETH становить приблизно 1017 разів більше, ніж резерви WETH пулу.

Це не "висока сліпучість" або "трохи тонка ліквідність" загальна проблема, а надзвичайно абсурдний шлях виконання ринкового замовлення, еквівалентний примушенню дуже маленького постійного продукту AMM пулу здійснити транзакцію в тисячі разів більше, ніж його власна потужність.

Торговий пул AMM виконав операцію відповідно до встановленого алгоритму, майже вичерпавши всі резерви AAVE в пулі.

Торговий пар SushiSwap викликав основну подію обміну Swap: виконавець передав 17,957.810805702142342238 WETH, отримавши назад лише 331.305315608938235428 AAVE. Після транзакції залишкова ліквідність у пулі становила приблизно:

0.326666929169791895 AAVE, 17,975.464081898540030304 WETH

Простими словами, близько 99.9% резервів AAVE в пулі були вичерпані за один хід.

Виходячи з резервів до транзакції, імпліцитна ціна AAVE в пулі становила близько 149.50 доларів. Фактична ціна виконання користувача становила близько 154,114.66 USDT за 1 AAVE. Це більше ніж у 1000 разів відрізняється від спотової ціни до транзакції.

Потім ці AAVE були повернуті в пул ліквідності Aave, використовуючи селектор 0x617ba037, тобто supply(address,uint256,address,uint16). Результатом стало те, що новостворений aEthAAVE був повернутий до контракту розрахунку. Контракт розрахунку в кінцевому підсумку передав 327.241335505966487788 aEthAAVE користувачу. Приблизно 4.06398010297174764 aEthAAVE залишилися в контракті розрахунку як надлишок від того, що заплатив користувач.

Таким чином, розрахунок не спотворив раптово хороший результат виконання в поганий. Він лише завершив результат, який вже був отриманий маршрутизацією.

Це ключовий момент, який варто чітко зазначити: катастрофічний результат вже був "попередньо налаштований" в маршрутизації до виконання.

У допоміжних даних виклику контракту, вбудованих в маршрутизацію, цільова купівельна сума на стороні покупки становила близько 331.272185078031026739, мінімальна купівельна сума, погоджена користувачем, становила 324.949260918413591035, а фактична сума розрахунку становила 327.241335505966487788, при цьому всі основні значення були зафіксовані на рівні понад триста AAVE до розрахунку.

Ця маршрутизація була поганою.

Де недолік?

Відповідь: кожен рівень механізму перевірки системи перевіряє неправильний вимір.

Усі рівні лише перевіряють, чи транзакція є виконуваною, чи підпис є дійсним, чи сума є ненульовою, але майже немає основного рівня, який перевіряє, чи є маршрутизація транзакції економічно обґрунтованою, що є основною причиною збою механізму.

Дефект коду в адаптері інтерфейсу Aave Quote Path

Перша очевидна точка аномалії коду з'являється в процесі цитування адаптера CoW інтерфейсу Aave: функція, яка спочатку використовувалася для прикріплення специфічних для адаптера даних програми під час запиту цитати, була безпосередньо змушена бути відключеною.

Джерело: rates.helpers.ts:93 та adapters.helpers.ts:194

Це означає, що коли інтерфейс Aave запитує котирування у CoW, він не прикріплює метадані про флеш-кредит і хуки, які насправді були б включені при розміщенні замовлення. Інакше кажучи, те, що котується, не зовсім те, що має бути виконано. Коментарі в коді навіть вказують, що мета цієї допоміжної функції полягає в тому, щоб зробити котирування адаптера більш точними, але ця функція була примусово відключена.

Слабке визначення розумності в логіці конкуренції котирувань CoW (основний недолік)

Друга і найсерйозніша проблема полягає в логіці конкуренції котирувань протоколу CoW: у його публічному коді, доки плата за газ котирування є позитивною, а обсяг виходу ненульовим, це буде вважатися "розумним котируванням."

Джерело: quote.rs:31

Для системи маршрутизації, що обробляє замовлення з восьмизначними цифрами, це шокуюче слабке визначення "розумності."

Система не інтегрувала оракулів для перевірки звуковості цін, не мала механізму перехоплення для "котирувань, що відхиляються від спотової ціни більш ніж на 500 разів," не проводила оцінку ризиків для "маршрутизації, що повністю виснажує ліквідні пулі," і не надавала попередження для "останніх гопів ліквідності, які серйозно не відповідають масштабам замовлення;" вона лише вимагала, щоб розв'язувач повернув виконуваний, ненульовий план маршрутизації, який буде прийнятий системою, це основний недолік цього інциденту.

Недоліки в логіці моделювання ліквідності стилю Uniswap V2

Третя проблема полягає в підході до моделювання ліквідності пулу стилю Uniswap V2: код використовує лише стандартний алгоритм постійного продукту, відхиляючи лише математично неможливі ситуації, такі як нульові резерви, недоповнення та переповнення, не проводячи перевірки економічної доцільності.

Джерело: pool_fetching.rs:118 та pool_fetching.rs:153

Цей сегмент коду не визначає, чи достатній розмір ліквідного пулу для розміщення відповідної транзакції маршрутизації; він лише перевіряє, чи є операція обміну математично дійсною. Отже, навіть мікропул з лише 331 резервами AAVE буде вважатися дійсним місцем для розміщення запиту на купівлю 17,957 WETH, просто тому, що алгоритм постійного продукту може дати ненульовий результат, повністю ігноруючи катастрофічні втрати активів, які цей результат викликав би.

Вторинний збій SDK флеш-кредиту та механізму перевірки замовлень

Потім SDK флеш-кредиту безпосередньо закріпив це недійсне котирування в замовленні та навантаженні виконання хуків без будь-якого вторинного перехоплення ризику.

Тоді:

Джерело: index.js:484 та index.js:591

Ось чому я завжди говорив, що ця маршрутизація "народилася поганою." Шар адаптера не "виявив" нову погану суму під час виконання. Він серіалізував вже котовану погану суму в дані хуків і визначив адресу екземпляра. Якщо існує погане цитування, залишкові механізми вірно передадуть його далі.

Навіть логіка перевірки замовлень CoW тут не захистила користувача, оскільки вона лише перевіряє, чи перевищує замовлення ринкову ціну на момент цитування, не перевіряючи, чи є саме цитування абсурдним відносно фактичної ліквідності.

Джерело: order_validation.rs:694

Це перевірка на узгодженість. Якщо саме цитування вже є безглуздим, замовлення все ще може пройти.

Механізм попередження інтерфейсу UI є неефективним

Інтерфейс Aave дійсно має попередження про великий вплив на ціну, але це не жорсткий автоматичний вимикач. Коли втрата вартості перевищує 20%, це стає чекбоксом підтвердження.

Якщо користувач відмічає чекбокс, бар'єр знімається:

Джерело: helpers.ts:24 та HighPriceImpactWarning.tsx:35

Отже, навіть якщо ця транзакція майже спустошить всю вартість активів, система лише вважала це операцією, що потребує підтвердження користувача, а не високоризиковою транзакцією, яку система повинна рішуче відхилити, і механізм попередження повністю втратив свою функцію перехоплення ризику.

Виходячи з усіх вищезазначених збоїв механізмів, я абсолютно не погоджуюсь з зневажливим висновком, що "це просто дурість користувача." Користувач дійсно завершив підпис, але вся програмна система мала безліч можливостей перехопити цю катастрофу, проте кожен рівень лише виконував базові перевірки, визначаючи "ненульовий, виконуваний, підписаний," і безпосередньо випустив його, в результаті чого виникли катастрофічні наслідки.

Маршрутизація не була підроблена

Цей розділ є вирішальним, безпосередньо виключаючи велику кількість помилкових спекуляцій: офіційний інтерфейс Aave, що відповідає aave-v3-interface-collateral-swap, розрахує кількість покупки з урахуванням ковзання на рядку 139 файлу useSwapOrderAmounts.ts, поєднуючи цитування, мережеві збори, збори партнерів та збори за миттєвий кредит; рядок 331 перетворює його на значення buyAmountBigInt; потім на рядку 191 файлу CollateralSwapActionsViaCoWAdapters.tsx ця сума точно підписується.

Наступні контракти адаптерів перевірять, що підписані поля замовлення повністю відповідають збереженим значенням на рядку 141 файлу AaveV3BaseAdapter.sol; контракт розрахунку CoW забезпечить дотримання підписаних узгоджених обмежень на рядку 337 файлу GPv2Settlement.sol. Отже, результат виконання в ланцюгу не перевищив межі, дозволені підписаним замовленням, а активи, які користувач фактично отримав, були навіть вище мінімального ліміту, узгодженого в підписі.

Цього достатньо, щоб довести: катастрофа сталася до етапу розрахунку, а не під час процесу розрахунку; фатальний недолік у маршрутизації вже заздалегідь визначив результат.

Куди пішла зникла вартість?

Наступна транзакція в тому ж блоці (хеш, що починається з 0x45388b0f) завершила арбітраж зворотного запуску проти пошкодженого пулу SushiSwap AAVE/WETH. Після того, як аномальна транзакція заповнила пул величезною кількістю WETH і висмоктала більшість AAVE, арбітражник негайно продав AAVE назад у пул, збираючи надлишкову вартість, принесену дисбалансом ліквідності.

Цей арбітраж зворотного запуску витягнув близько 17,929.770158685933 WETH, потім сплатив близько 13,087.73 ETH блоковому будівельнику та близько 4,824.31 ETH адресі виконання арбітражу.

Уся економічна вартість, втрачена користувачем, врешті-решт була майже миттєво перетворена на прибутки від MEV арбітражу та прибутки блокового будівельника в межах одного блоку.

Крім того, перевірка часової послідовності на рівні блоку підтверджує: ніхто зловмисно не маніпулював торговим пулом SushiSwap, щоб встановити пастку для користувачів; торгову пару AAVE/WETH вперше торкнулася ця аномальна транзакція (індекс транзакції 1); негайно наступна транзакція (індекс транзакції 2) завершила перший зворотний запуск проти спотворення ціни, викликаного цією транзакцією; індекс транзакції 3 також торкнувся цієї торгової пари під час процесу корекції ринку. Хронологія чітко підтверджує: ця аномальна транзакція створила екстремальне спотворення ціни, а наступні транзакції безпосередньо зібрали цей спотворений прибуток.

Отже, чия це провина?

Якщо ви запитаєте, чи впав основний протокол Aave V3, відповідь - ні. Ліквідний пул Aave виконав операції повністю відповідно до інструкцій, успішно завершивши процес викупу USDT та депозиту AAVE.

Якщо ви запитаєте, чи впав контракт GPv2Settlement CoW, відповідь - ні. Розрахунок забезпечив дійсний підписаний наказ і сплатив суму, що перевищує мінімальний ліміт, погоджений у підписі.

Якщо ви запитаєте, чи впали контракти торгових пар Uniswap V3 або SushiSwap, відповідь також ні. Обидва типи торгових пулів завершили ціноутворення транзакцій відповідно до своїх власних алгоритмічних правил.

Справжня системна помилка сталася на вищих рівнях маршрутизації та контролю ризиків:

первинна відповідальна сторона - це модулі маршрутизації, котирування та розв'язання протоколу CoW: критерії визначення "розумної маршрутизації" для всієї системи занадто слабкі, що дозволяє багатомільйонним замовленням врешті-решт потрапляти до мікро-пулів з низькою ліквідністю, оскільки маршрутизація є виконуваною та ненульовою, вона приймається, повністю ігноруючи екстремальну безглуздість на економічному рівні.

вторинна відповідальна сторона - це фронтальний інтерфейс Aave: він не прикріпив дані програми, пов'язані з гачком, під час запиту котирувань адаптера, безпосередньо передаючи помилкові результати в процес підписання, і покладався лише на попередження без механізму жорсткого відхилення. Для таких екстремально великих транзакцій ці заходи контролю ризиків абсолютно недостатні для запобігання ризикам.

Це екстремальна помилка якості маршрутизації транзакцій та бар'єрів контролю ризиків, що безпосередньо перетворює легітимну та відповідну операцію обміну застави на катастрофічну подію втрати активів.