50 млн USDT обменяно на 35 тыс. AAVE в инциденте с протоколом Aave CoW

Этот текст взят из: @Ehsan1579

Сборка｜ Odaily Planet Daily (@OdailyChina); Переводчик｜ Ethan (@ethanzhang_web3

По одному заголовку события можно с уверенностью предположить, что это атака с использованием уязвимости.

Суть события в том, что кто-то обменял USDT на сумму 50,4 миллиона долларов США, в итоге получив всего AAVE на сумму 35 900 долларов США.

Когда я впервые услышал об этом, я был по-настоящему потрясен. Поэтому я полностью проанализировал всю ситуацию: отслеживание транзакций, путь решателя, вызовы смарт-контрактов, исторические резервы, данные по расчетам, процессы адаптеров, код интерфейса Aave, SDK CoW Flash Loan и код маршрутизации для определения, является ли报价 «разумным».

Это не была хакерская атака. Основной протокол Aave не имел ошибок. CoW-расчет прошел корректно. Uniswap не имел ошибок. SushiSwap не имел ошибок. Транзакции были действительными, подписи были действительными, и все смарт-контракты строго выполнили код. Однако почти вся экономическая ценность была уничтожена только потому, что ей разрешили пройти через абсурдный маршрут.

Проблема не в публичной цепочке, а в маршрутизации.

На мой взгляд, сводить это дело к простой «ошибке пользователя» — это необъективный и непрофессиональный подход. Хотя пользователь и подписал заказ, вся программная система позволила операции по замене залога на сумму почти 50 миллионов долларов США пройти весь путь — от формирования цены и подписи до планирования маршрута и финального исполнения — и все этапы вели к ликвидному пулу, содержащему всего около 331 AAVE. Такое вообще не должно было произойти; по крайней мере, система должна была жестко заблокировать операцию еще до начала расчетов.

Хэш аномальной транзакции: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, подтвержденный на блоке 24643151 Ethereum Mainnet 12 марта 2026 года, индекс транзакции 1, потреблено 3780570 единиц газа, транзакция выполнена успешно. Адрес кошелька, к которому относится заказ, начинается с 0x98b9, а адрес решателя (отправителя транзакции), фактически выполнившего транзакцию, начинается с 0x3980 и помечен как tsolver в данных CoW Competition.

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

Перед сделкой кошелек содержал примерно 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 с адресом, начинающимся на 0x9008, на основе протокола CoW. Сначала контракт HooksTrampoline с адресом, начинающимся на 0x60bf, выполняет авторизацию aEthUSDT, позволяя ретранслятору CoW-казны извлекать активы пользователей без отдельной авторизации транзакций; затем контракт GPv2VaultRelayer с адресом, начинающимся на 0xc92e, извлекает 50432688.41618 единиц aEthUSDT из кошелька пользователя в процессе расчета. На данном этапе все операции соответствуют нормальной логике.

Сетлмент-контракт затем передает права на операции с aEthUSDT вспомогательному контракту, начинающемуся с 0xd524, и инициирует вызов через селектор функции 0x494b3137; этот вспомогательный контракт передает права на выполнение исполнительному контракту, начинающемуся с 0x699c, в результате чего полная картина аномального маршрута торговли полностью раскрывается.

Первый действительный вызов направлен на контракт пула Aave, начинающийся с 0x87870, через функцию withdraw (селектор 0x69328dec) происходит уничтожение aEthUSDT и выкуп базового нативного USDT; затем маршрутизация перенаправляется в глубокий торговый пул Uniswap V3, начинающийся с 0x4e68, где все 50432688.41618 USDT обмениваются на 17957.810805702142342238 WETH.

На этом этапе торговля прошла полностью нормально: обменный курс составлял примерно 2808,4 USDT за 1 WETH, что соответствовало рыночной ситуации в тот момент, отсутствовали проблемы с ликвидностью и расчетные погрешности, а первая цепочка торговой транзакции не содержала никаких аномалий.

Проблема возникает на втором переходе: как только вы видите резервы ликвидности, остальная часть истории неизбежна.

После получения 17957.810805702142342238 WETH исполнитель перевел все средства на адрес 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4 в пул ликвидности SushiSwap V2 AAVE/WETH.

Я проверил исторические данные о резервах ликвидности этого пула на момент непосредственно перед возникновением аномальной транзакции (высота блока 24643150): в пуле находились только:

331,631982538108027323 AAVE, 17,653276196397688066 WETH

Это не ошибка ввода данных, а неоспоримый факт.

Этот маршрут торговли направил почти 17 958 WETH в мини-пул с резервом всего 17,65 WETH и общим запасом AAVE в 331,63 WETH — объем вводимых WETH в около 1017 раз превышает резерв WETH в пуле.

Это не обычная проблема «высокого проскальзывания» или «недостаточной ликвидности», а крайне абсурдный путь исполнения рыночного ордера, равносильный принуждению чрезвычайно маленького AMM-пула с постоянным произведением принять сделку, превышающую его собственный объем в тысячи раз.

AMM-пул выполнил операцию в соответствии с заданным алгоритмом, почти исчерпав все резервы AAVE в пуле.

SushiSwap торговая пара вызвала событие обмена Core Swap: исполнитель перевел 17957.810805702142342238 WETH и получил обратно только 331.305315608938235428 AAVE. После завершения сделки оставшаяся ликвидность в пуле составляет примерно:

0.326666929169791895 AAVE, 17975.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 до расчета.

This route has been bad from birth.

Ответ: механизм проверки на каждом уровне системы проверяет ошибки по различным параметрам.

Все уровни проверяют только возможность выполнения сделки, действительность подписи и ненулевую сумму, но почти не проверяют экономическую обоснованность маршрутизации сделки на основном уровне — это основная причина сбоя механизма.

Уязвимость в коде пути报价 адаптера интерфейса Aave

Первая очевидная точка аномалии в коде возникает в процессе предложения CoW-адаптера на интерфейсе Aave: функция, ранее используемая для передачи специфических данных приложения адаптера при запросе предложения, была напрямую отключена.

Источник: rates.helpers.ts:93 и adapters.helpers.ts:194

Это означает, что интерфейс Aave при запросе предложения у CoW не прикрепляет метаданные о молниеносных кредитах и хуках, которые будут добавлены при фактической публикации ордера. Другими словами, то, что предлагается, не совсем то, что будет исполнено. Комментарии в коде даже указывают, что цель этой вспомогательной функции — сделать предложения адаптера более точными, однако эта функция была жестко отключена.

Логика оценки обоснованности предложений CoW слишком слаба (ключевая уязвимость)

Вторая и самая серьезная проблема заключается в логике конкуренции предложений протокола CoW: в его общедоступном коде любое предложение с положительной комиссией за газ и ненулевой суммой вывода считается «разумным предложением».

Источник: quote.rs:31

Для системы маршрутизации, обрабатывающей заказы с восемью цифрами, это поразительно слабое определение «разумности».

Система не подключена к оракулу для проверки ценовой целостности, не имеет механизма блокировки при отклонении报价 от спотовой цены более чем в 500 раз, не определяет риск полного высасывания ликвидности маршрутом и не выдает предупреждение о серьезном несоответствии ликвидности последнего звена и объема ордера; система принимает любой маршрут, возвращенный решателем, если он исполняем и ненулевой — это основная уязвимость данного инцидента.

Defects in the liquidity modeling logic of Uniswap V2

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

Источник: pool_fetching.rs:118 и pool_fetching.rs:153

Этот код не проверяет, достаточно ли объем ликвидности для выполнения соответствующей маршрутизированной сделки, а только определяет, является ли операция обмена математически корректной. Таким образом, даже микропул с резервом всего 331 AAVE будет признан подходящим для выполнения запроса на покупку 17957 WETH, поскольку алгоритм постоянного произведения выдает ненулевой результат, полностью игнорируя, что такой результат приведет к катастрофической потере активов.

Второй сбой в SDK для молниеносных кредитов и механизме проверки заказов

Затем SDK для молниеносных кредитов напрямую встроил этот недействительный ордер в нагрузку выполнения ордера и хука, не проведя никакой дополнительной блокировки рисков.

Далее:

Источник: index.js:484 и index.js:591

Вот почему я всегда говорил, что этот маршрут «изначально испорчен». Уровень адаптера не «обнаруживает» новую плохую сумму во время выполнения — он сериализует уже указанную плохую сумму в данные хука и определённый адрес экземпляра. Как только плохое предложение существует, остальные механизмы безоговорочно передают его дальше.

Даже логика проверки заказов CoW здесь не защищает пользователей, поскольку она проверяет только, не превышает ли заказ рыночную цену на момент предложения, но не оценивает, является ли само предложение абсурдным по сравнению с фактической ликвидностью.

Источник: order_validation.rs:694

Это проверка на согласованность. Если сама котировка уже бессмысленна, заказ всё равно может быть выполнен.

Механизм предупреждения на пользовательском интерфейсе не работает

Интерфейс 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 обратно в пул, извлекая сверхприбыль из дисбаланса ликвидности.

В ходе этой арбитражной операции было извлечено примерно 17929.770158685933 WETH, после чего было выплачено примерно 13087.73 ETH строителю блока и примерно 4824.31 ETH адресу исполнения арбитража.

Вся экономическая стоимость потерь пользователей в конечном итоге почти мгновенно преобразуется в доходы от MEV-арбитража и доходы создателей блоков в том же блоке.

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

Если вы спрашиваете, сломался ли основной протокол Aave V3, ответ — нет. Фонды Aave полностью выполнили команды и корректно завершили процесс выкупа USDT и внесения AAVE.

Если вы спрашиваете, сломался ли контракт GPv2Settlement CoW, ответ — нет. Система выполнила расчет действительного заказа с подписью и выплатила сумму, превышающую минимально указанную в подписи.

Если вы спрашиваете, сломались ли контракты торговых пар Uniswap V3 или SushiSwap, ответ также отрицательный. Оба типа пулов выполняют ценообразование в соответствии со своими собственными алгоритмическими правилами.

Системный сбой произошел на более высоком уровне маршрутизации и управления рисками:

Основная ответственность лежит на модулях маршрутизации, котировок и решателя CoW Protocol: вся система имеет слишком слабые критерии для определения «разумного маршрута», допуская огромные ордера в миллионы долларов, которые в итоге попадают в микроскопические пулы с низкой ликвидностью, при этом принимая любой маршрут, который может быть выполнен и не является нулевым, полностью игнорируя экономическую неразумность.

Вторичная ответственность лежит на интерфейсе Aave: при запросе报价 адаптера не передавались данные приложения, связанные с хуком, ошибочные результаты напрямую передавались в процесс подписи, а для защиты использовались только предупреждения без жестких механизмов блокировки; для таких экстремально крупных транзакций таких мер риск-менеджмента совершенно недостаточно.

Это был крайний провал качества маршрутизации сделок и систем защиты от рисков, который превратил законную и соответствующую нормам операцию по замене залога в катастрофическое событие потери активов.