50 milhões de USDT trocados por 35.000 USD AAVE: Como o desastre aconteceu? Quem devemos culpar?

Este artigo é de: @Ehsan1579

Compilado por: Ethan, Odaily Planet Daily

Apenas olhando para o título do evento, alguém pode erroneamente pensar que se trata de um caso de exploração de vulnerabilidade.

O cerne do evento é: alguém trocou USDT no valor de $50,4 milhões por AAVE no valor de apenas $35.900.

Fiquei realmente chocado quando ouvi sobre isso pela primeira vez. Portanto, revisei minuciosamente todo o evento: rastreamento de transações, caminhos de solução, chamadas de contrato, reservas históricas, dados de liquidação, processos de adaptador, código da interface Aave, SDK de empréstimo flash CoW e o código de roteamento que determina se a cotação é "razoável."

Isso não é um ataque de hacker. O protocolo Aave central não cometeu um erro. A liquidação CoW não cometeu um erro. A Uniswap não cometeu um erro. A SushiSwap não cometeu um erro. A transação era válida, a assinatura era válida e todos os contratos foram executados estritamente de acordo com o código. No entanto, quase todo o valor econômico foi destruído simplesmente porque o roteamento que foi permitido seguir era absurdamente irracional.

A cadeia pública não teve um problema; o problema estava no roteamento.

Na minha opinião, minimizar este incidente como meramente um "erro operacional do usuário" não é uma atitude objetiva ou rigorosa. De fato, o usuário completou a assinatura do pedido, mas todo o sistema de software permitiu uma operação envolvendo quase $50 milhões em colateral para completar a cotação, assinatura, planejamento de roteamento e execução final, tudo apontando para um pool de baixa liquidez que detinha apenas cerca de 331 AAVE. Isso deveria ter sido completamente impossível e, pelo menos, deveria ter sido firmemente interceptado e rejeitado pelo sistema antes que a fase de liquidação fosse iniciada.

Rastreamento de Informações Principais da Transação

O hash desta transação anômala é: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmado em 12 de março de 2026, na altura do bloco 24643151 da rede principal Ethereum, com índice de transação 1, consumindo 3.780.570 unidades de gás, e a transação foi executada com sucesso. O endereço da carteira pertencente ao pedido começa com 0x98b9, enquanto o endereço do solucionador que realmente executou (remetente da transação) começa com 0x3980, marcado como tsolver nos dados da competição CoW.

Primeiro, é importante entender que isso não é uma simples troca de USDT para AAVE a nível de carteira. O token vendido é aEthUSDT, que é o certificado de depósito de USDT que gera juros na plataforma Aave. O token comprado é aEthAAVE, que é o certificado de depósito de AAVE que gera juros na plataforma Aave. Portanto, isso é na verdade uma troca de colateral de Aave realizada através do sistema de liquidação do protocolo CoW e seu processo de adaptador de empréstimo relâmpago.

Antes da transação, a carteira possuía aproximadamente 50.432.693,075254 aEthUSDT e 0 aEthAAVE. Após a transação, restou apenas 4,980399 aEthUSDT e recebeu 327,241335505966487788 aEthAAVE. Na verdade, a carteira vendeu quase toda a sua posição.

Os metadados indicam mais claramente que o roteamento já era "tóxico" antes da execução. O pedido veio do processo aave-v3-interface-collateral-swap. A API do CoW exibiu isso como uma ordem de venda assinada, enquanto os metadados da aplicação marcaram como uma troca de colateral em estilo de mercado usando 121 pontos base de deslizamento inteligente. O valor de venda assinado foi de 50.432.688,41618 aEthUSDT. O valor mínimo de compra assinado foi de 324,949260918413591035 aEthAAVE. A liquidação real pagou 327,241335505966487788 aEthAAVE.

Este é um detalhe extremamente importante. A ordem não esperava obter milhares de AAVE, apenas ser de alguma forma destruída no meio do caminho. Desde o início, foi construída em torno de um resultado de mais de trezentos AAVE.

Link Completo do Colapso de Roteamento

Uma vez que você segue o rastreamento da transação, todo o processo é brutalmente simples.

O fluxo de capital de alto nível depende do contrato de liquidação GPv2Settlement do protocolo CoW começando com 0x9008. Primeiro, o contrato HooksTrampoline começando com 0x60bf completa a operação de autorização aEthUSDT, permitindo que o relayer do tesouro CoW extraia ativos do usuário sem autorização de transação separada; em seguida, o contrato GPv2VaultRelayer começando com 0xc92e extrai 50.432.688,41618 aEthUSDT da carteira do usuário para o processo de liquidação. Até este ponto, todas as operações estão em conformidade com a lógica normal.

