50 M USDT échangés contre 35 K AAVE dans le cadre de l'incident du protocole CoW d'Aave

Cet article provient de : @Ehsan1579

Compilation | Odaily Planet Daily (@OdailyChina); Translator | Ethan (@ethanzhang_web3

En regardant uniquement le titre de l'événement, on pourrait facilement croire qu'il s'agit d'une exploitation de vulnérabilité.

L'essentiel de l'événement est : quelqu'un a échangé 50,4 millions de dollars américains en USDT contre seulement 35 900 dollars américains en AAVE.

Lorsque j'ai entendu parler de cela pour la première fois, j'ai été profondément choqué. J'ai donc examiné en détail l'ensemble de l'événement : la traçabilité des transactions, les chemins des solveurs, les appels de contrat, les réserves historiques, les données de règlement, les processus d'adaptateur, le code d'interface Aave, le SDK CoW Flash Loan, ainsi que le code de routage permettant de déterminer si l'offre est « raisonnable ».

Ce n'est pas une attaque par piratage. Le protocole principal d'Aave n'a pas commis d'erreur. Le règlement CoW n'a pas commis d'erreur. Uniswap n'a pas commis d'erreur. SushiSwap n'a pas commis d'erreur. Les transactions étaient valides, les signatures étaient valides, et tous les contrats ont été exécutés strictement selon le code. Toutefois, presque toute la valeur économique a été détruite, simplement parce qu'on a autorisé une route absurde.

La chaîne publique n'a pas eu de problème, c'est le routage qui a posé problème.

À mon avis, réduire cet incident à une simple « erreur de l'utilisateur » ne constitue pas une approche objective ni rigoureuse. Bien qu'il soit vrai que l'utilisateur ait signé la commande, l'ensemble du système logiciel a permis à une opération impliquant près de 50 millions de dollars de garanties de passer par toutes les étapes — établissement du prix, signature, planification du routage et exécution finale — en direction d'un pool à faible liquidité ne détenant que 331 AAVE environ. Cela aurait dû être totalement impossible, et le système aurait dû bloquer et rejeter cette opération avant même l'étape de règlement.

L'hash de cette transaction anormale est : 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmée à la hauteur de bloc 24643151 sur le réseau principal Ethereum le 12 mars 2026, avec un index de transaction de 1, consommant 3780570 unités de Gas, et exécutée avec succès. L'adresse du portefeuille associée à la commande commence par 0x98b9, tandis que l'adresse du solveur (expéditeur de la transaction) qui a effectivement exécuté la transaction commence par 0x3980 et est marquée comme tsolver dans les données CoW竞赛.

Il faut d'abord comprendre qu'il ne s'agit pas d'un simple échange de niveau portefeuille de USDT vers AAVE. Le token vendu est aEthUSDT, soit le certificat de dépôt à rendement sur USDT sur la plateforme Aave. Le token acheté est aEthAAVE, soit le certificat de dépôt à rendement sur AAVE sur la plateforme Aave. Ainsi, il s'agit en réalité d'un changement de collatéral Aave effectué via le système de règlement CoW Protocol et son adaptateur de flash loan.

Avant la transaction, ce portefeuille détenait environ 50 432 693,075254 aEthUSDT et 0 aEthAAVE. Après la transaction, il ne reste plus que 4,980399 aEthUSDT, et il a reçu 327,241335505966487788 aEthAAVE. En réalité, ce portefeuille a vendu presque l'intégralité de sa position.

Les métadonnées indiquent plus clairement que le routage était déjà « toxique » avant exécution. L'ordre provient du processus aave-v3-interface-collateral-swap. L'API de CoW le présente comme un ordre de vente signé, tandis que les métadonnées de l'application le désignent comme un échange de garantie de type marché avec une glisse intelligente de 121 points de base. Le montant de vente signé est de 50 432 688,41618 aEthUSDT. Le montant minimal d'achat signé est de 324,949260918413591035 aEthAAVE. Le règlement effectif a payé 327,241335505966487788 aEthAAVE.

C'est un détail extrêmement important. Cette commande n'a jamais été conçue pour obtenir des milliers d'AAVE, puis être détruite en cours de route. Elle a été conçue dès le départ autour d'un résultat de plus de trois cents AAVE.

Une fois que tu suivis la trace de la transaction, tout le processus devient cruellement direct.

Le flux de fonds principal repose sur le protocole CoW et le contrat de règlement GPv2Settlement commençant par 0x9008. Tout d'abord, le contrat HooksTrampoline commençant par 0x60bf effectue l'autorisation aEthUSDT, permettant aux relais de trésorerie CoW de retirer les actifs des utilisateurs sans autorisation de transaction séparée ; ensuite, le contrat GPv2VaultRelayer commençant par 0xc92e retire 50432688,41618 aEthUSDT du portefeuille de l'utilisateur pour les intégrer au processus de règlement ; à ce stade, toutes les opérations sont conformes à la logique normale.

Le contrat de règlement accorde ensuite les droits d'opération aEthUSDT à un contrat auxiliaire non open-source commençant par 0xd524, et déclenche un appel via le sélecteur de fonction 0x494b3137 ; ce contrat auxiliaire transfère ensuite les droits d'exécution à un contrat exécuteur non open-source commençant par 0x699c, révélant ainsi entièrement le chemin d'exécution anormal.

Le premier appel valide cible le contrat de pool de financement Aave commençant par 0x87870, qui détruit aEthUSDT via la fonction withdraw (sélecteur 0x69328dec) pour récupérer les USDT natifs sous-jacents ; puis le routage redirige vers le pool de trading Uniswap V3 profond USDT/WETH commençant par 0x4e68, où les 50432688.41618 USDT sont entièrement échangés contre 17957.810805702142342238 WETH.

Les transactions de cette phase se sont déroulées normalement : le taux de change était d'environ 2808,4 USDT pour 1 WETH, conforme aux conditions du marché à ce moment-là, sans problème de liquidité ni erreur de calcul, et aucune anomalie n'a été détectée sur la première chaîne de transaction.

Le problème se situe à la deuxième étape ; une fois que vous voyez les réserves de liquidité, le reste de l'histoire est inévitable.

Après avoir obtenu 17957.810805702142342238 WETH, l'exécutrice transfère tous les fonds vers le pool de trading SushiSwap V2 AAVE/WETH à l'adresse 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

J'ai vérifié les données historiques de réserve de liquidité du pool au moment juste avant le trafic anormal (hauteur de bloc 24643150) ; le pool ne contenait que :

331,631982538108027323 AAVE, 17,653276196397688066 WETH

Ce n'est pas une erreur de saisie de données, mais un fait incontournable.

Ce chemin de transaction a injecté près de 17 958 WETH dans un mini-pool de trading ne contenant que 17,65 WETH et un stock total d'AAVE de 331,63 WETH ; la quantité de WETH entrante est environ 1 017 fois supérieure au réservoir de WETH du pool.

Ce n'est pas un problème classique de "slippage élevé" ou de "liquidité légère", mais un chemin d'exécution de commande au marché extrêmement absurde, équivalant à forcer un petit pool AMM à produit constant à absorber une transaction dont la taille dépasse plusieurs milliers de fois la sienne.

Le pool de trading AMM a exécuté une opération selon l'algorithme établi, épuisant presque entièrement les réserves de AAVE dans le pool.

Les paires de trading SushiSwap ont déclenché un événement d'échange Swap principal : l'exécuteur a transféré 17957,810805702142342238 WETH et n'a récupéré que 331,305315608938235428 AAVE. Après l'achèvement de la transaction, la liquidité restante dans ce pool est d'environ :

0,326666929169791895 AAVE, 17975,464081898540030304 WETH

En clair, environ 99,9 % des fonds AAVE dans le pool ont été vidés en une seule transaction.

Sur la base des réserves avant l'échange, le prix implicite d'AAVE est d'environ 149,50 $ US. Le prix réel d'exécution de l'utilisateur est d'environ 154 114,66 USDT pour 1 AAVE. Cela représente un écart de plus de 1 000 fois par rapport au prix spot avant l'échange.

Ensuite, ces AAVE sont réintroduits dans le pool Aave à l’aide du sélecteur 0x617ba037, soit supply(address,uint256,address,uint16). Le résultat est que les nouveaux aEthAAVE mintés sont renvoyés au contrat de règlement. Le contrat de règlement transfère finalement 327.241335505966487788 aEthAAVE à l’utilisateur. Environ 4.06398010297174764 aEthAAVE, en tant que surplus par rapport au paiement de l’utilisateur, restent dans le contrat de règlement.

Ainsi, le règlement n’a pas transformé soudainement un bon résultat en un mauvais résultat ; il a simplement confirmé définitivement le résultat déjà généré par le routage.

C'est un point crucial qui mérite d'être clairement énoncé : les résultats désastreux sont « prédéfinis » dans le routage avant son exécution.

Les données d'appel de contrat auxiliaire intégré dans le routage indiquent un montant cible d'achat d'environ 331,272185078031026739, le montant minimum d'achat convenu par la signature de l'utilisateur est de 324,949260918413591035, et le montant effectivement régi est de 327,241335505966487788 ; tous les chiffres clés sont verrouillés à un niveau de plusieurs centaines d'AAVE avant le règlement.

This route was bad from birth.

La réponse est : chaque mécanisme de vérification du système examine les erreurs selon des dimensions différentes.

Tous les niveaux ne vérifient que si la transaction est exécutable, si la signature est valide et si le montant est non nul, mais négligent presque entièrement la vérification du routage de la transaction du point de vue économique, ce qui constitue la cause fondamentale de l'échec du mécanisme.

Défaut de code dans le chemin de cotation de l'adaptateur d'interface Aave

Le premier point d'anomalie de code apparaît dans le processus de soumission d'offre de l'adaptateur CoW de l'interface Aave : la fonction utilisée pour inclure des données d'application spécifiques à l'adaptateur lors de la demande d'offre a été directement désactivée.

Source : rates.helpers.ts:93 et adapters.helpers.ts:194

Cela signifie que l'interface Aave ne joint pas les métadonnées de prêt flash et de crochet qui seront ajoutées lors de la publication réelle de l'ordre lorsqu'elle demande un devis à CoW. Autrement dit, ce qui est coté n'est pas entièrement ce qui sera exécuté. Les commentaires du code indiquent même que l'objectif de cette fonction d'assistance est de rendre les devis des adaptateurs plus précis, mais cette fonction a été désactivée de manière rigide.

La logique d'évaluation de la validité des offres CoW est trop faible (faille critique)

Le deuxième problème, et le plus grave, réside dans la logique de concurrence des offres du protocole CoW : dans son code de service public, toute offre dont les frais de gaz sont positifs et le montant de sortie non nul est considérée comme une « offre valide ».

Source : quote.rs:31

Pour un système de routage traitant des ordres à huit chiffres, c'est une définition étonnamment faible de « rationalité ».

Le système ne dispose pas de vérification de la santé des prix via un oracles, pas de mécanisme de blocage pour les offres décalées de plus de 500 fois le prix spot, pas d'évaluation des risques liés à un routage qui épuiserait complètement les pools de liquidité, pas d'alerte pour les incohérences sévères entre la liquidité de la dernière étape et la taille de la commande ; il suffit que le solveur retourne un routage exécutable et non nul pour qu'il soit accepté par le système — c'est la faille centrale de cet événement.

Défauts de la logique de modélisation de la liquidité de Uniswap V2

La troisième question concerne le modèle de piscine de liquidité de style Uniswap V2 : le code n'utilise que l'algorithme standard de produit constant et rejette uniquement les impossibilités mathématiques telles que les réserves nulles, les débordements numériques ou les débordements de réserves, sans vérifier la faisabilité économique.

Source : pool_fetching.rs:118 et pool_fetching.rs:153

Ce code ne vérifie pas si la liquidité du pool est suffisante pour absorber la transaction correspondante, il se contente de déterminer si l'opération d'échange est mathématiquement valide. Ainsi, un petit pool ne contenant que 331 AAVE sera considéré comme un endroit valide pour exécuter une demande d'achat de 17 957 WETH, simplement parce que l'algorithme de produit constant calcule un résultat non nul, tout en ignorant complètement que ce résultat entraînerait une perte catastrophique d'actifs.

Deuxième échec du SDK de prêt éclair et du mécanisme de vérification des commandes

Ensuite, le SDK de loan flash a directement intégré ce prix expiré dans la charge d'exécution de la commande et du hook, sans effectuer aucune autre interception de risque.

Ensuite :

Source : index.js:484 et index.js:591

C’est pourquoi j’ai toujours dit que ce chemin était « mauvais dès la naissance ». La couche d’adaptateur n’a pas « découvert » un nouveau montant défectueux à l’exécution ; elle a sérialisé la séquence de montants défectueux dans les données du hook et l’adresse de l’instance déterminée. Dès qu’une mauvaise cotation existe, les mécanismes restants la transmettent fidèlement.

Même la logique de vérification des ordres CoW ne protège pas réellement les utilisateurs ici, car elle ne vérifie que si l'ordre dépasse le prix du marché au moment de la cotation, sans évaluer si la cotation elle-même est absurde par rapport à la liquidité réelle.

Source : order_validation.rs:694

Ceci est une vérification de cohérence. Si le prix lui-même est déjà du charabia, la commande peut toujours être passée.

Le mécanisme d'alerte frontend de l'interface utilisateur est inefficace

L'interface Aave affiche effectivement un avertissement de choc de prix, mais ce n'est pas un interrupteur de coupure automatique. Lorsque la perte de valeur dépasse 20 %, elle devient une case de confirmation.

Une fois que l'utilisateur a coché la case, l'obstacle est levé :

Source : helpers.ts:24 et HighPriceImpactWarning.tsx:35

Ainsi, même si cette transaction réduit presque entièrement la valeur de l'actif, le système ne la classe que comme une opération nécessitant une confirmation de l'utilisateur, et non comme une transaction à haut risque que le système doit refuser catégoriquement, ce qui rend le mécanisme d'alerte totalement inefficace pour intercepter les risques.

À la lumière de la défaillance de tous ces mécanismes, je ne peux absolument pas accepter la conclusion superficielle selon laquelle « il s'agit simplement d'un utilisateur qui a commis une erreur ». L'utilisateur a effectivement signé, mais l'ensemble du système logiciel a eu à de nombreuses reprises l'occasion d'intercepter ce désastre, et à chaque niveau, il n'a effectué qu'une vérification de base, jugant « non nul, exécutable, signé » avant de le laisser passer directement, entraînant finalement des conséquences graves.

Cette étape est cruciale et élimine directement de nombreuses hypothèses erronées : le processus officiel de l'interface Aave pour aave-v3-interface-collateral-swap calcule le montant d'achat ajusté en fonction du slippage à la ligne 139 du fichier useSwapOrderAmounts.ts, en combinant le prix, les frais réseau, les frais de partenaire et les frais de loan flash ; à la ligne 331, il est converti en valeur buyAmountBigInt ; puis, au fichier CollateralSwapActionsViaCoWAdapters.tsx, ligne 191, ce montant est signé avec précision.

Le contrat adaptateur ultérieur vérifiera, à la ligne 141 du fichier AaveV3BaseAdapter.sol, que le champ de la commande signée correspond exactement à la valeur stockée ; le contrat de règlement CoW appliquera, à la ligne 337 du fichier GPv2Settlement.sol, les règles de limite stipulées dans la signature. Par conséquent, le résultat de l'exécution sur chaîne ne dépasse pas les limites autorisées par la commande signée, et les actifs reçus par l'utilisateur sont même supérieurs à la limite minimale convenue dans la signature.

Cela suffit à prouver : la catastrophe s'est produite avant le règlement, et non pendant, la faille critique du routage avait déjà scellé son destin.

La prochaine transaction dans le même bloc (commençant par le hachage 0x45388b0f) a réalisé un arbitrage de retrait sur le pool défectueux SushiSwap AAVE/WETH. Après que la transaction anormale ait saturé le pool avec une quantité massive de WETH et vidé la majeure partie de l'AAVE, l'arbitragiste a immédiatement revendu l'AAVE au sein du pool, capturant la valeur excédentaire générée par le déséquilibre de liquidité.

Au cours de cet arbitrage de backrunning, environ 17929,770158685933 WETH ont été extraits, puis environ 13087,73 ETH ont été payés au constructeur de bloc et environ 4824,31 ETH ont été payés à l'adresse d'exécution de l'arbitrage.

La valeur économique totale perdue par les utilisateurs est transformée presque instantanément en gains d'arbitrage MEV et en revenus pour les constructeurs de blocs au sein du même bloc.

De plus, la vérification de la séquence temporelle au niveau du bloc confirme : avant la transaction, personne n’a manipulé de manière malveillante le pool de SushiSwap pour tendre un piège aux utilisateurs ; la paire AAVE/WETH a été touchée pour la première fois lors de cette transaction anormale (index de transaction 1) ; la transaction suivante (index de transaction 2) a immédiatement profité de la distorsion de prix causée par cette transaction ; la transaction d’index 3 a également touché cette paire pendant le processus de rétablissement du marché. La chronologie confirme clairement : cette transaction anormale a créé une distorsion de prix extrême, et les transactions ultérieures ont directement capté ce profit déformé.

Si vous vous demandez si le protocole principal d'Aave V3 a connu une panne, la réponse est non. Les pools Aave ont exécuté les opérations comme prévu et ont terminé normalement le retrait de USDT et le dépôt d'AAVE.

Si vous vous demandez si le contrat GPv2Settlement de CoW a planté, la réponse est non. Le règlement a exécuté une commande signée valide et a payé un montant supérieur au minimum signé.

Si vous vous demandez si les contrats de paires de trading sur Uniswap V3 ou SushiSwap ont échoué, la réponse est non non plus. Les deux types de pools de trading ont effectué l'évaluation des prix selon leurs propres algorithmes.

Un échec systémique réel s'est produit au niveau supérieur des routages et de la gestion des risques :

La responsabilité principale incombe aux modules de routage, de cotation et de résolution du protocole CoW : le système dans son ensemble applique des critères trop faibles pour déterminer un « routage raisonnable », acceptant des ordres de plusieurs millions de dollars qui se terminent dans des piscines de faible liquidité, tant que le routage est exécutable et non nul, ignorant complètement l'absurdité économique extrême.

La partie responsable secondaire est l'interface frontale d'Aave : lors de la demande de cotation de l'adaptateur, les données de l'application associées au hook n'ont pas été incluses, les résultats d'erreur ont été transmis directement au processus de signature, et seules des alertes ont été utilisées sans mécanisme de refus obligatoire ; pour de telles transactions extrêmement importantes, ces mesures de gestion des risques sont totalement insuffisantes pour prévenir les risques.

Il s'agit d'un échec extrême de la qualité du routage des transactions et des barrières de contrôle des risques, ayant transformé une opération légale et conforme de rotation de garanties en un événement de perte d'actifs dévastatrice.