Je viens de me mettre à jour sur ce qui s’est passé avec l’événement de liquidation d’Aave en mars, et honnêtement, la cause principale est assez folle. Chaos Labs a publié leur analyse et a essentiellement confirmé qu’il s’agissait d’un problème classique de configuration d’oracle — ce genre de chose qui peut entraîner de graves problèmes si on ne surveille pas de près.

Voici ce qui s’est passé : l’oracle de risque CAPO avait ce problème de contrainte où le paramètre snapshotRatio était plafonné à seulement 3 % de croissance tous les 3 jours. Il devait passer d’environ 1.1572 à 1.2282, mais ne pouvait qu’augmenter jusqu’à 1.1919. Pendant ce temps, le timestamp snapshotTimestamp a simplement été mis à jour normalement avec un timestamp datant de 7 jours. Ce décalage entre les deux paramètres ? C’est là que tout a commencé à se désagréger.

En raison de ce décalage, le plafond du taux de change calculé par CAPO s’est retrouvé environ 2,85 % en dessous du taux du marché réel — environ 1.1939 contre la réalité. Cet écart a déclenché la liquidation d’environ 10 938 wstETH. Pas une petite somme. La partie folle, c’est que le protocole lui-même n’a pas subi de pertes dues à des dettes impayées, donc au moins, il y a ça.

Ce qui est intéressant, c’est la rapidité de la réaction. Chaos Labs et BGD Labs ont immédiatement réagi, ont réduit le plafond d’emprunt wstETH à 1 pour arrêter toute cascade de liquidations, et ont manuellement réaligné les paramètres via Risk Steward. Ils ont récupéré 141,5 ETH via BuilderNet pour commencer à compenser les utilisateurs, le reste étant couvert par le trésor d’Aave. La compensation totale par la DAO ? On s’attendait à moins de 345 ETH.

Tout ce scénario de liquidation est un rappel solide de la sensibilité de ces systèmes d’oracle. Une erreur de configuration et voilà que vous avez des mouvements inattendus de dizaines de millions. C’est clairement quelque chose à surveiller si vous détenez des positions dans ces protocoles.