O contrato de liquidação então concede autoridade de operação aEthUSDT a um contrato auxiliar não verificado começando com 0xd524 e inicia uma chamada via seletor de função 0x494b3137; este contrato auxiliar então transfere a autoridade de execução para um contrato executor não verificado começando com 0x699c, momento em que a imagem completa do roteamento de transação anômala é completamente exposta.

A primeira chamada efetiva aponta para o contrato do pool de liquidez Aave começando com 0x87870, que destrói aEthUSDT através da função de retirada (seletor 0x69328dec) para resgatar o USDT nativo subjacente; em seguida, o roteamento salta para o pool de negociação Uniswap V3 profundo USDT/WETH começando com 0x4e68, trocando todos os 50.432.688,41618 USDT por 17.957,810805702142342238 WETH.

A transação neste estágio é completamente normal: a taxa de câmbio é de cerca de 2808,4 USDT por 1 WETH, consistente com o mercado na época, sem problemas de escassez de liquidez e sem desvios de cálculo; o primeiro link de transação não apresenta anomalias.

O problema surge no segundo salto; uma vez que você vê as reservas de liquidez, o resto da história é inevitável.

Depois que o executor obtém 17.957,810805702142342238 WETH, ele transfere todos os fundos para o pool de negociação SushiSwap V2 AAVE/WETH no endereço 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Eu verifiquei os dados históricos de reserva de liquidez deste pool de negociação logo antes da transação anômala ocorrer (altura do bloco 24643150), e o pool tinha apenas:

331,631982538108027323 AAVE, 17,653276196397688066 WETH

Isso não é um erro de entrada de dados, mas um fato inegável.

Esse roteamento de transação injetou quase 17.958 WETH inteiramente em um micro pool de negociação que reserva apenas 17,65 WETH, correspondendo a um estoque total de AAVE de apenas 331,63 AAVE, com o volume de WETH de entrada sendo cerca de 1017 vezes as reservas de WETH do pool.

Isso não é um problema comum de "alta slippage" ou "liquidez levemente fina", mas um caminho de execução de ordem de mercado extremamente absurdo, equivalente a forçar um pool AMM de produto constante muito pequeno a realizar uma transação em escala milhares de vezes além de sua própria capacidade.

O pool de negociação AMM executou a operação de acordo com o algoritmo estabelecido, quase esgotando todas as reservas de AAVE no pool.

O par de negociação SushiSwap acionou o evento central de troca Swap: o executor transferiu 17.957,810805702142342238 WETH, recebendo de volta apenas 331,305315608938235428 AAVE. Após a transação, a liquidez restante no pool era aproximadamente:

0.326666929169791895 AAVE, 17.975,464081898540030304 WETH

Em termos simples, cerca de 99,9% das reservas de AAVE na pool foram drenadas em um único salto.

Com base nas reservas antes da transação, o preço implícito do AAVE na pool era de cerca de $149,50. O preço de execução real do usuário foi de cerca de 154.114,66 USDT por 1 AAVE. Isso é mais de 1000 vezes diferente do preço à vista antes da transação.

Subsequentemente, esses AAVE foram fornecidos de volta à pool de liquidez Aave, usando o seletor 0x617ba037, ou seja, supply(address,uint256,address,uint16). O resultado foi que o aEthAAVE recém-emitido foi enviado de volta ao contrato de liquidação. O contrato de liquidação acabou transferindo 327.241335505966487788 aEthAAVE para o usuário. Cerca de 4.06398010297174764 aEthAAVE permaneceram no contrato de liquidação como excedente em relação ao que o usuário pagou.

Assim, a liquidação não distorceu repentinamente um bom resultado de execução em um ruim. Ela apenas finalizou o resultado que o roteamento já havia produzido.

Este é um ponto chave que vale a pena afirmar claramente: o resultado desastroso já estava "pré-definido" no roteamento antes da execução.

Nos dados da chamada do contrato auxiliar incorporados no roteamento, a quantidade alvo de compra no lado da compra era de cerca de 331.272185078031026739, a quantidade mínima de compra acordada pelo usuário era de 324.949260918413591035, e a quantidade real de liquidação era de 327.241335505966487788, com todos os valores principais bloqueados em mais de trezentos AAVE antes da liquidação.

Esse roteamento nasceu ruim.

Onde está a falha?

A resposta é: cada camada do mecanismo de verificação do sistema está checando a dimensão errada.

Todos os níveis apenas verificam se a transação é executável, se a assinatura é válida, se a quantidade é diferente de zero, mas quase não há verificação em nível central se o roteamento da transação é economicamente razoável, que é a raiz central da falha do mecanismo.

Defeito de Código no Adaptador de Interface Aave Quote Path

