Le 10 mars, une erreur de configuration technique dans l'infrastructure oracle d'Aave a entraîné des liquidations forcées, mettant à l'épreuve la dépendance de la DeFi / Finance Décentralisée aux systèmes de gestion des risques automatisée.
L'événement de liquidation de 21,7 M$ sur Aave
Les utilisateurs d'Aave ont subi environ 21,7 M$ de liquidations le 10 mars après qu'une contrainte on-chain dans l'agent de risque Wrapped stETH (wstETH) ait entraîné une sous-évaluation des valeurs collatérales. Au total, 34 comptes ont été liquidés car le protocole a évalué le wstETH à environ 2,85 % en dessous de son véritable prix du marché.
Le protocole n'a finalement pas encouru de créances irrécouvrables et a compensé les utilisateurs affectés. Cependant, l'événement a exposé des faiblesses structurelles dans la manière dont la gestion des risques automatisée de la DeFi / Finance Décentralisée exécute des changements sans intervention humaine. Il a également montré à quelle vitesse un paramètre mal configuré peut se propager en liquidations à grande échelle de positions par ailleurs saines.
Selon les données post-incident, les utilisateurs détenant du wstETH comme collatéral contre une dette en WETH semblaient sous-collatéralisés uniquement en raison de l'évaluation incorrecte. De plus, leurs positions seraient restées sûres aux prix réels du marché, soulignant que la défaillance était infrastructurelle plutôt que liée au marché.
Les mécanismes de la défaillance CAPO
L'incident a pris naissance dans le système CAPO (Correlated Asset Price Oracle) d'Aave, conçu pour protéger contre la manipulation d'actifs aux prix corrélés, tels que wstETH et stETH. CAPO récupère le ratio wstETH/stETH depuis Lido, applique un plafond protecteur via le WstETHPriceCapAdapter, puis multiplie le résultat par le prix de l'ETH pour obtenir une évaluation en USD.
À 12h47 UTC le 10 mars, le moteur Edge Risk off-chain de Chaos Labs a recommandé de mettre à jour le prix maximum CAPO à 1,1933947 wstETH/ETH. À ce moment, le ratio réel du marché était de 1,2285, ce qui impliquait que le plafond proposé était déjà sensiblement inférieur aux prix en vigueur.
L'AgentHub de BGD a exécuté cette recommandation un bloc plus tard via son système Oracle Automation, sans aucun délai de révision entre la recommandation off-chain et l'implémentation on-chain. Cela dit, ce pipeline instantané est précisément ce qui a transformé une erreur de configuration en un événement impactant immédiatement les utilisateurs.
Le désalignement résultant de 2,85 % a conduit le protocole à sous-évaluer le collatéral wstETH. En conséquence, les comptes qui auraient dû être sûrs selon les données réelles du marché ont été signalés comme sous-collatéralisés et liquidés. La cascade a traité 10 938 wstETH sur 34 comptes et a généré environ 512 ETH de bonus de liquidation pour les liquidateurs avant que le problème ne soit détecté et corrigé.
Cause technique profonde : désalignement du snapshot
La défaillance technique provenait d'une incompatibilité de paramètres entre snapshotRatio et snapshotTimestamp au sein de CAPO. L'agent de risque off-chain de Chaos Labs a calculé un ratio cible d'environ 1,2282, ancré à un snapshot vieux de 7 jours. Cependant, le système on-chain limitait la vitesse à laquelle le ratio pouvait évoluer.
Selon les règles de protection de CAPO, la valeur on-chain précédente d'environ 1,1572 ne pouvait augmenter que de 3 % tous les 3 jours. En pratique, cela signifiait que le ratio ne pouvait augmenter que jusqu'à environ 1,1919 en une seule mise à jour, même si la cible off-chain avait dérivé plus haut. De plus, la mise à jour n'a pas aligné ces contraintes avec la logique du timestamp.
Le snapshotTimestamp a été défini comme si l'ancrage on-chain reflétait déjà le ratio off-chain vieux de 7 jours de 1,2282. Cela a créé une incohérence critique entre les références de temps et de prix. En conséquence, CAPO a calculé un taux de change maximum d'environ 1,1939, environ 2,85 % en dessous du taux réel du marché de 1,2285.
Cet incident a marqué la première mise à jour automatisée poussée on-chain par l'agent de risque CAPO de Chaos Labs depuis son déploiement. Cela dit, le fait que l'exécution inaugurale ait produit des liquidations d'utilisateurs a rendu la mauvaise configuration particulièrement alarmante pour la gouvernance et les utilisateurs.
La chaîne d'exécution automatisée d'Edge Risk à AgentHub
Edge Risk est le moteur de risque off-chain propriétaire de Chaos Labs qui prépare et pousse les changements de paramètres depuis une adresse désignée. AgentHub, développé par BGD, écoute ces changements en utilisant Oracle Automation puis les propage au protocole.
Le changement de paramètre défectueux a traversé la pile de risque automatisée de Chaos Labs en une séquence de deux transactions. Premièrement, le moteur Edge Risk a recommandé de changer le plafond à 1,191926 wstETH/ETH dans la transaction 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. Ensuite, AgentHub a exécuté le changement un bloc plus tard via la transaction 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.
Les liquidations quotidiennes sur Aave en février étaient relativement modestes, dépassant rarement 5 M$, car les conditions du marché restaient stables. Le pic du 10 mars à 21,6 M$ se distingue comme une valeur aberrante isolée, représentant environ un bond de 4x par rapport aux niveaux typiques. De plus, les volumes de liquidation sont rapidement revenus à la normale après la correction, confirmant que le stress provenait du chemin oracle plutôt que d'une insolvabilité plus large du protocole.
Ce comportement a renforcé la conclusion que le problème de tarification du wstETH était une défaillance de configuration discrète. Ce n'était pas un symptôme de détérioration de la qualité du collatéral, de problèmes de liquidité ou de désendettement systémique au sein de l'écosystème Aave.
Détection, atténuation et plan de compensation de liquidation
La mauvaise configuration a été détectée en quelques minutes, déclenchant une réponse accélérée de l'équipe Aave et de ses fournisseurs de risques. Pour contenir une exposition supplémentaire, les plafonds d'emprunt de wstETH sur Aave Core et Aave Prime ont été rapidement réduits à 1, gelant efficacement toute nouvelle activité d'emprunt contre cet actif.
Par une intervention manuelle du Risk Steward, l'équipe a réaligné le snapshotRatio avec le snapshotTimestamp en direct, restaurant le flux oracle à sa valeur correcte. Une correction oracle a été poussée via la transaction 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d, tandis que les changements de plafond d'emprunt pour définir la capacité d'emprunt de wstETH à 1 wstETH ont été exécutés via la transaction 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.
Malgré la vente forcée, le protocole n'a encouru aucune créance irrécouvrable et a publié une analyse post-mortem détaillée sur les forums de gouvernance d'Aave. Cependant, les pertes d'utilisateurs dues aux liquidations ont nécessité une réponse politique distincte, conduisant finalement à un plan de compensation de liquidation structuré.
Pour compenser les comptes affectés, Aave a récupéré 141,5 ETH de bonus de liquidation grâce aux remboursements BuilderNet. La trésorerie DAO a ensuite couvert l'écart restant, la restitution totale aux utilisateurs étant plafonnée à 358 ETH. Fait important, le plan a été mis en œuvre via une Proposition d'amélioration Aave (AIP) directe, garantissant que les utilisateurs affectés reçoivent une compensation complète malgré l'erreur provenant de l'infrastructure.
Contexte du marché autour de l'incident du 10 mars
L'activité cross-chain sur Aave a montré une croissance robuste des utilisateurs pendant la période février-mars. Par exemple, Avalanche a enregistré 38 445 utilisateurs déposants le 10 février, tandis que Base a enregistré 31 763 utilisateurs déposants le 6 mars, soit quatre jours avant l'événement de liquidation piloté par l'oracle.
Ces pics soulignent l'engagement croissant des utilisateurs sur les réseaux pris en charge par Aave, même si le protocole naviguait dans un incident technique complexe. De plus, les dépôts et emprunts globaux d'Aave sont restés stables tout au long du début de 2026, suggérant que la confiance dans la conception de base du protocole ne s'est pas matériellement affaiblie après l'événement.
La stabilité des dépôts, combinée à la normalisation rapide des liquidations, souligne que l'erreur de tarification du wstETH provenait de problèmes de configuration, et non d'un stress fondamental sur les marchés collatéraux. Cela dit, le risque de concentration chez les fournisseurs d'automatisation et les chemins d'oracle reste une préoccupation structurelle pour les plateformes DeFi / Finance Décentralisée à l'échelle d'Aave.
Gouvernance, transparence et avenir de l'exécution oracle automatisée
L'incident du 10 mars illustre les compromis de gouvernance créés par l'exécution oracle automatisée dans les principaux protocoles de prêt DeFi / Finance Décentralisée. Edge Risk de Chaos Labs a recommandé un plafond en dessous du marché, l'AgentHub de BGD l'a exécuté un bloc plus tard, et les liquidations ont suivi en quelques minutes, ne laissant presque aucun temps pour une intervention humaine.
Aave a répondu par une détection rapide, des actions correctives décisives et une compensation complète des utilisateurs financée en partie par la trésorerie DAO. Cependant, l'épisode a révélé des lacunes dans la validation pré-exécution et a mis en évidence les risques d'une dépendance excessive à un moteur de risque unique et propriétaire. En particulier, la nature fermée des calculs d'Edge Risk de Chaos Labs limite la vérification indépendante et place un contrôle opérationnel significatif entre les mains de fournisseurs de services externes.
Alors que davantage de protocoles DeFi / Finance Décentralisée adoptent des cadres d'agents de risque CAPO automatisés et des systèmes similaires, l'incident montre que la gouvernance doit intégrer des tests robustes, des fenêtres de révision explicites et une surveillance transparente. De plus, l'architecture oracle plus large d'Aave aura probablement besoin de couches de sécurité supplémentaires, telles que des vérifications croisées multi-sources ou des mécanismes de déploiement par étapes, pour garantir que les futures erreurs techniques ne se traduisent pas directement en pertes pour les utilisateurs.
En résumé, les liquidations du 10 mars n'étaient pas une crise du marché mais un test de résistance de gouvernance et d'infrastructure. La combinaison de l'automatisation, de l'exécution rapide et de la modélisation opaque des risques souligne pourquoi les protocoles DeFi / Finance Décentralisée doivent équilibrer l'efficacité avec des garde-fous transparents et vérifiables pour protéger les utilisateurs.
Source : https://en.cryptonomist.ch/2026/03/23/aave-oracle-liquidations/
