Il rischio di protocollo DeFi è la possibilità che una posizione subisca una perdita, un blocco o un risultato inatteso per il guasto di uno dei componenti da cui dipende. Il codice dello smart contract è soltanto uno di questi componenti: contano anche governance, dati esterni, asset, liquidità, rete e servizi operativi.
In parole semplici — Una posizione DeFi è una catena. Anche se il contratto principale funziona come previsto, può fallire un oracle, perdere il peg un collateral, bloccarsi una rete o intervenire una chiave amministrativa.
Dal codice al sistema completo
Il rischio smart contract riguarda codice, configurazione, accessi, proxy e upgrade. Il rischio di protocollo osserva l'insieme che presta il servizio finanziario. Comprende le regole economiche del meccanismo, le parti che possono cambiarle e le dipendenze necessarie perché una transazione venga valutata, eseguita e infine chiusa.
Un audit del contratto principale può essere corretto entro il proprio scope e non coprire il frontend, un oracle, un bridge, il token usato come collateral o un protocollo esterno integrato. Anche “non-custodial” e “DAO” non eliminano automaticamente privilegi: multisig, timelock, comitati di emergenza e concentrazione del voto definiscono chi può intervenire e con quali tempi.
Le dipendenze da ricostruire
La rete di base fornisce consenso, finalità e capacità di esecuzione. Congestione, outage o riorganizzazioni possono ritardare operazioni e liquidazioni. Gli asset portano rischi propri: una stablecoin può perdere il peg, un token può cambiare liquidità e un bridge può introdurre un'altra catena di controllo.
Gli oracle trasformano dati esterni in input leggibili dal contratto. Prezzi obsoleti, manipolati o non disponibili possono alterare collateral e liquidazioni. Keeper, sequencer, frontend, indicizzatori e RPC non sempre custodiscono fondi, ma possono influire sulla possibilità pratica di osservare o inviare un'operazione.
Restano infine le regole economiche: fattori di collateral, soglie, incentivi dei liquidatori, cap, curve di tasso e disponibilità delle riserve. Il loro funzionamento dipende dal comportamento degli utenti e dalla liquidità reale, non soltanto dall'assenza di bug.
Come un guasto si propaga
Immagina un protocollo di prestito che riceva un prezzo troppo alto per un collateral. Le posizioni possono sembrare più solide di quanto siano; le liquidazioni partono tardi e, quando il prezzo viene corretto, la liquidità disponibile può non assorbire le vendite. Il risultato può diventare debito non coperto e ridurre la capacità di prelievo degli altri utenti.
La causa iniziale è il dato, ma la perdita finale dipende dalla combinazione di oracle, parametri, incentivi, liquidità e procedure di emergenza. Lo stesso schema vale per un depeg, un bridge o la congestione della rete: il rischio è nel percorso di trasmissione, non in un'etichetta isolata.
Controlli osservabili prima dell'uso
Identifica rete, indirizzi e versione effettivamente distribuita. Verifica chi controlla proxy, pause, parametri e treasury; come sono composti multisig, timelock e voto; quali contratti e commit coprono gli audit e quali problemi sono rimasti esclusi.
Mappa poi oracle, bridge, stablecoin, token ricevuta, protocolli integrati e servizi fuori catena. Per prestito e derivati servono anche collateral ammessi, cap, soglie, liquidatori, riserve o fondi di sicurezza e condizioni in cui i prelievi possono rallentare o fermarsi. Storico degli incidenti, bug bounty, monitoraggio e procedure pubbliche di risposta aggiungono evidenza, senza produrre una garanzia.
Un numero non riassume il rischio
Una TVL elevata indica valore conteggiato secondo una metodologia, non sicurezza. Età del protocollo, numero di audit e ampiezza della community sono informazioni utili, ma non diventano probabilità di perdita. Il sistema cambia con upgrade, nuovi collateral, governance e integrazioni; una verifica è datata e deve dichiarare il proprio perimetro.
Fonti
- Financial Stability Board — The Financial Stability Risks of Decentralised Finance — pp. 16 e 33: tratta leva, liquidità, interconnessioni e canali con cui le vulnerabilità DeFi possono amplificarsi.
- BIS Financial Stability Institute — Crypto, tokens and DeFi: navigating the regulatory landscape — pp. 32–33: esamina il ruolo di governance, oracle, admin key e infrastruttura nel funzionamento dei protocolli.
- ESMA — Decentralised Finance in the EU: Developments and risks — pp. 7–9: tratta rischio del codice, design economico, governance, liquidità e trasmissione delle perdite.
- IOSCO — Policy Recommendations for Decentralized Finance (DeFi) — raccomandazione 5, pp. 32–36: richiede una lettura complessiva di blockchain, contratti, governance, oracle, bridge e dipendenze.
Collegamenti
Rischio smart contract · Oracle blockchain · Bridge blockchain · Stablecoin · TVL · Finanza decentralizzata (DeFi)