O primeiro ponto óbvio de anomalia de código aparece no processo de citação do adaptador CoW da interface Aave: a função originalmente usada para anexar dados de aplicação específicos do adaptador ao solicitar uma citação foi forçada a ser desativada.

Fonte: rates.helpers.ts:93 e adapters.helpers.ts:194

Isso significa que quando a interface Aave solicita uma cotação do CoW, ela não anexa o empréstimo relâmpago e os metadados do hook que realmente estariam incluídos ao fazer um pedido. Em outras palavras, o que está sendo cotado não é inteiramente o que deve ser executado. Os comentários do código até afirmam que o propósito desta função auxiliar é tornar as cotações do adaptador mais precisas, no entanto, essa função foi desativada à força.

Determinação de Razoabilidade Fraca na Lógica de Competição de Cotações do CoW (Falha Principal)

O segundo e mais sério problema reside na lógica de competição de cotações do protocolo CoW: em seu código de serviço público, desde que a taxa de gás da cotação seja positiva e a quantidade de saída seja não zero, será considerada uma "cotação razoável."

Fonte: quote.rs:31

Para um sistema de roteamento que lida com pedidos de oito dígitos, essa é uma definição surpreendentemente fraca de "razoabilidade."

O sistema não integrou oráculos para verificações de solidez de preços, não tinha mecanismo de interceptação para "cotações que se desviam do preço à vista em mais de 500 vezes," nenhuma avaliação de risco para "roteamento que drena completamente os pools de liquidez," e nenhum aviso para "última liquidez de salto severamente desalinhada com a escala do pedido;" apenas exigia que o solucionador retornasse um plano de roteamento executável e não zero, que seria aceito pelo sistema, essa é a falha principal deste incidente.

Defeitos na Lógica de Modelagem de Liquidez Estilo Uniswap V2

O terceiro problema reside na abordagem de modelagem de pool de liquidez estilo Uniswap V2: o código apenas emprega o algoritmo padrão de produto constante, rejeitando apenas situações matematicamente impossíveis, como reservas zero, underflow e overflow, sem realizar verificações de viabilidade econômica.

Fonte: pool_fetching.rs:118 e pool_fetching.rs:153

Este segmento de código não determina se o tamanho do pool de liquidez é suficiente para acomodar a transação de roteamento correspondente; ele apenas verifica se a operação de troca é matematicamente válida. Portanto, mesmo um micro pool com apenas 331 reservas de AAVE seria considerado um lugar válido para acomodar um pedido de compra de 17.957 WETH, simplesmente porque o algoritmo de produto constante pode gerar um resultado não zero, ignorando completamente a perda catastrófica de ativos que esse resultado causaria.

Falha Secundária do SDK de Empréstimo Relâmpago e Mecanismo de Verificação de Pedidos

Subsequentemente, o SDK de empréstimo relâmpago solidificou diretamente essa cotação inválida no pedido e na carga útil de execução do hook sem qualquer interceptação de risco secundário.

Então:

Fonte: index.js:484 e index.js:591

É por isso que sempre disse que esse roteamento é "nascido ruim." A camada do adaptador não "descobriu" um novo valor ruim durante a execução. Ela serializou o valor ruim já cotado nos dados do hook e determinou o endereço da instância. Uma vez que uma citação ruim existe, os mecanismos restantes a passarão fielmente adiante.

Mesmo a lógica de verificação de pedidos do CoW aqui ainda não protegeu verdadeiramente o usuário, pois apenas verifica se o pedido excede o preço de mercado no momento da citação, sem verificar se a citação em si é absurda em relação à liquidez real.

Fonte: order_validation.rs:694

Esta é uma verificação de consistência. Se a citação em si já é sem sentido, o pedido ainda pode passar.

O mecanismo de aviso da interface do frontend é ineficaz

A interface do Aave realmente possui avisos de alto impacto de preço, mas não é um cortador de circuito rígido. Quando a perda de valor excede 20%, torna-se uma caixa de seleção de confirmação.

Uma vez que o usuário marca a caixa de seleção, a barreira é removida:

Fonte: helpers.ts:24 e HighPriceImpactWarning.tsx:35

Portanto, mesmo que esta transação esvaziasse quase todo o valor do ativo, o sistema apenas a considerou uma operação que requer confirmação do usuário, em vez de uma transação de alto risco que deve ser firmemente rejeitada pelo sistema, e o mecanismo de aviso perdeu completamente sua função de interceptação de risco.

Com base em todas as falhas dos mecanismos acima, eu absolutamente não concordo com a conclusão desdenhosa de que "isso é apenas estupidez do usuário." O usuário completou a assinatura, mas todo o sistema de software teve inúmeras oportunidades de interceptar esse desastre, no entanto, cada camada apenas realizou verificações básicas, determinando "não zero, executável, assinado," e liberou diretamente, resultando em consequências desastrosas.

