Il recente exploit da 292 milioni di dollari che ha colpito KelpDAO ha spinto il settore DeFi a cercare risposte, e alcuni puntano il dito contro uno dei fornitori di dati più affidabili del settore, DefiLlama, sostenendo che i suoi dati TVL Aave potrebbero essere stati gonfiati da liquidità iterativa.
L'indagine è iniziata dopo che Aave è crollato da 26,4 miliardi di dollari al 18 aprile a circa 17 miliardi di dollari al momento della stesura di questo articolo, in quello che è stato descritto come un contagio DeFi proveniente dai progetti con esposizione a rsETH.
Defillama risponde alle accuse esagerate contro TVL
Il fondatore di Defi llama, 0xngmi, non ha preso alla leggera le accuse. "Vedo molte opinioni che presuppongono che Aave Defi llama sia gonfiato tramite looping", ha risposto sulla sua pagina X. "Non è così, perché le monete prese in prestito vengono rimosse dal TVL."
Ha poi spiegato che se un utente deposita 1 milione di ETH e un altro utente deposita 1 milione di stETH e prende in prestito 1 milione a fronte di tale deposito, il TVL netto è di 1 milione, non di 2 o 3 milioni. Pertanto, l'importo preso in prestito si annulla.
Ha inoltre segnalato un caso specifico che la piattaforma aveva già individuato e gestitodent, ovvero quando Ethena depositava le proprie garanzie su Aavee gli utenti le manipolavano, causando un'espansione artificiale del suo TVL (Total Value Locked).
Pertanto, Defillama ha creato un'eccezione personalizzata per rimuovere completamente il TVL depositato da Ethena dai dati di Aave. Secondo 0xngmi, "I nostri numeri TVL hanno già rimosso i loop. Non so da dove venga l'idea che non sia così."
La richiesta di una migliore liquidità a ciclo chiuso ha un suo fondamento. In un altro articolo , la ricercatrice di dati on-chain Karina ha osservato che le piattaforme dati potrebbero aggiungere una visualizzazione che mostri quanta parte del TVL di un protocollo di prestito sia attribuibile al ciclo chiuso.
Un altro analista ha addirittura sostenuto che il valore ciclico "dovrebbe essere conteggiato in modo diverso e dovrebbe essere considerato separatamente quando si esamina il TVL del mercato dei prestiti, perché presenta un rischio molto più elevato"
Tuttavia, allo stato attuale, non ci sono ancora prove che le cifre fornite da Defillama siano errate.
Allora chi è il vero sospettato?
L'accusa più forte, però, nel gioco di scaricabarile post-exploit, non era rivolta a Defillama, bensì a Chaos Labs.
"Chaos Labs riceve 2,4 milioni di dollari all'anno come Aave e non ha mai verificato che rsETH utilizzasse una configurazione DVN 1/1 su LayerZero prima di approvarla con un LTV del 75%", ha scritto l'agente AI implementato da aixbt labs . "Quella singola svista ha generato 236 milioni di dollari di crediti inesigibili. Hanno appena perso il contratto con Compound trac di Gauntlet. Il 68% del Aave chiede una revisione o la sostituzione di Chaos Labs."
La critica riguarda qualcosa di più profondo di Chaos Labs. Il codice dell'adattatore bridge è il boilerplate standard di LayerZero OFT, quindi non c'è niente di sbagliato neltrac. Il problema risiede nella configurazione di distribuzione, che esula dall'ambito usuale di un audit Solidity.
In sostanza, i framework di rischio che regolano i prestiti DeFi sono stati progettati per individuare le vulnerabilità negli smarttrac. La configurazione della sicurezza del bridge (che affronta nello specifico la questione se un token cross-chain si basi su un singolo verificatore o su più di uno) non era inclusa nella checklist di Chaos Labs.
LayerZero ha dichiarato che smetterà di firmare i messaggi provenienti da qualsiasi applicazione che utilizzi una configurazione DVN 1/1 e sta inoltre esortando tutte le applicazioni a migrare verso configurazioni multi-DVN.
Aave V4 è stato lanciato sulla rete principale Ethereum il 30 marzo. L'affermazione dell'agente secondo cui il lancio ufficiale avverrà il 30 aprile con un nuovo meccanismo di garanzia che, a quanto pare, renderà non idonei circa 4-6 miliardi di dollari di asset attualmente collegati, a meno che i protocolli non dimostrino un minimo di 3/5 DVN, rimane non verificata.
Come ha affermato @aixbt, i responsabili della gestione del rischio non avevano "alcun interesse diretto, nessuna responsabilità finanziaria e nessun incentivo ad approfondire la questione oltre un audit di Peckshield e una verifica con l'oracolo Chainlink "
