Nel marzo 2026 un malfunzionamento dell’ecosistema di oracoli di Aave legato all’oracolo Aave su wstETH ha causato liquidazioni per oltre 21,7 milioni di dollari, poi interamente compensate.
Il meccanismo che ha generato le liquidazioni
Il 10 marzo, a causa di un vincolo on-chain sul risk agent di Wrapped stETH (wstETH), utenti di Aave hanno subito circa 21,7 milioni di dollari di liquidazioni. In totale sono stati colpiti 34 account.
Il protocollo ha valutato wstETH circa 2,85% in meno del suo valore reale di mercato. Di conseguenza, posizioni sane sono apparse sottocollateralizzate e sono state liquidate, pur restando solide ai prezzi effettivi.
Le liquidazioni hanno coinvolto 10.938 wstETH su 34 conti, generando circa 512 ETH di bonus per i liquidatori prima che il problema fosse individuato e corretto. Tuttavia, il protocollo non ha registrato bad debt e ha poi compensato gli utenti interessati.
Come funziona il sistema CAPO e dove è avvenuto l’errore
L’incidente ha origine nel sistema CAPO (Correlated Asset Price Oracle) di Aave, progettato per mitigare manipolazioni di prezzo su asset con valori correlati. CAPO recupera il rapporto wstETH/stETH da Lido, applica un tetto protettivo tramite WstETHPriceCapAdapter e lo moltiplica per il prezzo di ETH per la valutazione in dollari.
Alle 12:47 UTC del 10 marzo, il motore Edge Risk di Chaos Labs ha suggerito di impostare il CAPO max price a 1,1933947 wstETH/ETH, mentre il rapporto di mercato era 1,2285. BGD, tramite AgentHub, ha eseguito questa modifica un blocco dopo con Oracle Automation, senza finestra di revisione tra raccomandazione e implementazione.
Questa disallineamento del 2,85% ha portato il protocollo a sottovalutare il collaterale in wstETH. Inoltre, gli utenti che avevano wstETH a garanzia contro debito in WETH sono stati liquidati pur mantenendo posizioni corrette rispetto ai prezzi reali di mercato.
Cause tecniche dell’errore nel CAPO
La causa tecnica è un disallineamento tra i parametri snapshotRatio e snapshotTimestamp all’interno di CAPO. Il Risk Agent off-chain di Chaos Labs ha calcolato un rapporto target di circa 1,2282 basato su una finestra di 7 giorni.
Tuttavia, on-chain il valore snapshotRatio poteva aumentare solo del 3% ogni 3 giorni, secondo i meccanismi protettivi di CAPO. Il valore precedente di circa 1,1572 poteva quindi salire in un singolo aggiornamento solo fino a circa 1,1919.
Lo snapshotTimestamp è stato però impostato come se il valore di ancoraggio fosse vecchio di 7 giorni, corrispondente a uno snapshotRatio di 1,2282. Questo disallineamento critico ha portato CAPO a calcolare un tasso massimo di circa 1,1939, cioè circa il 2,85% sotto il tasso di mercato di 1,2285.
Detto ciò, questo è stato il primo aggiornamento automatizzato inserito on-chain dal CAPO Risk Agent di Chaos Labs dalla sua attivazione. Ciò rende la misconfigurazione ancora più rilevante, trattandosi dell’esordio operativo di questa automazione.
Catena di esecuzione automatica e ruolo dell’oracolo Aave
Edge Risk è il motore di rischio proprietario off-chain di Chaos Labs, che invia le modifiche suggerite attraverso un indirizzo dedicato. AgentHub, sviluppato da BGD, riceve questi aggiornamenti e li applica usando Oracle Automation.
Nel caso specifico, il cambio di parametro errato ha attraversato l’intera infrastruttura automatizzata di gestione del rischio di Chaos Labs, fino all’esecuzione sul protocollo, in modo completamente trustless ma privo di controllo umano immediato.
La prima transazione, raccomandata da Edge Risk, ha proposto di impostare il cap a 1,191926 wstETH/ETH tramite la transazione 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. La seconda, eseguita da AgentHub un blocco dopo, ha applicato il cambiamento via Oracle Automation con la transazione 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.
Confronto con l’andamento delle liquidazioni
Le liquidazioni giornaliere nel mese di febbraio erano rimaste contenute, raramente oltre 5 milioni di dollari, grazie a condizioni di mercato stabili. Il picco del 10 marzo a 21,6 milioni rappresenta quindi un evento isolato, circa 4 volte superiore ai livelli tipici.
Dopo quel picco, i volumi di liquidazione sono tornati rapidamente alla norma. Questo ritorno alla base indica che l’episodio è stato legato esclusivamente alla misconfigurazione dell’oracolo, non a insolvenza del protocollo o a uno stress sistemico.
Rilevazione dell’anomalia e risposta del protocollo
La misconfigurazione è stata individuata entro pochi minuti, consentendo al team Aave di intervenire rapidamente. I risk provider hanno ridotto i borrow cap di wstETH a 1 unità sia su Aave Core sia su Prime, bloccando nuova esposizione durante la fase di correzione.
Attraverso un intervento manuale del Risk Steward, il team ha riallineato il parametro snapshotRatio con lo snapshotTimestamp corrente, riportando l’oracolo al valore corretto. Inoltre, sono state approvate modifiche puntuali sui limiti di prestito per limitare ulteriori rischi.
La correzione dell’oracolo è stata applicata tramite la transazione 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d. La riduzione del Borrow Cap, con impostazione del cap di wstETH a 1 wstETH, è stata eseguita con la transazione 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.
Nel complesso, il protocollo non ha generato bad debt e un’analisi dettagliata post-mortem è stata pubblicata sui forum di governance di Aave, a beneficio della comunità.
Compensazione degli utenti colpiti
Per compensare gli utenti interessati, Aave ha recuperato 141,5 ETH in bonus di liquidazione tramite rimborsi BuilderNet. Il resto della compensazione è stato coperto dalla tesoreria della DAO, con un tetto massimo pari a 358 ETH.
Il piano di compensazione è stato implementato tramite AIP diretto, garantendo un ristoro integrale agli utenti colpiti, nonostante la natura tecnica dell’errore. Inoltre, questo rappresenta uno dei primi casi in cui un protocollo DeFi ha offerto una compensazione completa per liquidazioni originate da un fallimento infrastrutturale.
Contesto di mercato e dinamica cross-chain
Nel periodo febbraio-marzo, i dati sui depositi cross-chain indicano una crescita significativa dell’utenza. Il 10 febbraio, la rete Avalanche ha registrato 38.445 utenti depositanti, mentre il 6 marzo Base ha contato 31.763 depositanti, solo quattro giorni prima dell’evento di liquidazione.
Questi picchi mostrano un aumento dell’engagement, con la crescita di Base che avviene in stretta prossimità temporale all’incidente. Tuttavia, i depositi e i prestiti complessivi di Aave sono rimasti stabili nelle prime settimane del 2026, indicando una tenuta dell’architettura di base.
Ciò conferma che le liquidazioni sono derivate dall’errore parametrico dell’oracolo e non da un deterioramento dei collaterali o da condizioni di mercato avverse. In contrasto con altre crisi DeFi, qui non si sono osservate fughe di liquidità prolungate o perdite strutturali.
Lezioni di governance e rischi dell’automazione
L’episodio del 10 marzo mette in luce i compromessi dei sistemi di gestione del rischio completamente automatizzati. Edge Risk ha suggerito un cap sotto i prezzi di mercato, AgentHub lo ha eseguito un blocco dopo e, nel giro di pochi minuti, sono scattate le liquidazioni.
Aave ha reagito con individuazione rapida del problema, azioni correttive decise e compensazione tramite fondi della tesoreria DAO. Tuttavia, l’evento evidenzia lacune nei processi di validazione delle modifiche ai parametri quando l’esecuzione è affidata a catene automatizzate.
La natura proprietaria della metodologia di calcolo di Edge Risk limita la possibilità di revisione indipendente e concentra il controllo operativo presso i fornitori di servizio. Inoltre, questo solleva interrogativi di governance su chi, in ultima istanza, debba poter bloccare o revisionare proposte di aggiornamento critiche prima che vengano applicate on-chain.
Per il futuro, l’incidente dimostra la necessità di test pre-esecuzione più robusti, maggiore trasparenza nelle logiche di calcolo del rischio e meccanismi di revisione multilivello. Solo così si possono evitare che errori tecnici nei sistemi di oracolo o di automazione si traducano in perdite per gli utenti.