50 milhões de USDT trocados por 35 mil dólares de AAVE: Como é que o desastre aconteceu? Quem é que devemos culpar?

Este artigo é de: @Ehsan1579

Compilado por｜Odaily Star Daily（@OdailyChina）；Tradutor｜ Ethan（__@ethanzhang_web 3）

Ao observar apenas o título do evento, é provável que se pense que se trata de um ataque de exploração de vulnerabilidade.

O núcleo do evento é: Alguém trocou USDT no valor de 50,4 milhões de dólares por apenas 35,9 mil dólares em AAVE.

Quando ouvi falar nisso pela primeira vez, fiquei realmente chocado. Por isso, analisei toda a situação detalhadamente: rastreamento da transação, caminho do solver, chamadas de contrato, reservas históricas, dados de liquidação, fluxo do adaptador, código da interface do Aave, SDK de flash loans do CoW, além do roteamento para verificar se a cotação era “razoável”.

Não se trata de um ataque de hackers. O protocolo principal do Aave não cometeu erro. A liquidação do CoW não falhou. Uniswap não falhou. SushiSwap não falhou. A transação foi válida, a assinatura foi válida, todos os contratos foram executados estritamente conforme o código. No entanto, quase todo o valor econômico foi destruído, simplesmente porque o roteamento permitido foi absurdamente mal planejado.

A blockchain pública não teve problema, o problema está no roteamento.

Na minha opinião, minimizar o ocorrido como uma “falha do usuário” é uma postura superficial e pouco rigorosa. De fato, o usuário assinou a ordem, mas todo o sistema de software permitiu uma operação envolvendo quase 50 milhões de dólares em garantias, passando por cotação, assinatura, planejamento de roteamento e execução final, tudo direcionado a um pool de baixa liquidez com apenas cerca de 331 AAVE. Isso deveria ser impossível de acontecer, ou pelo menos, deveria ser barrado pelo sistema antes mesmo de chegar à fase de liquidação.

Rastreamento da transação principal

O hash desta transação anômala é: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmada na blockchain principal do Ethereum em bloco 24643151, em 12 de março de 2026. O índice da transação é 1, consumiu 3.780.570 unidades de Gas e foi bem-sucedida. A carteira de origem começa com 0x98b9, enquanto o solver (quem enviou a transação) é 0x3980, marcado como tsolver nos dados do CoW.

Primeiro, é importante entender que isso não é uma simples troca de USDT por AAVE na camada de carteira. O token vendido é aEthUSDT, um recibo de depósito de USDT que gera juros na plataforma Aave. O token comprado é aEthAAVE, um recibo de depósito de AAVE que também gera juros. Ou seja, trata-se de uma troca de garantias via o sistema de liquidação do protocolo CoW e seu adaptador de flash loans.

Antes da transação, essa carteira tinha aproximadamente 50.432.693,075254 aEthUSDT e 0 aEthAAVE. Após a operação, restaram apenas 4.980399 aEthUSDT e receberam 327.241335505966487788 aEthAAVE. Ou seja, a carteira vendeu quase toda sua posição.

Os metadados indicam claramente que o roteamento já era “tóxico” antes da execução. A ordem veio do fluxo aave-v3-interface-collateral-swap. A API do CoW mostra-a como uma ordem de venda assinada, enquanto os metadados indicam uma troca de garantias a mercado com 121 pontos base de slippage inteligente. A assinatura corresponde a uma venda de 50.432.688,41618 aEthUSDT. O valor mínimo de compra assinado é 324.949260918413591035 aEthAAVE. A liquidação final pagou 327.241335505966487788 aEthAAVE.

Este detalhe é crucial. A ordem nunca deveria ter esperado receber milhares de AAVE e, de alguma forma, ser destruída no meio do caminho. Desde a sua criação, ela já envolvia um resultado de cerca de 300 AAVE.

Cadeia completa do colapso do roteamento

Seguindo o rastreamento da transação, o processo é brutalmente direto.

