Cos’è il rischio di smart contract?

Avanzato28 ott 2026 · 8 min di lettura

Il rischio di smart contract è la probabilità che Lei perda valore — o perda l’accesso utilizzabile a quel valore — perché il comportamento di un programma on-chain, le sue dipendenze, i suoi oracle o la sua autorità di admin / upgrade producono un esito che Lei non intendeva quando ha depositato, approvato o interagito. Il rischio di smart contract non è «la chain ha dimenticato i Suoi coin».

Definizione

Il rischio di smart contract è la probabilità che Lei perda valore — o perda l’accesso utilizzabile a quel valore — perché il comportamento di un programma on-chain, le sue dipendenze, i suoi oracle o la sua autorità di admin / upgrade producono un esito che Lei non intendeva quando ha depositato, approvato o interagito.

In parole semplici:

Il rischio di smart contract non è «la chain ha dimenticato i Suoi coin». È il rischio che codice che Lei ha autorizzato — o codice che può riscrivere le regole dopo che Lei ha depositato — sposti, congeli, misprezzi o dreni valore secondo la propria logica.

La custodia chiede chi può spendere. Il rischio di smart contract chiede cosa i programmi che Lei tocca possono fare, cosa assumono del mondo e chi può cambiare quelle regole in seguito.

In trading

La vera domanda di trading

Per questa esposizione, posso nominare i contratti, le superfici di fiducia (oracle, upgrade, admin) e una forma di perdita che riesco ancora a sostenere se quelle superfici falliscono — oppure sto trattando «auditato / TVL alto / logo familiare» come sostituto della misurazione?

Risponda per deposito e per superficie di approvazione. Torni a rispondere dopo gli upgrade, dopo i cambi di oracle e dopo i salti di size. Un solo slogan per ogni interazione DeFi è la trappola del solo riconoscimento che questa pagina lascia alle spalle.

Due indicatori che le persone collassano in uno solo

	Titoli di «hack» a scala di mercato	Esposizioni di protocollo DeFi
Cosa spesso domina le perdite in dollari	Chiavi, signer, infra di wallet, front-end, compromissione admin	Logica di protocollo e assunti economici
Cosa spesso domina il conteggio degli incidenti	Misto; i bug di codice restano frequenti	Logica, controllo degli accessi, oracle, percorsi contabili
Errore del trader	Trattare ogni storia di perdita come «i contratti sono insicuri, quindi eviti il DeFi»	Trattare ogni badge di audit come «il rischio di codice è chiuso»
Risposta utile	Tenere un indicatore di custodia per venue e chiavi	Tenere un indicatore di contratto / oracle / upgrade per i depositi

Entrambi gli indicatori sono reali. Mischiarli produce l’hedge sbagliato: o Lei sotto-dimensiona ogni protocollo perché i furti di chiavi CeFi hanno riempito le notizie, oppure si fida troppo di un vault perché «la maggior parte del valore rubato quest’anno erano chiavi».

Lettura delimitata dei conteggi recenti di settore: sull’intero mercato, infrastruttura e compromissione delle chiavi spesso concentrano la maggior parte del valore; dentro le perdite dei protocolli DeFi, la logica spesso concentra la maggior parte della massa di perdita. Usi entrambi i fatti. Non ne scelga uno scartando l’altro.

Tassonomia (classi, non una sola bandiera «hackerato»)

Classe	Cosa si rompe	Come appare la perdita
Controllo degli accessi	Funzioni privilegiate invocabili dalla parte sbagliata	Si apre un percorso di mint, pause, upgrade, set-price o drenaggio
Logica di business	Regole intese ≠ regole codificate	Reward sbagliati, matematica del collaterale sbagliata, liquidazione o mint/redeem rotti
Reentrancy / chiamate esterne	Il controllo viene ceduto prima che lo stato sia definitivo	Prelievi ripetuti, reentry tra funzioni, callback di hook
Aritmetica / arrotondamento / share	La matematica a virgola fissa, fee, share o riserva deriva	Fuga silenziosa di valore; gli stati estremi amplificano errori da un wei
Oracle / liquidità sottile	La logica di sicurezza si fida di un prezzo mobile o stale	Prestiti underwater, liquidazioni scorrette, collaterale gonfiato
Amplificazione flashloan	Capitale same-tx spinge un assunto debole fino a romperlo	Il bug radice c’era già; il capitale temporaneo lo ha reso redditizio
Proxy / upgradeability	L’implementazione o il percorso di initializer / admin è debole	Riscrittura della logica, claim non inizializzato, corruzione dello storage
Griefing / DoS	Disponibilità o uscite bloccate senza un «furto» pulito	Prelievi bloccati, liquidazioni inceppate, distribuzioni che fanno revert

