Comment une défaillance d'oracle Aave a déclenché des liquidations de 21,7 millions de dollars et a testé la gouvernance des risques dans la DeFi

Le 10 mars, une mauvaise configuration technique dans l’infrastructure de l’oracle Aave a entraîné des liquidations forcées, mettant à l’épreuve la dépendance de la finance décentralisée (DeFi) aux systèmes automatisés de gestion des risques.

L’événement de liquidation de 21,7 millions de dollars sur Aave

Les utilisateurs d’Aave ont subi environ 21,7 millions de dollars de liquidations le 10 mars, après qu’une contrainte en chaîne dans l’agent de risque Wrapped stETH (wstETH) a sous-estimé la valeur de la garantie. Au total, 34 comptes ont été liquidés car le protocole évaluait le wstETH à environ 2,85 % en dessous de son prix réel sur le marché.

Finalement, le protocole n’a enregistré aucune dette impayée et a indemnisé les utilisateurs affectés. Cependant, cet incident a révélé des faiblesses structurelles dans la façon dont la gestion automatisée des risques de la DeFi exécute les changements sans intervention humaine. Il a aussi montré à quelle vitesse une paramètre mal configuré peut entraîner des liquidations à grande échelle de positions autrement saines.

Selon les données post-incident, les utilisateurs détenant du wstETH en garantie contre une dette en WETH semblaient sous-garantis uniquement à cause de la mauvaise valorisation. De plus, leurs positions seraient restées sûres aux prix réels du marché, ce qui souligne que la défaillance était d’ordre infrastructurel plutôt que liée au marché.

Mécanique de la défaillance du CAPO

L’incident a débuté dans le système CAPO (Correlated Asset Price Oracle) d’Aave, conçu pour se protéger contre la manipulation d’actifs à prix corrélés, comme le wstETH et le stETH. CAPO récupère le ratio wstETH/stETH depuis Lido, applique un plafond de protection via le WstETHPriceCapAdapter, puis multiplie le résultat par le prix de l’ETH pour obtenir une valorisation en USD.

Le 10 mars à 12h47 UTC, le moteur de risque hors chaîne de Chaos Labs a recommandé de mettre à jour le prix maximum du CAPO à 1,1933947 wstETH/ETH. À ce moment-là, le ratio réel du marché était de 1,2285, ce qui signifiait que le plafond proposé était déjà nettement inférieur aux prix en vigueur.

AgentHub de BGD a exécuté cette recommandation un bloc plus tard via son système d’automatisation de l’oracle, sans période de revue entre la recommandation hors chaîne et la mise en œuvre en chaîne. Ce pipeline instantané a précisément transformé une erreur de configuration en un événement impactant immédiatement les utilisateurs.

Ce décalage de 2,85 % a conduit le protocole à sous-estimer la valeur du wstETH en garantie. En conséquence, des comptes qui auraient été considérés comme sûrs selon les données du marché ont été signalés comme sous-garantis et liquidés. La cascade a traité 10 938 wstETH répartis sur 34 comptes, générant environ 512 ETH en bonus de liquidation pour les liquidateurs avant que le problème ne soit détecté et corrigé.

Cause technique racine : décalage de snapshot

La défaillance technique provenait d’un décalage entre le paramètre snapshotRatio et le timestamp snapshot dans CAPO. L’agent de risque hors chaîne de Chaos Labs a calculé un ratio cible d’environ 1,2282, basé sur un snapshot datant de 7 jours. Cependant, le système en chaîne limitait la rapidité avec laquelle ce ratio pouvait évoluer.

Selon les règles de protection de CAPO, la valeur précédente en chaîne d’environ 1,1572 ne pouvait augmenter que de 3 % tous les 3 jours. En pratique, cela signifiait que le ratio ne pouvait atteindre qu’environ 1,1919 lors d’une seule mise à jour, même si la cible hors chaîne avait augmenté. De plus, la mise à jour n’a pas aligné ces contraintes avec la logique de timestamp.

Le timestamp du snapshot était fixé comme si l’ancrage en chaîne reflétait déjà le ratio hors chaîne de 1,2282 datant de 7 jours. Cela a créé une incohérence critique entre le temps et la référence de prix. En conséquence, CAPO a calculé un taux d’échange maximum d’environ 1,1939, soit 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 en chaîne effectuée par l’agent de risque CAPO de Chaos Labs depuis son déploiement. Le fait que cette première exécution ait entraîné des liquidations d’utilisateurs a rendu la mauvaise configuration particulièrement alarmante pour la gouvernance et les utilisateurs.

Chaîne d’exécution automatisée de Edge Risk à AgentHub

Edge Risk est le moteur de risque hors chaîne 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, surveille ces changements via 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 deux transactions. D’abord, le moteur Edge Risk a recommandé de modifier le plafond à 1,191926 wstETH/ETH dans la transaction 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. Ensuite, AgentHub a exécuté cette modification un bloc plus tard via la transaction 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.

