Valutare il rischio DeFi

Prima che un fondo, una tesoreria, un custode o una banca interagisca con un protocollo DeFi, qualcuno deve rispondere a una domanda semplice: come potremmo perdere denaro qui e in quale misura? Questa lezione trasforma i meccanismi delle quattro lezioni precedenti in una valutazione strutturata, usando incidenti reali per mostrare come si manifesta ciascun rischio.

Rischio degli smart contract e cosa rivelano davvero gli audit

Il rischio più diretto è un bug nel codice. Un audit è una revisione, limitata nel tempo, di una specifica versione del codice (identificata da un hash di commit), condotta da una società esterna e conclusa con un rapporto che elenca i rilievi per gravità e indica se sono stati risolti. È una prova utile, non una garanzia. Gli audit non rilevano bug sottili di natura aritmetica e d’interazione, non coprono il codice distribuito dopo la revisione e raramente esaminano il comportamento del protocollo quando è combinato con altri.

Due incidenti del 2025 dimostrano il punto:

• Cetus (Sui, 22 maggio 2025): un aggressore ha sfruttato un controllo di overflow difettoso in una libreria matematica usata dal DEX per coniare enormi posizioni di liquidità in cambio di pochissimi token, sottraendo circa 223 milioni di dollari. I validatori di Sui hanno poi bloccato circa 162 milioni di dollari dei fondi rubati on-chain, limitando le perdite ma dimostrando anche che i validatori di una rete presumibilmente decentralizzata potevano coordinarsi per congelare gli asset.
• Balancer V2 (3 novembre 2025): un errore di arrotondamento nella logica di scalatura dei suoi pool stabili componibili, combinato con swap raggruppati, ha permesso a un aggressore di sottrarre circa 128 milioni di dollari su diverse blockchain, sfruttando codice sottoposto più volte ad audit e operativo da anni.

Una prova più solida deriva dalla combinazione di diversi elementi: più audit indipendenti del codice distribuito, verifica formale delle invarianti critiche, un bug bounty significativo, tempo trascorso in produzione con un valore considerevole a rischio, monitoraggio in tempo reale e la possibilità di mettere in pausa il protocollo in caso di emergenza, che è essa stessa un potere amministrativo da valutare.

Manipolazione degli oracoli e del mercato

Un aggressore in grado di alterare il prezzo letto da un protocollo può prendere in prestito fondi usando collaterale sopravvalutato o innescare liquidazioni ingiuste. Le difese sono note: usare solo prezzi provenienti da mercati profondi, aggregare i dati di più fonti, calcolare medie ponderate nel tempo, fissare limiti alle variazioni di prezzo per ogni aggiornamento e stabilire limiti di offerta per gli asset con liquidità ridotta. La revisione dovrebbe identificare ogni oracolo usato dal protocollo, il mercato da cui ciascuno ricava i dati e cosa succede se smette di aggiornarsi. Il caso di Mango Markets, trattato nella lezione Prestiti, indebitamento e liquidazioni, è l’esempio di riferimento.

Il rischio di progettazione economica è più ampio: il protocollo funziona esattamente come programmato, ma gli incentivi non funzionano. Tra gli esempi vi sono token di ricompensa che sostengono i rendimenti solo finché arriva nuovo capitale, collaterale il cui valore dipende dal protocollo stesso (riflessività), disallineamenti tra la liquidità immediata promessa ai depositanti e gli asset illiquidi sottostanti e leva ricorsiva che trasforma una piccola variazione di prezzo in una cascata di liquidazioni. Il collasso della stablecoin algoritmica UST nel 2022, trattato nella lezione Le stablecoin nell’infrastruttura dei mercati, è l’esempio più grande.

Governance, chiavi amministrative e aggiornabilità

La maggior parte dei protocolli non è immutabile. Usa contratti proxy che consentono a un amministratore di sostituire il codice dietro un indirizzo fisso e dispone di funzioni privilegiate per aggiungere asset, modificare parametri, impostare oracoli o mettere in pausa il protocollo. Chiunque detenga questi poteri può, nel peggiore dei casi, portarsi via tutto. La valutazione dovrebbe stabilire:

• Quali funzioni sono privilegiate e chi può invocarle: una singola chiave, una multisig (con quale soglia e quali firmatari) o la governance dei token.
• Se le modifiche passano attraverso un timelock, un ritardo obbligatorio che dà agli utenti il tempo di venire a conoscenza di una modifica e uscire prima che entri in vigore.
• Se i poteri di emergenza (come quelli di un consiglio di sicurezza) aggirano il timelock e quanto siano limitati in modo rigoroso.