O fluxo de fundos principal depende do contrato de liquidação GPv2Settlement, que começa com o endereço 0x9008 no protocolo CoW. Primeiro, o contrato HooksTrampoline (começa com 0x60bf) autoriza a operação de aEthUSDT, permitindo que o repositório do CoW retire ativos do usuário sem uma autorização separada. Depois, o contrato GPv2VaultRelayer (começa com 0xc92e) retira 50.432.688,41618 aEthUSDT da carteira do usuário para o processo de liquidação. Até aqui, tudo dentro do esperado.

O contrato de liquidação então concede permissão de operação de aEthUSDT a um contrato auxiliar não aberto (começa com 0xd524), usando o seletor de função 0x494b3137. Este contrato auxiliar transfere a permissão para um executor não aberto (começa com 0x699c). Assim, toda a cadeia do roteamento anômalo fica exposta.

A primeira chamada válida aponta para o contrato do pool de fundos do Aave (começa com 0x87870), usando a função withdraw (seletor 0x69328dec), destruindo aEthUSDT e resgatando USDT nativo. Depois, o roteamento salta para o pool de liquidez do Uniswap V3 (começa com 0x4e68), trocando todas as 50.432.688,41618 USDT por 17.957,810805702142342238 WETH.

Até aqui, tudo normal: a taxa de troca de aproximadamente 2808,4 USDT por WETH está de acordo com o mercado na época, sem problemas de liquidez ou cálculos errados. A primeira etapa do roteamento não apresenta anomalias.

O problema surge na segunda etapa, quando se observa a reserva de liquidez, e aí o enredo se torna inevitável.

Após receber 17.957,810805702142342238 WETH, o executor transfere todo o valor para o pool SushiSwap AAVE/WETH (começa com 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4).

Verifiquei os dados históricos de reserva desse pool na hora exata do evento anômalo (bloco 24643150): ele continha apenas:

331,631982538108027323 AAVE e 17,653276196397688066 WETH

Não é erro de entrada de dados, é fato mesmo.

Essa rota de transação injeta quase 17.958 WETH em um pool que só tem cerca de 17,65 WETH de reserva, e que possui um estoque total de AAVE de apenas 331,63. Ou seja, a quantidade de WETH inserida é aproximadamente 1017 vezes maior que a reserva do pool.

Isso não é um problema de “slippage alto” ou “liquidez escassa”, mas uma execução de mercado extremamente absurda, forçando um pool AMM de volume muito pequeno a suportar uma operação de escala milhares de vezes maior.

O pool, seguindo seu algoritmo, quase esgota toda a reserva de AAVE:

O evento de troca do SushiSwap é acionado: o executor transfere 17.958 WETH e recebe de volta apenas 331,305 AAVE. Após a troca, a liquidez remanescente do pool é aproximadamente:

0,326666929169791895 AAVE e 17.975,464081898540030304 WETH

Ou seja, cerca de 99,9% do estoque de AAVE foi drenado em uma única operação.

Com base na reserva anterior, o preço implícito do AAVE era cerca de 149,50 dólares. O preço efetivo de execução foi aproximadamente 154.114,66 USDT por AAVE — mais de mil vezes o preço de mercado antes da operação.

Depois, esses AAVE são devolvidos ao pool do Aave, usando o seletor 0x617ba037 (supply(address,uint256,address,uint16)). Como resultado, o aEthAAVE recém-emitido é enviado de volta ao contrato de liquidação. Este, por sua vez, transfere 327,241335505966487788 aEthAAVE ao usuário. Cerca de 4,06 aEthAAVE permanecem no contrato de liquidação como lucro para o sistema, além do valor pago pelo usuário.

Ou seja, a liquidação não distorceu um bom resultado em um ruim. Ela apenas confirmou o resultado que o roteamento já tinha produzido.

Este é o ponto crucial: o desastre já estava “pré-definido” antes mesmo da execução do roteamento.

Nos dados embutidos no contrato auxiliar, o valor de compra estimado era cerca de 331,27 AAVE, enquanto o mínimo assinado era 324,94 AAVE, e o valor final de liquidação foi 327,24 AAVE — tudo isso, antes mesmo da execução, já estava fixado na ordem.

Este roteamento nasceu ruim.

Onde está a vulnerabilidade?

