Oracle Aave déraille : 26M$ liquidés

Imaginez : vous êtes confortablement installé dans une stratégie DeFi jugée solide sur Aave, avec un health factor qui oscille gentiment au-dessus de 1,1… et en quelques minutes, sans aucun mouvement de marché majeur, votre position est balayée par une vague de liquidations mécaniques. C’est exactement ce qui est arrivé à plusieurs dizaines d’utilisateurs le 10 mars 2026. Le coupable ? Un simple décalage technique dans l’oracle CAPO du protocole le plus utilisé en lending décentralisé.

En l’espace de quelques heures, environ 26 millions de dollars d’actifs ont été liquidés, principalement sur des positions wstETH. Pourtant, ni le marché global ni la solvabilité d’Aave n’ont été réellement menacés. Alors comment un bug aussi « bénin » a-t-il pu générer un tel choc ? Plongeons dans les détails de cet incident qui rappelle à quel point la DeFi reste une ingénierie de précision fragile.

Un incident technique aux conséquences financières immédiates

Le 10 mars 2026 vers midi UTC, plusieurs utilisateurs d’Aave sur les instances Ethereum Core et Prime ont vu leurs positions liquidées sans raison apparente liée au marché. Le prix du wstETH affiché par l’oracle CAPO (Correlated Asset Price Oracle) s’est soudainement décalé d’environ 2,85 % sous le taux réel du marché. Pour des positions en E-Mode très optimisées, ce petit écart a suffi à faire passer le health factor sous la barre critique de 1.

En tout, 10 938 wstETH ont été liquidés, touchant 34 comptes distincts. Les liquidateurs externes ont empoché environ 512 ETH de profits (bonus de liquidation + écart de prix réalisé). Mais surtout : Aave n’a pas subi de mauvaise dette. Le protocole est resté parfaitement solvable. C’est donc bien un événement « localisé »… mais très douloureux pour les utilisateurs concernés.

Comment fonctionne l’oracle CAPO ?

CAPO est un mécanisme de sécurité spécifique aux actifs qui portent un rendement natif, comme le wstETH par rapport au stETH sous-jacent. Son rôle principal est double :

• empêcher une inflation artificielle ou une manipulation du ratio wstETH/stETH
• limiter les hausses brutales du ratio pour éviter des comportements anormaux

Concrètement, CAPO applique une borne supérieure déterministe sur le taux de change. Cette borne évolue lentement grâce à deux paramètres cruciaux :

• le snapshot ratio : la valeur de référence du ratio wstETH/stETH
• le snapshot timestamp : l’horodatage associé à cette valeur de référence

La règle est stricte : le ratio ne peut augmenter que de 3 % maximum tous les trois jours. Cette limite protège contre des attaques d’inflation ou des manipulations flash. Mais elle crée aussi une rigidité qui, mal gérée, peut devenir dangereuse.

La faute à une mise à jour mal synchronisée

Lors d’une mise à jour de routine du ratio de référence, l’algorithme hors-chaîne a tenté de pousser la valeur vers le ratio réel du marché. Problème : le contrat intelligent a plafonné mécaniquement l’augmentation à cause de la règle des 3 % / 3 jours. Jusque-là, rien d’anormal.

Mais dans le même temps, l’horodatage (timestamp) a été mis à jour sans aucune restriction. Résultat : on se retrouve avec un snapshot timestamp récent… mais un snapshot ratio bloqué à une valeur trop basse. L’oracle calcule alors un taux maximal autorisé 2,85 % inférieur au vrai prix du marché.

« Une simple désynchronisation entre le ratio et son horodatage a suffi à rendre liquidables des positions saines. »

Post-mortem officiel Aave

Cette petite erreur de configuration a créé une distorsion temporaire mais suffisante pour déclencher le processus automatique de liquidation sur les positions les plus sensibles, notamment celles en E-Mode wstETH/stETH.

Réaction immédiate des équipes

Dès les premières alertes, Chaos Labs (prestataire risk & monitoring d’Aave) a identifié l’anomalie. Les actions prises ont été rapides :

• réduction immédiate des borrow limits sur wstETH à leur valeur minimale
• correction manuelle des paramètres CAPO pour réaligner ratio et timestamp
• rétablissement progressif des conditions normales une fois le bug corrigé

Moins de deux heures après le début de l’incident, la situation était stabilisée et aucun nouvel utilisateur n’a été affecté après la correction.

26 millions de dollars… mais zéro mauvaise dette

