1/ Op 4 november om 05:45:11 AM UTC werd het Moonwell-protocol geëxploiteerd via een Chainlink-orakelstoring die secundaire marktprijzen rapporteerde, wat leidde tot een verlies van $1 miljoen.

2/ De Chainlink wrsETH oracle had 1.057 moeten rapporteren; echter, het rapporteerde 1.7m, een discrepantie van 7 ordes van grootte, waardoor de aanval mogelijk werd.

3/ Hoewel we de prijsbepalingsmethodologie van Chainlink niet kunnen bevestigen, lijkt het door de tijds nabijheid tot de exploit erop dat ze afhankelijk waren van pools met uitgeputte liquiditeit, na de Balancer-exploit.

4/ Interessant om te observeren: 1) meer knooppunten ≠ meer veiligheid 2) de kwaliteit van knooppuntoperators is belangrijk. De screenshot hieronder toont aan dat in deze prijsronde de jury verdeeld was; sommigen meldden opgeblazen waarden, terwijl de minderheid de juiste prijs meldde.

5/ Chainlink’s oracle heeft wrsETH verkeerd geprijsd op $5,8B Dit was 1,7 miljoen keer de werkelijke koers. Duidelijk ontbreken van belangrijke beveiligingen, zoals CAPO-limieten of liquiditeitsvereisten op gegevensbronnen. Een herinnering: prijsfeeds zijn risicosystemen.

6/ Price Oracle versus Risk Oracle is een valse dichotomie. Je kunt prijs niet scheiden van risico. Activaklassen exploderen: - gewrapte activa - RWAs - derivaten - enz. Naarmate de verfijning van activa toeneemt, is "mediaan van ongeverifieerde feeds" niet meer voldoende.

7/ Wat zou de aanpak moeten zijn voor het prijzen van activa-gedekte onderpanden? Voor gewrapte activa volgt de prijsstelling meestal de primaire wisselkoers. Echter, Moonwell heeft de keuze gemaakt om de Chainlink-marktorakel te gebruiken, een niet-standaard keuze voor een looping activa zoals wETH.

8/ Het gebruik van een secundaire marktprijs voor een circulerende onderpand is onregelmatig - maar het was niet de directe oorzaak van de exploit. Het echte probleem is structureel.

9/ Deze exploit benadrukt de ontbrekende schakel tussen Oracle-ontwerp en risicoinformatie. Elke gegevensstroom die in een markt is geïntegreerd, zou dezelfde controle moeten ondergaan als elke onderpand: het zou getest, gemonitord en begrensd moeten worden door afdwingbare limieten. Oracles zijn risicosystemen.

10/ Voor iedereen die geïnteresseerd is in mogelijke mitigaties In dit geval zijn er een paar, van de selectie van de feed tot de implementatie ervan. @aave heeft het CAPO-framework geïmplementeerd, dat dient als een bovengrens voor wisselkoers-orakels om manipulatie te voorkomen.