A resposta é: cada camada de validação do sistema verifica apenas o erro na dimensão errada.

Todas as verificações validam se a transação é executável, se a assinatura é válida, se o valor é diferente de zero — mas quase não há validações na camada econômica, se o roteamento é razoável do ponto de vista financeiro. Essa é a raiz do mecanismo falho.

Defeito no código do caminho de cotação do adaptador da interface do Aave

O primeiro erro evidente ocorre na rotina de cotação do adaptador do CoW na interface do Aave: a função que deveria incluir dados específicos do adaptador na solicitação de cotação foi simplesmente desativada.

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

Ou seja, ao solicitar uma cotação ao CoW, a interface do Aave não envia os metadados de flash loans e hooks que normalmente seriam anexados na ordem. Em outras palavras, o que é cotado não é exatamente o que será executado. O comentário do código até diz que essa função auxilia na precisão da cotação, mas ela foi desativada de forma rígida.

Lógica de competição de cotações do CoW excessivamente fraca (vulnerabilidade principal)

O segundo e mais grave problema está na lógica de competição de cotações do protocolo CoW: seu código de serviço público, ao avaliar uma cotação, considera “razoável” qualquer cotação que tenha Gas positivo e valor de saída não zero.

Fonte: quote.rs:31

Para um sistema de roteamento que lida com ordens de oito dígitos, essa definição de “razoável” é absurdamente fraca.

O sistema não usa oráculos para validar preços, não possui mecanismos de detecção de cotações que desviem mais de 500 vezes do preço à vista, não avalia o risco de esvaziar completamente pools de liquidez, nem alerta quando a última etapa do roteamento apresenta uma disparidade enorme entre liquidez e volume de ordens. Basta que o solver retorne uma rota executável e com valor não zero para que seja aceita — essa é a vulnerabilidade central do evento.

Defeitos na modelagem de liquidez do Uniswap V2

O terceiro problema está na modelagem de pools de liquidez no estilo Uniswap V2: o código usa apenas o algoritmo padrão de produto constante, rejeitando apenas reservas zero, underflow ou overflow matemático, sem validações econômicas de viabilidade.

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

O código não verifica se o volume do pool é suficiente para suportar a operação de roteamento. Apenas valida se a troca é matematicamente possível. Assim, até um pool com apenas 331 AAVE pode ser considerado apto a suportar uma compra de 17.958 WETH, pois o algoritmo de produto constante calcula um resultado não zero, ignorando o fato de que esse resultado pode causar perdas catastróficas.

Segunda falha no SDK de flash loans e na validação de ordens

Depois, o SDK de flash loans simplesmente embute essa cotação inválida na carga útil da ordem e do hook, sem fazer nenhuma checagem de risco adicional.

Depois:

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

Por isso, sempre digo que esse roteamento nasceu ruim. O adaptador não detecta que o valor cotado é errado na execução. Ele serializa o valor ruim na carga do hook e no endereço do contrato, e assim, uma vez que o valor ruim está lá, os demais mecanismos apenas o transmitem fielmente.

Nem mesmo a validação de ordens do CoW consegue proteger o usuário de forma efetiva, pois ela só verifica se a cotação não ultrapassa o preço de mercado na assinatura, sem avaliar se a cotação é economicamente absurda.

Fonte: order_validation.rs:694

Essa é uma verificação de consistência: se a cotação já é absurda, a ordem ainda assim pode passar.

Sistema de alerta na interface não funciona

A interface do Aave tem um aviso de impacto de preço elevado, mas não é um mecanismo de corte rígido. Quando a perda de valor ultrapassa 20%, ela vira uma caixa de confirmação.

Ao marcar essa caixa, o obstáculo é removido:

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

Assim, mesmo que a transação quase esvazie todo o valor, o sistema apenas exige confirmação do usuário, sem uma rejeição automática de risco elevado. O mecanismo de alerta, portanto, não consegue impedir a operação de risco extremo.

Diante de todas essas falhas de mecanismo, não concordo com a conclusão simplista de que “foi apenas um erro do usuário”. O usuário assinou a transação, mas o sistema tinha inúmeras oportunidades de impedir essa tragédia, e cada camada apenas fez validações básicas — “não zero, executável, assinado” — e liberou, culminando na destruição.

