50M USDT trocados por 35K AAVE no incidente do Protocolo Aave CoW

Este artigo é de: @Ehsan1579

Compilado por Odaily Planet Daily (@OdailyChina); Tradutor: Ethan (@ethanzhang_web3

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

O núcleo do evento é: alguém converteu USDT no valor de 50,4 milhões de dólares, mas acabou recebendo apenas AAVE no valor de 35.900 dólares.

Quando ouvi falar disso pela primeira vez, fiquei realmente chocado. Por isso, revisei completamente todo o evento: rastreamento de transações, caminho do resolvedor, chamadas de contrato, reservas históricas, dados de liquidação, fluxo do adaptador, código da interface do Aave, SDK de闪电贷 do CoW e o código de roteamento para determinar se a cotação é "razoável".

Isso não foi um ataque hacker. O protocolo central da Aave não teve erro. O结算 da CoW não teve erro. A Uniswap não teve erro. A SushiSwap não teve erro. As transações eram válidas, as assinaturas eram válidas, e todos os contratos executaram estritamente conforme o código. No entanto, quase todo o valor econômico foi destruído apenas porque foi permitido um caminho absurdo.

A cadeia pública não teve problemas; o problema foi com o roteamento.

Na minha opinião, reduzir esse incidente a meramente um “erro de operação do usuário” não é uma atitude objetiva nem rigorosa. Embora o usuário tenha assinado o pedido, todo o sistema de software permitiu que uma operação de rotação de garantia envolvendo quase 50 milhões de dólares fosse cotada, assinada, roteada e executada por completo, com todo o processo direcionado a um pool de baixa liquidez que detém apenas cerca de 331 AAVE. Isso deveria ser completamente impossível e, pelo menos, deveria ter sido bloqueado e recusado pelo sistema antes da liquidação.

O hash da transação anormal é: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmado no bloco 24643151 da Ethereum Mainnet em 12 de março de 2026, com índice de transação 1, consumindo 3780570 unidades de Gas, e executada com sucesso. O endereço da carteira associada à ordem começa com 0x98b9, enquanto o endereço do solucionador (remetente da transação) que realmente executou a transação começa com 0x3980, marcado como tsolver nos dados do CoW Auction.

Primeiro, é importante entender que esta não é uma simples troca de USDT para AAVE a nível de carteira. O token vendido é aEthUSDT, o comprovante de depósito de USDT com rendimento na plataforma Aave. O token comprado é aEthAAVE, o comprovante de depósito de AAVE com rendimento na plataforma Aave. Portanto, trata-se na verdade de uma troca de ativos de garantia na Aave, realizada por meio do sistema de liquidação do protocolo CoW e seu adaptador de empréstimos relâmpago.

Antes da transação, a carteira detinha aproximadamente 50.432.693,075254 aEthUSDT e 0 aEthAAVE. Após a transação, restaram apenas 4,980399 aEthUSDT, e foram recebidos 327,241335505966487788 aEthAAVE. Na realidade, 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 da CoW o exibe como uma ordem de venda assinada, enquanto os metadados da aplicação o marcam como uma troca de ativos de garantia do tipo mercado com deslizamento inteligente de 121 pontos-base. O valor de venda assinado é de 50.432.688,41618 aEthUSDT. O valor mínimo de compra assinado é de 324,949260918413591035 aEthAAVE. O pagamento efetivamente liquidado foi de 327,241335505966487788 aEthAAVE.

Este é um detalhe extremamente importante. Este pedido nunca foi esperado para obter milhares de AAVE, e depois ser destruído de alguma forma no meio do caminho. Desde o seu início, foi planejado em torno de um resultado de mais de trezentos AAVE.

Once you follow the trade trail, the entire process becomes brutally straightforward.

A transferência central de fundos depende principalmente do contrato de liquidação GPv2Settlement com início em 0x9008. Primeiro, o contrato HooksTrampoline com início em 0x60bf realiza a autorização do aEthUSDT, permitindo que o relay da CoW Treasury retire ativos do usuário sem necessidade de autorizações de transação separadas; em seguida, o contrato GPv2VaultRelayer com início em 0xc92e retira 50.432.688,41618 aEthUSDT da carteira do usuário para o processo de liquidação; até este estágio, todas as operações estão dentro da lógica normal.

O contrato de liquidação em seguida concede permissões de operação do aEthUSDT ao contrato auxiliar não aberto com endereço que começa em 0xd524 e inicia a chamada por meio do seletor de função 0x494b3137; esse contrato auxiliar transfere então as permissões de execução para o contrato executor não aberto que começa em 0x699c, revelando totalmente o caminho da transação anormal.

A primeira chamada válida aponta para o contrato do pool de empréstimos Aave que começa em 0x87870, utilizando a função withdraw (seletor 0x69328dec) para destruir aEthUSDT e resgatar o USDT nativo subjacente; em seguida, o roteamento redireciona para o pool de liquidez Uniswap V3 que começa em 0x4e68, convertendo todos os 50432688.41618 USDT em 17957.810805702142342238 WETH.

As negociações nesta fase ocorreram normalmente: a taxa de câmbio foi de aproximadamente 2808,4 USDT por 1 WETH, alinhada com as condições de mercado na época, sem problemas de liquidez nem erros de cálculo; não houve nenhuma anomalia na cadeia de negociação inicial.

O problema está no segundo salto; assim que você ver a reserva de liquidez, o restante da história se torna inevitável.

Após receber 17957.810805702142342238 WETH, o executor transfere todos os fundos para o pool de negociação SushiSwap V2 AAVE/WETH no endereço 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Verifiquei os dados históricos de reserva de liquidez do pool no instante anterior à transação anômala (altura do bloco 24643150), e o pool continha apenas:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

This is not a data entry error, but an ironclad fact.

Este roteamento de transação injetou cerca de 17.958 WETH em um mini-pool de negociação com apenas 17,65 WETH em reserva e um estoque total de AAVE de 331,63 WETH; a quantidade de WETH inserida é aproximadamente 1.017 vezes o estoque de WETH no pool.

Este não é um problema comum de "slippage elevado" ou "liquidez ligeiramente baixa", mas sim um caminho de execução de ordem de mercado extremamente absurdo, equivalente a forçar um pool AMM de produto constante de tamanho minúsculo a absorver uma transação de valor milhares de vezes maior que sua própria capacidade.

O pool de negociação AMM executou operações conforme o algoritmo definido, esgotando quase totalmente as reservas de AAVE no pool.

O par de negociação SushiSwap acionou um evento de troca Swap principal: o executor transferiu 17957,810805702142342238 WETH e recebeu apenas 331,305315608938235428 AAVE. Após a conclusão da transação, a liquidez restante neste pool é aproximadamente:

0.326666929169791895 AAVE, 17975.464081898540030304 WETH

Em outras palavras, cerca de 99,9% dos fundos de AAVE no pool foram esvaziados em um único salto.

Com base na reserva antes da negociação, o preço implícito do AAVE no pool é de aproximadamente 149,50 dólares. O preço real de execução do usuário foi de aproximadamente 154.114,66 USDT por 1 AAVE. Isso representa mais de 1.000 vezes a diferença em relação ao preço spot antes da negociação.

Em seguida, esses AAVE são fornecidos de volta ao pool da Aave usando o seletor 0x617ba037, ou seja, supply(address,uint256,address,uint16). Como resultado, os aEthAAVE recém-mintados são enviados de volta ao contrato de liquidação. O contrato de liquidação transfere finalmente 327.241335505966487788 aEthAAVE para o usuário. Aproximadamente 4.06398010297174764 aEthAAVE permanecem no contrato de liquidação como excedente em relação ao pagamento do usuário.

Portanto, o encerramento não distorceu repentinamente um bom resultado de execução em um mau resultado. Ele simplesmente confirmou finalmente o resultado já gerado pela rota.

Este é um ponto crucial, merece ser dito claramente: resultados desastrosos já estavam “pré-definidos” dentro do roteamento antes da execução.

Nos dados de chamada de contrato auxiliar embutido no roteamento, o valor-alvo na compra é de aproximadamente 331,272185078031026739 unidades, o valor mínimo de compra acordado pela assinatura do usuário é de 324,949260918413591035 unidades, e o valor liquidado real é de 327,241335505966487788 unidades; todos os valores principais foram bloqueados antes da liquidação, na faixa de centenas de unidades de AAVE.

This route was bad from birth.

A resposta é: cada mecanismo de verificação do sistema está verificando a dimensão do erro.

Todos os níveis verificam apenas se a transação pode ser executada, se a assinatura é válida e se o valor é diferente de zero, mas quase não verificam se o roteamento da transação é economicamente razoável no nível central — essa é a raiz fundamental da falha do mecanismo.

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

O primeiro ponto evidente de anomalia de código ocorre no fluxo de cotaçã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 cotação foi diretamente desativada.

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

Isso significa que a interface da Aave, ao solicitar cotações à CoW, não anexa os metadados de empréstimos relâmpago e ganchos que seriam anexados ao publicar efetivamente a ordem. Em outras palavras, o que está sendo cotado não é exatamente o que será executado. Os comentários no código até dizem que o propósito dessa função auxiliar é tornar as cotações do adaptador mais precisas, mas essa função foi desativada rigidamente.

A lógica de avaliação da justificativa da oferta CoW é muito fraca (vulnabilidade central)

O segundo e mais grave problema reside na lógica de competição de cotações do protocolo CoW: em seu código de serviço público, qualquer cotação com taxa de gas positiva e valor de saída diferente de zero é considerada uma "cotação válida".

Fonte: quote.rs:31

Para um sistema de roteamento que lida com ordens de oito dígitos, essa é uma definição surpreendentemente fraca de “racionalidade”.

O sistema não integra oráculos para verificação de integridade de preços, não possui mecanismo de bloqueio para “desvio de cotação acima de 500 vezes o preço à vista”, não realiza avaliação de risco para “rotas que esgotam completamente os pools de liquidez” e não emite alertas para “liquidez do último salto severamente desproporcional ao tamanho do pedido”; basta que o resolvedor retorne uma rota executável e não nula para que o sistema a aceite — essa é a vulnerabilidade central deste evento.

Defeitos na lógica de modelagem de liquidez do Uniswap V2

A terceira questão reside no modelo de pool de liquidez no estilo Uniswap V2: o código utiliza apenas o algoritmo padrão de produto constante, rejeitando apenas situações matemáticas impossíveis, como reservas zero, underflow numérico e overflow de reservas, sem realizar verificações de viabilidade econômica.

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

Este código não verifica se o volume do pool de liquidez é suficiente para absorver a transação roteada, apenas verifica se a operação de troca é matematicamente válida. Portanto, mesmo um minúsculo pool com apenas 331 AAVE em reserva será considerado um local válido para absorver uma solicitação de compra de 17.957 WETH, apenas porque o algoritmo de produto constante calcula um resultado diferente de zero, ignorando completamente o fato de que esse resultado causaria uma perda catastrófica de ativos.

Segunda falha no SDK de empréstimos relâmpago e no mecanismo de verificação de ordens

Em seguida, o SDK de empréstimos relâmpago fixou diretamente essa cotação inválida na carga de execução do pedido e do gancho, sem realizar qualquer outra interceptação de risco.

Em seguida:

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

É por isso que sempre disse que este caminho é “defeituoso desde o nascimento”. A camada de adaptador não “descobriu” um novo valor inválido em tempo de execução; ela serializou a sequência de valores inválidos já cotados nos dados do gancho e no endereço da instância determinada. Assim que a cotação ruim existir, os demais mecanismos a transmitirão fielmente.

Mesmo a lógica de validação de ordens da CoW não protege realmente os usuários aqui, pois verifica apenas se a ordem excede o preço de mercado no momento da cotação, mas não avalia se a cotação em si é absurda em relação à liquidez real.

Fonte: order_validation.rs:694

Este é um teste de consistência. Se a cotação já for nonsense, o pedido ainda será aprovado.

O mecanismo de alerta da interface do usuário é meramente simbólico

A interface da Aave realmente possui um aviso de impacto de preço elevado, mas não é um interruptor de desligamento automático rígido. Quando a perda de valor excede 20%, ela se torna uma caixa de confirmação.

Uma vez que o usuário marcar a caixa de seleção, o obstáculo será removido:

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

Portanto, mesmo que esta transação quase esgotasse todo o valor dos ativos, o sistema apenas a classificaria como uma operação que requer confirmação do usuário, e não como uma transação de alto risco que o sistema deveria recusar rigidamente, tornando o mecanismo de alerta totalmente ineficaz na interceptação de riscos.

Com base na falha de todos os mecanismos acima, não concordo com a conclusão superficial de que “isso é apenas um erro do usuário”. O usuário realmente assinou, mas o sistema de software inteiro teve inúmeras oportunidades de interromper esse desastre, e em cada camada apenas realizou verificações básicas, aprovando diretamente após confirmar “não zero, executável, assinado”, resultando finalmente nesse desastre.

Esta etapa é crucial e exclui diretamente muitos palpites incorretos: o fluxo oficial da interface da Aave correspondente a aave-v3-interface-collateral-swap calcula o valor de compra ajustado pelo slippage na linha 139 do arquivo useSwapOrderAmounts.ts, combinando cotação, taxas de rede, taxas de parceiros e taxas de empréstimo relâmpago; na linha 331, converte esse valor para buyAmountBigInt; em seguida, no arquivo CollateralSwapActionsViaCoWAdapters.tsx, na linha 191, assina com precisão esse valor.

O contrato adaptador subsequente verificará na linha 141 do arquivo AaveV3BaseAdapter.sol se os campos do pedido assinado correspondem exatamente aos valores armazenados; o contrato de liquidação CoW aplicará na linha 337 do arquivo GPv2Settlement.sol as regras de limite estabelecidas pela assinatura. Portanto, o resultado da execução na cadeia não excedeu o limite permitido pelo pedido assinado, e os ativos recebidos pelo usuário são, na verdade, superiores ao limite mínimo estipulado na assinatura.

Isso é suficiente para provar: o desastre ocorreu antes do processo de liquidação, e não durante ele; o defeito fatal no roteamento já estava destinado ao desfecho.

A próxima transação no mesmo bloco (com hash que começa em 0x45388b0f) realizou um arbitragem de corrida no pool danificado do SushiSwap AAVE/WETH. Após a transação anômala encher o pool com uma grande quantidade de WETH e esvaziar a maior parte do AAVE, o arbitragista vendeu imediatamente o AAVE de volta ao pool, capturando o valor excedente gerado pelo desequilíbrio de liquidez.

Nesta operação de arbitragem de backrunning, foram extraídas aproximadamente 17929,770158685933 WETH, seguidas por um pagamento de aproximadamente 13087,73 ETH ao construtor do bloco e aproximadamente 4824,31 ETH ao endereço de execução da arbitragem.

O valor econômico total perdido pelo usuário é transformado quase instantaneamente em ganhos de arbitragem MEV e receitas do construtor do bloco dentro do mesmo bloco.

Além disso, a verificação da sequência temporal ao nível do bloco confirma: antes da transação, ninguém manipulou maliciosamente o pool de negociação do SushiSwap para armadilhar usuários; o par AAVE/WETH foi tocado pela primeira vez nesta transação anômala (índice da transação 1); a transação imediatamente seguinte (índice da transação 2) realizou o primeiro arbitragem aproveitando a distorção de preço causada por esta transação; a transação de índice 3 também tocou este par durante o processo de correção do mercado. A linha do tempo claramente comprova: esta transação anômala criou um preço extremamente distorcido, e as transações subsequentes capturaram diretamente esse lucro distorcido.

Se você perguntar se o protocolo central do Aave V3 sofreu uma falha, a resposta é não. Os pools da Aave executaram perfeitamente as operações solicitadas, concluindo normalmente o resgate do USDT e o depósito de AAVE.

Se você perguntou se o contrato GPv2Settlement do CoW caiu, a resposta é não. O settlement executou com sucesso um pedido assinado válido e pagou um valor superior ao mínimo especificado na assinatura.

Se você perguntar se os contratos de pares de negociação do Uniswap V3 ou SushiSwap entraram em colapso, a resposta é igualmente não. Ambos os pools de negociação realizam a precificação das transações de acordo com suas próprias regras algorítmicas.

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

A principal responsável pelo módulo de roteamento, cotação e solucionador do protocolo CoW: o sistema inteiro possui critérios excessivamente fracos para determinar “roteamento razoável”, permitindo ordens de milhões de dólares que acabam em pools minúsculos e de baixa liquidez, desde que o roteamento seja executável e não nulo, ignorando completamente a extrema irracionalidade econômica.

A parte secundariamente responsável é a interface frontal da Aave: ao solicitar uma cotação do adaptador, os dados da aplicação associados ao gancho não foram incluídos, o resultado de erro foi diretamente encaminhado para o processo de assinatura, e apenas depende de alertas de aviso, sem mecanismo de recusa obrigatória; para transações extremamente volumosas desse tipo, essas medidas de controle de risco são completamente insuficientes para prevenir riscos.

Foi um fracasso extremo na qualidade do roteamento de negociação e nos sistemas de proteção de risco, transformando diretamente uma operação legítima e regulamentada de troca de garantias em um evento de perda catastrófica de ativos.