1/ Le 4 novembre à 05:45:11 AM UTC, le protocole Moonwell a été exploité via un dysfonctionnement de l'oracle Chainlink qui a signalé des prix de marché secondaires, entraînant une perte de 1 million de dollars.

2/ L'oracle wrsETH de Chainlink aurait dû rapporter 1,057 ; cependant, il a rapporté 1,7 m, une différence de 7 ordres de grandeur, permettant l'attaque.

3/ Bien que nous ne puissions pas confirmer la méthodologie de tarification de Chainlink, en raison de la proximité temporelle avec l'exploitation, il semble qu'ils dépendaient de pools avec une liquidité épuisée, après l'exploitation de Balancer.

4/ Intéressant à observer : 1) plus de nœuds ≠ plus de sécurité 2) la qualité des opérateurs de nœuds compte. La capture d'écran ci-dessous montre que lors de ce tour de prix, le jury était partagé ; certains ont signalé des valeurs gonflées, tandis que la minorité a rapporté le prix correct.

5/ L'oracle de Chainlink a mal évalué le wrsETH à 5,8 milliards de dollars C'était 1,7 million de fois le taux réel. Manquant clairement de garde-fous essentiels, tels que des limiteurs CAPO ou des exigences de liquidité sur les sources de données. Un rappel : les flux de prix sont des systèmes à risque.

6/ L'oracle de prix contre l'oracle de risque est un faux dilemme. Vous ne pouvez pas séparer le prix du risque. Les classes d'actifs explosent : - actifs enveloppés - RWAs - dérivés - etc. À mesure que la sophistication des actifs augmente, "la médiane des flux non vérifiés" ne suffit plus.

7/ Quelle devrait être l'approche pour la tarification des garanties adossées à des actifs ? Pour les actifs enveloppés, la tarification suit généralement le taux de change principal. Cependant, Moonwell a supposé l'utilisation de l'oracle de marché Chainlink, un choix non standard pour un actif en boucle comme le wETH.

8/ Utiliser un taux de marché secondaire pour un collatéral en boucle est irrégulier - mais ce n'était pas la cause directe de l'exploitation. Le véritable problème est structurel.

9/ Cette exploitation met en évidence le lien manquant entre la conception des Oracles et l'intelligence des risques. Chaque flux de données intégré dans un marché devrait subir le même examen que tout collatéral : il devrait être testé, surveillé et limité par des limites applicables. Les Oracles sont des systèmes de risque.

10/ Pour quiconque intéressé par d'éventuelles atténuations Dans ce cas, il y en a quelques-unes, de la sélection du flux à sa mise en œuvre. @aave a mis en œuvre le cadre CAPO, qui sert de limite supérieure pour les oracles de taux de change afin de prévenir la manipulation.