L’incidente di Drift del 1° aprile 2026 su Solana mostra come questi controlli possano venire meno tutti insieme. Nel corso di diverse settimane, gli aggressori hanno usato tecniche di ingegneria sociale per indurre membri del consiglio di sicurezza di Drift a firmare in anticipo transazioni, sfruttando una funzionalità di Solana (i nonce durevoli) che consente di eseguire in seguito transazioni firmate. Alcuni giorni prima dell’attacco, il consiglio era passato a una multisig 2 su 5 e aveva rimosso il timelock. Le transazioni firmate in anticipo aggiungevano come collaterale approvato un token senza valore creato dagli aggressori e aumentavano i limiti di prelievo; gli aggressori lo hanno depositato a un prezzo artificiale e nel giro di pochi minuti hanno prelevato circa 285 milioni di dollari. Società di analisi blockchain come TRM Labs ed Elliptic hanno valutato che i responsabili fossero probabilmente hacker nordcoreani. Non è stato coinvolto alcun bug nel codice. I controlli di governance e di firma trattati nelle lezioni Livelli di wallet, policy delle transazioni e flussi di firma e Attacchi alla governance e modalità di malfunzionamento si applicano direttamente.

Rischio dei bridge

I bridge concentrano il valore dietro un singolo passaggio di verifica, come spiegato nella lezione Elementi fondamentali della DeFi, e i loro malfunzionamenti dominano l’elenco delle perdite maggiori.

Le lezioni sono coerenti: contare i verificatori e i firmatari indipendenti, controllare che le loro chiavi siano davvero separate (le cinque chiavi di Ronin erano in mano a sole due organizzazioni), verificare che le autorizzazioni vengano revocate quando non sono più necessarie e considerare ogni token trasferito tramite bridge come soggetto al rischio del bridge oltre che a quello dell’asset.

Esposizione a sanzioni e rischi di conformità

I pool DeFi sono aperti a chiunque, comprese le parti sanzionate. Gli investigatori hanno collegato gruppi nordcoreani agli attacchi a Ronin, Drift e Kelp DAO e i fondi rubati spesso transitano attraverso pool DEX, bridge e mixer. Per una società regolamentata, ciò crea esposizioni assenti su una piattaforma sottoposta a verifica:

• Ricevere fondi riconducibili a un indirizzo presente nell’elenco delle persone specificamente designate (SDN) dell’OFAC o a proventi noti di exploit.
• Fornire liquidità a un pool usato per riciclare asset rubati o detenere token che un protocollo congela successivamente.
• Usare un’interfaccia front-end o un protocollo soggetti a sanzioni o provvedimenti esecutivi; il caso delle sanzioni contro Tornado Cash è trattato nella lezione Integrità del mercato, sanzioni e misure di contrasto.

I controlli comprendono lo screening tramite analisi blockchain delle controparti e dei pool prima e dopo ogni interazione, elenchi di indirizzi wallet consentiti, l’accettazione documentata del rischio per ciascun protocollo e i processi previsti dalla Travel Rule descritti nella lezione Standard FATF e Travel Rule quando i trasferimenti coinvolgono fornitori di servizi di asset virtuali.

Un quadro di valutazione

Un modo pratico per confrontare i protocolli consiste nell’assegnare a ogni categoria di rischio un punteggio da 1 (solido) a 5 (debole), ponderare le categorie e fissare limiti di esposizione in base al risultato. Una struttura tipica:

I punteggi ponderati dovrebbero essere combinati con limiti inderogabili che nessun punteggio può superare (per esempio, non usare mai un protocollo la cui chiave amministrativa sia un singolo account esterno di proprietà, o i cui aggiornamenti non prevedano un timelock), con limiti di concentrazione per protocollo e per blockchain e con soglie di monitoraggio che impongano una revisione: una proposta di governance per modificare i poteri amministrativi, un deflusso improvviso di TVL, il depeg di un token usato come collaterale o un exploit in un protocollo da cui si dipende. Un punteggio è un’istantanea: il rischio DeFi cambia a ogni aggiornamento e voto.

Focus sull’esame: cosa copre un audit e perché anche il codice sottoposto ad audit può comunque essere sfruttato (Cetus, maggio 2025; Balancer V2, novembre 2025); le difese contro la manipolazione degli oracoli e il rischio di progettazione economica; proxy, chiavi amministrative, soglie multisig e timelock, e come l’attacco a Drift (aprile 2026) abbia combinato ingegneria sociale, transazioni firmate in anticipo e rimozione del timelock; le cause principali degli exploit dei bridge Ronin, Wormhole e Kelp DAO; l’esposizione a sanzioni derivante dall’interazione con pool aperti; e come costruire un quadro di valutazione ponderato con limiti inderogabili e soglie di monitoraggio.