Le liste in stile OWASP Top 10 ruotano i ranghi di anno in anno. Controllo degli accessi, logica di business e oracle restano vicino al vertice; i percorsi facilitati da flashloan e le categorie proxy/upgrade sono saliti come superfici pratiche. Tratti la lista come un menu di monitoraggio, non come una cartella del bingo.

Superfici di secondo ordine (dove la size esperta muore davvero)

La reentrancy da manuale non è l’unico indicatore. Questi percorsi di secondo ordine di solito contano di più quando Lei lascia la size da giocattolo:

Composabilità — il Suo vault sta bene finché non valuta le share su un pool peer, un wrapper o un bridge che Lei non ha mai rivisto.
Gap di scope di audit — molti post-mortem di protocolli «auditati» mostrano che il percorso d’attacco stava fuori da ogni scope pubblico di audit, o in una dipendenza / keeper / forwarder che il report non ha mai coperto.
Bytecode non verificato o disallineato — il nome in UI ≠ l’indirizzo sull’explorer ≠ l’implementazione a cui il proxy punta ora.
Upgrade senza finestra di revisione — niente timelock, un solo upgrader EOA, o uno swap silenzioso di implementazione dopo che Lei ha depositato.
Emergency pause come fiducia — una pause può salvare un drenaggio e può anche intrappolare le uscite; chi tiene l’interruttore fa parte del prezzo del rischio.
Drenaggio parziale vs totale — alcuni bug fanno skim sull’arrotondamento; alcuni svuotano il pool; alcuni congelano i fondi senza trasferirli. Dimensioni per la peggiore forma credibile, non per il titolo medio.
Contratti «sicuri» stale — i deploy vecchi vengono rivisitati; l’età non è un alone di sicurezza se gli incentivi restano nell’indirizzo.

Superfici residue sui venue wallet-first

Il trading wallet-first (inclusi venue come edgeX) riduce il rischio di «IOU sul saldo della società» quando è la Sua autorizzazione a muovere i fondi. Il rischio di contratto compare comunque quando:

Lei approva uno spender che può prelevare token in seguito
Lei deposita in un vault, bridge o prodotto strutturato
matching o settlement dipendono da contratti il cui percorso di upgrade o di oracle Lei non ha mappato
un frontend clonato Le chiede di firmare contro un indirizzo diverso da quello che Lei ha verificato

Se la Sua checklist chiede solo «è non-custodial?», Lei è ancora sul vecchio indicatore.

Scene lavorate (giudizio, non slogan)

A — Arrotondamento sotto pressione di flashloan.

La matematica di withdraw di un pool arrotonda dal lato sbagliato in un tick estremo. Il flusso normale sembra a posto. Capitale preso in prestito nella stessa transazione spinge il pool in quello stato, estrae il gap, ripaga il prestito e lascia gli LP in corto. Il flashloan è stato l’amplificatore. Il bug era contabilità.

B — «Hack dell’oracle» che era controllo degli accessi.

Gli aggiornamenti di prezzo dovrebbero viaggiare attraverso un percorso keeper / forwarder. Un forwarder debole lascia che un attaccante raggiunga `setPrices`. Stampano un mark cattivo, aprono e chiudono contro di esso, e se ne vanno. Il brand del feed non era la radice; chi poteva scrivere sul feed sì.

C — Vault auditato, dipendenza fuori scope.

Tre PDF di audit stanno sul sito dei docs. Il drenaggio usa un helper di libreria o un verificatore di bridge che quei report non hanno mai delimitato. «Eravamo auditati» era vero e incompleto. Chieda quale commit, quali file, quali percorsi economici, e cosa è cambiato da allora.

D — Proxy giorno uno vs anno due.

Lei ha dimensionato un deposito quando l’implementazione era congelata e multisig + timelock erano pubblici. Sei mesi dopo atterra un upgrade con una finestra corta e un nuovo ruolo. Stesso indirizzo di proxy; diversa superficie di fiducia. Rivaluti o esca — non erediti la tesi dell’anno scorso.

Monitoraggio (cosa falsificare)

Valuti ogni esposizione materiale di contratto contro fatti che Lei può controllare — non contro i badge.