L’un des points les plus rassurants de cet incident est l’absence totale de mauvaise dette (bad debt) pour le protocole. Toutes les positions ont été liquidées dans les règles, les collatéraux ont couvert les emprunts, et les liquidateurs ont été payés normalement. Aave reste donc parfaitement solvable, même après un choc de cette ampleur.

Cela montre la robustesse globale du système… mais aussi sa sensibilité aux micro-déviations d’oracle sur des stratégies très leviéragées.

Le plan de compensation intégral

Face à la colère légitime des utilisateurs touchés, Aave a annoncé un remboursement complet des pertes nettes subies (hors bonus de liquidation empochés par les liquidateurs). Le financement provient de deux sources :

• 141 ETH déjà récupérés via BuilderNet (remboursement des bonus de liquidation)
• jusqu’à 358 ETH supplémentaires prélevés sur la trésorerie de la DAO Aave

Le total maximal de compensation est donc estimé autour de 500 ETH, soit environ 1,25 million de dollars au cours du 12 mars 2026. Les utilisateurs lésés recevront une proposition de gouvernance spécifique pour valider les montants exacts et les modalités de distribution.

« Nous assumons pleinement la responsabilité opérationnelle de cette erreur de configuration. Les utilisateurs ne doivent pas payer le prix d’une mauvaise synchronisation technique. »

Stani Kulechov – fondateur Aave

Cette prise de position rapide et ferme contraste avec certains incidents passés où les DAOs avaient laissé les utilisateurs absorber les pertes. Ici, la communauté semble unie derrière l’idée d’une indemnisation totale.

Ce que cet incident nous apprend sur la DeFi en 2026

Même si l’événement reste marginal (0,0027 % de la TVL totale d’Aave), il met en lumière plusieurs réalités persistantes du paysage DeFi actuel :

• la complexité croissante des mécanismes de protection peut paradoxalement créer de nouveaux vecteurs de risque
• la dépendance aux mises à jour hors-chaîne reste un point faible majeur
• les stratégies E-Mode à haut levier sont extrêmement sensibles aux micro-déviations d’oracle
• la rapidité de réaction des équipes et la transparence restent les meilleurs remparts contre la perte de confiance

On est loin des hacks massifs de 2022-2023, mais on voit que même les protocoles les plus matures ne sont pas à l’abri d’erreurs opérationnelles.

CAPO est-il intrinsèquement défectueux ?

Chaos Labs a été très clair : l’incident ne provient pas d’un défaut de conception du système CAPO lui-même, mais d’une erreur d’exécution lors de la mise à jour des paramètres sous les contraintes du contrat intelligent.

Des mesures supplémentaires ont déjà été déployées :

• surveillance accrue et alerte automatique sur tout décalage ratio/timestamp
• double validation humaine avant toute mise à jour critique du ratio
• tests plus fréquents des scénarios de plafonnement

Reste à savoir si ces garde-fous suffiront à éviter un bis repetita dans les prochains mois.

Et maintenant ? Perspectives pour Aave et ses utilisateurs

À court terme, l’incident ne devrait pas affecter durablement la domination d’Aave sur le lending décentralisé. Le protocole continue d’afficher des volumes records et reste le leader incontesté du secteur.

À moyen terme, plusieurs questions se posent :

• la communauté acceptera-t-elle facilement le prélèvement sur la trésorerie DAO ?
• va-t-on voir une réduction volontaire de l’usage de l’E-Mode sur les paires wstETH ?
• d’autres protocoles utilisant des mécanismes similaires (Morpho, Compound v3, etc.) vont-ils durcir leurs propres oracles ?

Une chose est sûre : cet événement va probablement accélérer la mise en place de redondances d’oracles et de systèmes de kill-switch plus agressifs sur l’ensemble de la DeFi.

Conclusion : la maturité n’efface pas la complexité

Aave est aujourd’hui le protocole DeFi le plus utilisé, le plus audité, le plus institutionnalisé… et pourtant, une simple erreur de synchronisation a suffi à générer 26 millions de dollars de liquidations. Cela rappelle une vérité fondamentale : dans un écosystème où tout est automatisé, immuable et permissionless, la moindre imperfection opérationnelle peut avoir des conséquences immédiates et très coûteuses.

Heureusement, la réponse rapide, transparente et responsable des équipes limite fortement les dégâts collatéraux. Reste à transformer cet incident en leçon collective pour rendre la DeFi un peu plus antifragile. Car si la confiance est déjà difficile à obtenir dans cet univers, la perdre à cause d’un bug évitable serait impardonnable.

Et vous, que pensez-vous de cet événement ? Faut-il durcir encore plus les garde-fous au risque de perdre en efficacité, ou accepter que ce genre d’incident fasse partie du jeu ? La discussion est ouverte.