O roteamento não foi adulterado

Esta seção é crucial, eliminando diretamente um grande número de especulações errôneas: o processo da interface oficial do Aave correspondente ao aave-v3-interface-collateral-swap calculará o valor de compra ajustado pela slippage na linha 139 do arquivo useSwapOrderAmounts.ts, combinando a citação, taxas de rede, taxas de parceiros e taxas de empréstimos relâmpago; a linha 331 converte isso no valor buyAmountBigInt; então, na linha 191 do arquivo CollateralSwapActionsViaCoWAdapters.tsx, esse valor é precisamente assinado.

Os contratos de adaptadores subsequentes verificarão se os campos do pedido assinado correspondem completamente aos valores armazenados na linha 141 do arquivo AaveV3BaseAdapter.sol; o contrato de liquidação do CoW fará cumprir as regras de limite acordadas assinadas na linha 337 do arquivo GPv2Settlement.sol. Portanto, o resultado da execução on-chain não excedeu os limites permitidos pelo pedido assinado, e os ativos que o usuário realmente recebeu estavam até acima do limite mínimo acordado na assinatura.

Isso é suficiente para provar: o desastre ocorreu antes da fase de liquidação, não durante o processo de liquidação; a falha fatal no roteamento já havia predeterminado o resultado.

Para onde foi o valor desaparecido?

A próxima transação no mesmo bloco (hash começando com 0x45388b0f) completou uma arbitragem de back-run contra o pool danificado SushiSwap AAVE/WETH. Após a transação anormal encher a piscina com uma quantidade massiva de WETH e drenar a maior parte do AAVE, o arbitrador imediatamente vendeu o AAVE de volta para a piscina, colhendo o valor excedente trazido pelo desequilíbrio de liquidez.

Esse arbitragem de back-run extraiu cerca de 17.929,770158685933 WETH, depois pagou cerca de 13.087,73 ETH ao construtor de blocos e cerca de 4.824,31 ETH ao endereço de execução da arbitragem.

Todo o valor econômico perdido pelo usuário foi, em última análise, quase instantaneamente convertido em lucros de arbitragem MEV e lucros do construtor de blocos dentro do mesmo bloco.

Além disso, verificar a sequência de tempo em nível de bloco confirma: ninguém manipulou maliciosamente a piscina de negociação SushiSwap para armar uma armadilha para os usuários; o par de negociação AAVE/WETH foi o primeiro a ser tocado por essa transação anormal (índice da transação 1); a transação imediatamente seguinte (índice da transação 2) completou o primeiro back-run contra a distorção de preço causada por essa transação; o índice da transação 3 também tocou esse par de negociação durante o processo de correção do mercado. A linha do tempo verifica claramente: essa transação anormal criou uma distorção extrema de preço, e as transações subsequentes colheram diretamente esse lucro distorcido.

Então, de quem é a culpa?

Se você perguntar se o protocolo central Aave V3 colapsou, a resposta é não. A piscina de liquidez Aave executou operações completamente de acordo com as instruções, completando com sucesso o processo de resgate de USDT e depósito de AAVE.

Se você perguntar se o contrato GPv2Settlement do CoW colapsou, a resposta é não. O acerto impôs uma ordem assinada válida e pagou um valor acima do limite mínimo acordado na assinatura.

Se você perguntar se os contratos de pares de negociação do Uniswap V3 ou SushiSwap colapsaram, a resposta também é não. Ambos os tipos de piscinas de negociação completaram a precificação das transações de acordo com suas próprias regras de algoritmo.

A verdadeira falha sistêmica ocorreu nos níveis superiores de roteamento e controle de risco:

A parte principal responsável é os módulos de roteamento, cotação e solucionador do protocolo CoW: os critérios de todo o sistema para determinar "roteamento razoável" são muito fracos, permitindo que ordens de milhões de dólares acabem fluindo para piscinas de baixa liquidez, desde que o roteamento seja executável e não zero, é aceito, ignorando completamente a extrema irracionalidade no nível econômico.

A parte secundária responsável é a interface frontend do Aave: ela não anexou os dados da aplicação associados ao hook ao solicitar cotações de adaptadores, passando diretamente resultados errôneos para o processo de assinatura, e confiou apenas em avisos sem um mecanismo de rejeição rigoroso. Para transações tão extremas, essas medidas de controle de risco são completamente insuficientes para prevenir riscos.

Esta é uma falha extrema na qualidade do roteamento de transações e barreiras de controle de risco, transformando diretamente uma operação legítima e em conformidade de troca de colateral em um evento catastrófico de perda de ativos.