1/ Il 4 novembre alle 05:45:11 AM UTC, il protocollo Moonwell è stato sfruttato a causa di un malfunzionamento dell'oracolo Chainlink che ha riportato i prezzi del mercato secondario, portando a una perdita di 1 milione di dollari.

2/ L'oracolo wrsETH di Chainlink avrebbe dovuto segnalare 1.057; tuttavia, ha segnalato 1.7m, una discrepanza di 7 ordini di grandezza, che ha reso possibile l'attacco.

3/ Sebbene non possiamo confermare la metodologia di pricing di Chainlink, a causa della prossimità temporale all'exploit, sembra che fossero dipendenti da pool con liquidità esaurita, dopo l'exploit di Balancer.

4/ Interessante osservare: 1) più nodi ≠ maggiore sicurezza 2) la qualità degli operatori di nodo è importante. Lo screenshot qui sotto mostra che in questo giro di prezzi, la giuria era divisa; alcuni hanno segnalato valori gonfiati, mentre la minoranza ha riportato il prezzo corretto.

5/ L'oracolo di Chainlink ha sovrastimato wrsETH a $5.8B Questo era 1.7 milioni di volte il tasso reale. Chiaramente mancano guardrail chiave, come i limitatori CAPO o i requisiti di liquidità sulle fonti di dati. Un promemoria: i feed dei prezzi sono sistemi di rischio.

6/ L'Oracolo dei Prezzi contro l'Oracolo del Rischio è un falso dilemma. Non puoi separare il prezzo dal rischio. Le classi di attivi stanno esplodendo: - attivi avvolti - RWAs - derivati - ecc. Con la crescente sofisticazione degli attivi, "la media dei feed non verificati" non è più sufficiente.

7/ Quale dovrebbe essere l'approccio per la valutazione del collaterale supportato da attivi? Per gli attivi avvolti, la valutazione di solito segue il tasso di cambio primario. Tuttavia, Moonwell ha assunto l'uso dell'oracolo di mercato Chainlink, una scelta non standard per un attivo ciclico come wETH.

8/ Utilizzare un tasso di mercato secondario per un collaterale in looping è irregolare - ma non è stata la causa diretta dell'exploit. Il vero problema è strutturale.

9/ Questo exploit evidenzia il collegamento mancante tra il design degli Oracle e l'intelligenza del rischio. Ogni feed di dati integrato in un mercato dovrebbe subire lo stesso scrutinio di qualsiasi collaterale: dovrebbe essere testato, monitorato e vincolato da limiti applicabili. Gli Oracle sono sistemi di rischio.

10/ Per chiunque sia interessato a possibili mitigazioni In questo caso, ce ne sono alcune, dalla selezione del feed all'implementazione dello stesso. @aave ha implementato il framework CAPO, che funge da limite superiore per gli oracoli del tasso di cambio per prevenire la manipolazione.