Roteamento não foi adulterado

Essa parte é crucial e descarta muitas hipóteses erradas: o roteamento do aave-v3-interface-collateral-swap, que é o fluxo oficial da interface do Aave, na linha 139 do arquivo useSwapOrderAmounts.ts, calcula o valor de compra ajustado pelo slippage, considerando cotação, taxas de rede, taxas de parceiros e custos de flash loans; na linha 331, converte esse valor para buyAmountBigInt; e na linha 191 do arquivo CollateralSwapActionsViaCoWAdapters.tsx, realiza a assinatura precisa desse valor.

Os contratos de adaptador subsequentes, no arquivo AaveV3BaseAdapter.sol, na linha 141, verificam se os dados da assinatura correspondem exatamente aos valores armazenados; o contrato de liquidação do CoW, no arquivo GPv2Settlement.sol, na linha 337, força a execução das regras de limite de assinatura. Portanto, o resultado na blockchain não ultrapassa o limite autorizado na assinatura, e o usuário recebeu até mais do que o mínimo assinado.

Isso prova que o problema ocorreu antes da liquidação, e não na sua execução: a falha fatal do roteamento já estava embutida desde o início.

Para onde foi o valor que desapareceu?

Na mesma blockchain, a próxima transação (hash começando com 0x45388b0f) fez uma arbitragem de retorno contra o pool SushiSwap AAVE/WETH destruído. Após a operação anômala, com WETH em volume massivo e AAVE quase esgotado, o arbitrador vendeu AAVE de volta ao pool, capturando o valor excedente gerado pelo desequilíbrio.

Essa arbitragem de retorno retirou cerca de 17.929,77 WETH, e pagou aproximadamente 13.087,73 ETH ao construtor do bloco, além de pagar cerca de 4.824,31 ETH ao endereço de execução da arbitragem.

Todo o valor econômico perdido pelo usuário foi quase instantaneamente convertido em lucros de MEV e ganhos do construtor do bloco.

A verificação do timestamp do bloco confirma que, antes da operação, ninguém manipulou maliciosamente o pool do SushiSwap. O primeiro contato com o par AAVE/WETH foi justamente essa transação anômala (índice 1). A próxima transação (índice 2) foi uma primeira tentativa de arbitragem após o impacto de preço, e a terceira (índice 3) ocorreu durante o processo de reparo do mercado. A linha do tempo mostra claramente que a operação criou uma distorção extrema de preço, e as transações seguintes aproveitaram essa distorção para obter lucros.

Então, quem é o responsável?

Se você perguntar se o protocolo principal do Aave V3 quebrou, a resposta é: não. Os pools de fundos do Aave seguiram as instruções normalmente, realizando resgates de USDT e depósitos de AAVE sem problemas.

Se perguntar se o contrato de liquidação GPv2 do CoW quebrou, a resposta é: não. Ele executou uma ordem assinada válida e pagou mais do que o mínimo assinado.

Se perguntar se os contratos do Uniswap V3 ou SushiSwap quebraram, a resposta também é: não. Ambos seguiram suas regras de precificação.

A falha sistêmica real ocorreu na camada superior de roteamento e controle de risco:

A principal responsabilidade recai sobre o roteamento, cotação e solver do protocolo CoW: o sistema aceita rotas “razoáveis” com base em critérios fracos, permitindo que ordens de dezenas de milhões de dólares sejam direcionadas a pools de baixa liquidez, desde que a rota seja executável e o valor seja não zero — ignorando completamente a extrema irracionalidade econômica dessa operação.

Responsabilidade secundária é da interface do Aave: ao solicitar cotação ao adaptador, ela não envia os metadados de hooks e flash loans, entregando resultados incorretos ao sistema de assinatura, e sem mecanismos de rejeição automática. Para operações de grande escala, essas medidas de controle são insuficientes.

Essa é uma falha grave na qualidade do roteamento e na camada de controle de risco, que transformou uma operação legítima de troca de garantias em uma destruição massiva de ativos.