Monitor	Un pass appare così	Un fail appare così
Mappa degli indirizzi	Lei può nominare proxy vs implementazione vs spender	«Il contratto del sito», non verificato
Mappa dei permessi	Sono noti i ruoli per upgrade, pause, mint, scrittura oracle	Una sola god-key «owner» che Lei non sa descrivere
Percorso di upgrade	Cultura di timelock / multisig / diff pubblicato	Upgrade EOA silenziosi
Design dell’oracle	Aggregato / TWAP / freschezza / limiti di scostamento dove la size li richiede	Spot same-tx da un pool sottile per le liquidazioni
Igiene di audit	Scope, data, hash del commit; bounty ancora attiva	Muro di logo; niente scope; il codice si è mosso dopo il report
Composabilità	Lei sa da quali pool/bridge esterni dipende l’esposizione	Wrapper annidati che Lei non sa nominare
Superficie di allowance	Minimo privilegio; revoca periodica	Unlimited approve per sempre a ogni router
Prove di uscita	Un withdraw piccolo ha funzionato di recente	Solo memoria muscolare del deposito
Postura sugli incidenti	Pause delimitata; monitoraggio; abitudine al post-mortem pubblico	TVL come prova di sicurezza

Default condizionali (parta da qui, poi aggiusti)

Se Lei non può nominare l’indirizzo del contratto e chi può farne l’upgrade → non scali l’esposizione.
Se il pricing critico per la sicurezza legge uno spot same-transaction da un pool sottile → tratti i percorsi di liquidazione / mint / redeem come ostili finché non è dimostrato il contrario.
Se l’unico comfort è «auditato» senza scope né commit → tratti l’audit come marketing, non come indicatore.
Se un upgrade è atterrato dopo il Suo deposito → rivaluti; non assuma continuità.
Se capitale della size di un flashloan può muovere l’oracle o la matematica delle share da cui Lei dipende → dimensioni come se quel capitale arriverà.
Se il trading hot e i depositi di protocollo condividono approvazioni unlimited → separi le superfici nella stessa settimana.
Se la size è salita con forza → rifaccia la mappa anche se la UI non è cambiata.

Mosse di design

Separi le approvazioni del float di trading dai depositi di protocollo idle.
Preferisca indirizzi verificati che Lei incolla da una fonte nota piuttosto che «Connect and hope».
Limiti ogni esposizione di protocollo a una forma di perdita che Lei può sostenere (skim vs svuotare vs congelare).
Provi un withdraw piccolo prima di scalare.
Revochi le allowance unlimited stale secondo un calendario.
Preferisca venue e protocolli che pubblicano indirizzi di contratto, policy di upgrade e scope di audit — e poi esegua comunque i Suoi monitor.
Scriva un ordine breve di stress: quale esposizione esce per prima se scatta un alert di upgrade o di oracle.

Limiti di questo framework

Questa pagina non sostituisce un audit professionale, la verifica formale o l’incident response per i builder. Non prezza ogni quirk di finality di chain, bridge o L2. Non salverà un’esposizione se Lei ignora il phishing e firma uno spender maligno. Gli indicatori vicini — custodia, approvazioni, MEV, rischio di protocollo vs piattaforma vs utente — restano validi. Usi questa tassonomia per smettere di collassare ogni perdita on-chain in una sola parola.

Non confonda con

Rischio di custodia — fallimento di autorità di spesa / controparte-vs-operatore; si somma ai depositi di protocollo, non è lo stesso indicatore.
Rischio di approvazione di token — allowance che può abilitare un prelievo successivo; spesso è la porta verso il rischio di contratto, non l’intero albero dell’exploit.
Rischio di prezzo — il mark può muoversi mentre comportamento del codice e controllo restano intatti.
Rischio di liquidità / slippage — non poter uscire dalla size sul mercato ≠ vault drenato, congelato o misprezzato dalla logica di programma.
MEV / sandwich — ordinamento ed estrazione intorno alla Sua transazione; può toccare il design di oracle/swap, e comunque non è sinonimo di bug di logica.

Pronto per il prossimo passo?

Continua alla registrazione o al trading da questa pagina usando i link ufficiali.

Inizia a fare trading su edgeX

Disclaimer

Questo contenuto ha solo scopo educativo e non costituisce consulenza in materia di investimenti. Il trading di asset digitali e derivati comporta rischi. Assicurati di comprendere i prodotti e valuta la tua situazione prima di fare trading.

Glossario

Cos’è il rischio di smart contract?

Avanzato28 ott 2026 · 8 min di lettura

Definizione

In parole semplici:

La custodia chiede chi può spendere. Il rischio di smart contract chiede cosa i programmi che Lei tocca possono fare, cosa assumono del mondo e chi può cambiare quelle regole in seguito.