Les liquidations quotidiennes sur Aave en février étaient relativement modestes, dépassant rarement 5 millions de dollars, car les conditions du marché restaient stables. La hausse du 10 mars à 21,6 millions de dollars constitue une exception isolée, environ 4 fois le niveau habituel. De plus, les volumes de liquidation sont rapidement revenus à la normale après la correction, confirmant que la stress venait du chemin de l’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 isolée. Il ne s’agissait pas d’un symptôme de dégradation de la qualité des garanties, de problèmes de liquidité ou de désendettement systémique dans l’écosystème Aave.

Détection, mitigation et plan de compensation des liquidations

La mauvaise configuration a été détectée en quelques minutes, ce qui a permis à l’équipe d’Aave et à ses fournisseurs de risque d’intervenir rapidement. Pour limiter l’exposition, les plafonds d’emprunt en wstETH sur Aave Core et Aave Prime ont été rapidement réduits à 1, bloquant ainsi tout nouveau prêt contre cet actif.

Grâce à l’intervention manuelle du Risk Steward, l’équipe a réaligné le snapshotRatio avec le snapshotTimestamp en direct, restaurant la feed de l’oracle à sa valeur correcte. Une correction de l’oracle a été effectuée via la transaction 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d, tandis que les modifications du plafond d’emprunt pour fixer la capacité d’emprunt en wstETH à 1 wstETH ont été exécutées via la transaction 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.

Malgré la vente forcée, le protocole n’a enregistré aucune dette impayée et a publié une analyse détaillée sur les forums de gouvernance d’Aave. Cependant, les pertes des utilisateurs dues aux liquidations ont nécessité une réponse politique distincte, aboutissant finalement à un plan structuré de compensation.

Pour indemniser les comptes affectés, Aave a récupéré 141,5 ETH en bonus de liquidation via des remboursements BuilderNet. La trésorerie du DAO a ensuite couvert le reste, avec une restitution totale aux utilisateurs plafonnée à 358 ETH. Il est important de noter que ce plan a été mis en œuvre via une proposition d’amélioration d’Aave (AIP), garantissant que les utilisateurs affectés aient reçu une compensation intégrale malgré l’origine de l’erreur dans 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 durant la période février-mars. Par exemple, Avalanche a enregistré 38 445 utilisateurs déposants le 10 février, tandis que Base comptabilisait 31 763 utilisateurs déposants le 6 mars, à seulement quatre jours de l’événement de liquidation piloté par l’oracle.

Ces pics illustrent l’engagement croissant des utilisateurs sur les réseaux supportés par Aave, même en naviguant une incident technique complexe. De plus, le total des dépôts et emprunts sur Aave est resté stable tout au long du début 2026, suggérant que la confiance dans la conception fondamentale du protocole n’a pas été significativement affaiblie après l’incident.

La stabilité des dépôts, combinée à la rapide normalisation des liquidations, indique que le problème de tarification du wstETH provenait d’un souci de configuration, et non d’un stress fondamental sur les marchés de garanties. Cependant, le risque de concentration dans les fournisseurs d’automatisation et les chemins de l’oracle demeure une préoccupation structurelle pour les plateformes DeFi à l’échelle d’Aave.

Gouvernance, transparence et l’avenir de l’exécution automatisée des oracles

L’incident du 10 mars illustre les compromis de gouvernance liés à l’exécution automatisée des oracles dans les principaux protocoles de prêt DeFi. La recommandation de Chaos Labs pour un plafond inférieur au marché, l’exécution par AgentHub un bloc plus tard, et les liquidations qui ont suivi en quelques minutes, ont laissé peu de temps à l’intervention humaine.

Aave a réagi rapidement avec une détection efficace, des actions correctives décisives, et une indemnisation complète des utilisateurs financée en partie par la trésorerie du DAO. Cependant, cet épisode a révélé des lacunes dans la validation pré-exécution et souligné les risques liés à une dépendance excessive à un moteur de risque propriétaire unique. En particulier, la nature fermée des calculs de Chaos Labs Edge Risk limite la vérification indépendante et confie un contrôle opérationnel important à des prestataires externes.

Alors que davantage de protocoles DeFi adoptent des cadres automatisés de type CAPO Risk Agent et systèmes similaires, cet incident montre que la gouvernance doit intégrer des tests rigoureux, des fenêtres de revue explicites, et une supervision transparente. De plus, l’architecture globale de l’oracle d’Aave devra probablement intégrer des couches de sécurité supplémentaires, telles que des vérifications croisées multi-sources ou des mécanismes de déploiement progressif, pour éviter que de futures erreurs techniques ne se traduisent directement par des pertes pour les utilisateurs.

En résumé, les liquidations du 10 mars n’ont pas constitué une crise de marché, mais un test de gouvernance et d’infrastructure. La combinaison d’automatisation, d’exécution rapide et de modélisation des risques opaque souligne l’importance pour les protocoles DeFi de trouver un équilibre entre efficacité et mesures de sécurité transparentes et vérifiables pour protéger les utilisateurs.