Den 4 november klockan 05:45:11 UTC utnyttjades Moonwell-protokollet via ett Chainlink-orakelfel som rapporterade andrahandsmarknadspriser, vilket ledde till en förlust på 1 miljon dollar.

2/ Chainlink wrsETH-oraklet borde ha rapporterat 1,057; Den rapporterade dock 1,7 miljoner, en avvikelse på 7 storleksordningar, vilket möjliggjorde attacken.

3/ Även om vi inte kan bekräfta Chainlink-prissättningsmetodiken, på grund av tidsnärheten till exploateringen, ser det ut som att de var beroende av pooler med utarmad likviditet, efter Balancer-exploateringen.

4/ Intressant att observera: 1) Fler noder ≠ mer säkerhet 2) Kvaliteten på nodoperatörerna spelar roll. Skärmdumpen nedan visar att i den här prisomgången var juryn delad; Vissa rapporterade uppblåsta värden, medan minoriteten rapporterade det korrekta priset.

5/ Chainlinks orakel prissatte wrsETH fel till 5,8 miljarder dollar Detta var 1,7 miljoner gånger den verkliga räntan. Det är uppenbart att det saknas viktiga skyddsräcken, t.ex. CAPO-begränsare eller likviditetskrav på datakällor. En påminnelse: prisflöden är risksystem.

6/ Price Oracle vs. Risk Oracle är en falsk dikotomi. Du kan inte skilja pris från risk. Tillgångsklasser exploderar: - Förpackade tillgångar - RWA -Derivat -etc. I takt med att tillgångarna blir mer sofistikerade räcker det inte längre med "medianen av ogranskade flöden".

7/ Vad bör vara tillvägagångssättet för prissättning av tillgångsbaserade säkerheter? För inslagna tillgångar följer prissättningen vanligtvis den primära växelkursen. Moonwell antog dock att man skulle använda Chainlink-marknadsoraklet, ett icke-standardiserat val för en looping-tillgång som wETH.

8/ Att använda en andrahandsmarknadsränta för en looping-säkerhet är oregelbundet - men det var inte den direkta orsaken till exploateringen. Det verkliga problemet är strukturellt.

9/ Denna exploatering belyser den saknade länken mellan Oracle-design och riskintelligens. Varje dataflöde som integreras på en marknad bör genomgå samma granskning som alla säkerheter: det bör testas, övervakas och begränsas av verkställbara gränser. Orakel är risksystem.

10/ För alla som är intresserade av möjliga åtgärder I det här fallet finns det några, från valet av foder till implementeringen av det. @aave har implementerat CAPO-ramverket, som fungerar som en övre gräns för växelkursorakel för att förhindra manipulation.