Code is law? Quando il codice incontra il diritto vero

C'è una frase che gira nei convegni sulla blockchain come una formula magica: code is law, il codice è legge. La pronunciano con gli occhi lucidi, come se avessero appena scoperto il modo di mandare in pensione noi avvocati. Il ragionamento è seducente: se l'accordo è scritto in righe di software che si eseguono da sole, senza che nessuno possa fermarle, tradirle o reinterpretarle, allora a cosa servono i tribunali? La macchina fa quello che è scritto. Punto.

Ecco, fermiamoci proprio su quel punto. Perché la verità sgradevole è un'altra: il codice non è legge. Il codice è un fatto. E quando un fatto incontra il diritto, il diritto vince — non perché sia più nobile, ma perché è quello che decide chi paga quando le cose vanno storte. E nello smart contract, prima o poi, qualcosa va storto: un dato sbagliato in ingresso, un bug nel software, un attacco che svuota un protocollo. Allora la domanda smette di essere filosofica e diventa volgarmente pratica: chi risponde?

Mettiamo sul tavolo lo strumento più affilato che abbiamo. Si chiama qualificazione giuridica. E si comincia da una parola che inganna tutti.

Lo smart contract non è un contratto (e l'Italia lo ha messo per iscritto)

Il nome è un falso amico. Smart contract contiene la parola "contratto", ma un programma che gira su una blockchain non è, di per sé, un contratto nel senso dell'articolo 1321 del codice civile — quello per cui il contratto è "l'accordo di due o più parti per costituire, regolare o estinguere tra loro un rapporto giuridico patrimoniale". Lo smart contract, nella sua essenza tecnica, è un meccanismo di esecuzione. È la serratura automatica, non il patto di affittare la casa.

L'Italia, va detto, è stata fra i primi Paesi a prendere posizione per legge. L'articolo 8-ter del D.L. 14 dicembre 2018, n. 135, convertito con la Legge 11 febbraio 2019, n. 12, definisce lo smart contract come "un programma per elaboratore che opera su tecnologie basate su registri distribuiti e la cui esecuzione vincola automaticamente due o più parti sulla base di effetti predefiniti dalle stesse" (Normattiva, testo dell'art. 8-ter). Leggetela bene: la norma non dice che lo smart contract è un contratto. Dice che è un programma la cui esecuzione vincola le parti sulla base di effetti che le parti hanno predefinito. L'accordo resta a monte, fuori dal codice; il codice ne è il braccio esecutore.

La dottrina lo aveva già intuito con una distinzione che vale oro: da una parte lo smart legal contract, dove il programma è la veste informatica di un vero accordo giuridico; dall'altra il puro smart code, righe di software che eseguono e basta, rilevanti solo sul piano tecnico (Bellomia, Il contratto intelligente: questioni di diritto civile, Judicium). La conseguenza è netta: il diritto dei contratti — formazione del consenso, vizi, cause di nullità, rimedi — non sparisce perché l'accordo è scritto in Solidity. Resta tutto lì, in agguato.

La forma scritta e il fantasma di AgID

Lo stesso art. 8-ter contiene una promessa rimasta a metà. Stabilisce che gli smart contract "soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall'Agenzia per l'Italia Digitale con linee guida". E qui casca l'asino: a oltre sette anni dall'entrata in vigore, quelle linee guida AgID non sono mai state emanate (Agenda Digitale, Blockchain e validazione temporale degli smart contract). Senza i requisiti tecnici di identificazione, la norma che attribuisce la forma scritta resta sospesa nel vuoto: una equivalenza promessa ma non operativa nel suo presupposto.

Non è un cavillo. La forma scritta, in diritto italiano, non è un vezzo: per certi contratti è richiesta a pena di nullità, per altri è prova. Dire che uno smart contract "vale come scritto" senza avere il processo di identificazione che la legge stessa pretende significa costruire su una fondazione che il legislatore ha disegnato ma non gettato. Lo stesso articolo, va riconosciuto, ha avuto più fortuna su un altro fronte: la memorizzazione di un documento tramite DLT "produce gli effetti giuridici della validazione temporale elettronica" di cui all'art. 41 del Regolamento (UE) n. 910/2014, l'eIDAS — cioè fa data certa opponibile (art. 8-ter, comma 3). Una cosa è la marca temporale; un'altra è la firma del consenso. La prima funziona, la seconda aspetta AgID.

Il consenso si forma prima del codice, e i vizi sopravvivono

Veniamo al cuore civilistico. Se lo smart legal contract è un contratto, allora il consenso si forma secondo le regole di sempre: proposta, accettazione, incontro delle volontà. E se il consenso può formarsi, può anche essere viziato. Errore, dolo, violenza (artt. 1427 e seguenti c.c.) non evaporano perché la clausola è scritta in linguaggio macchina. Anzi: lo smart contract aggrava il problema, perché esegue alla cieca. Un contratto tradizionale viziato si può non eseguire e poi impugnare; uno smart contract viziato si esegue lo stesso, automaticamente, e solo dopo si va dal giudice a chiedere di rimettere le cose a posto.

Qui sta il primo paradosso che l'Avvocato del Diavolo non può tacere. L'immutabilità, vantata come la grande virtù della blockchain, è anche il suo tallone. Una volta che la transazione è confermata sul registro, nessun giudice può ordinare alla catena di tornare indietro: la blockchain è, per costruzione, non modificabile. Quello che un giudice può fare è ordinare alle parti rimedi fuori catena — restituzioni, risarcimenti, pagamenti compensativi (Oaks Legal, Is Code Law?). Tradotto: il diritto di ripensamento del consumatore, la risoluzione per inadempimento, l'annullamento per vizio del consenso non muoiono. Diventano però rimedi a posteriori, che inseguono una macchina che ha già pagato. Non si annulla l'esecuzione: si riequilibra il dopo.

Gli oracoli: il tallone d'Achille che nessuno vuole nominare

Adesso il punto tecnico che fa crollare il castello del code is law. Uno smart contract, da solo, è cieco e sordo verso il mondo. Sa solo quello che è scritto sul suo registro. Ma la stragrande maggioranza degli accordi utili dipende da fatti esterni: il prezzo di un titolo, il tasso di cambio, l'avvenuta consegna di una merce, il verificarsi di un sinistro. Per sapere queste cose lo smart contract ha bisogno di un ponte verso la realtà. Quel ponte si chiama oracolo.

L'oracolo è il punto in cui il sogno dell'automatismo perfetto si schianta contro il vetro. Perché se il dato che entra è sbagliato — per errore, per guasto, per manipolazione — lo smart contract esegue impeccabilmente la cosa sbagliata. È il vecchio garbage in, garbage out, ma con i soldi veri e l'irreversibilità in più. La dottrina lo chiama, senza giri di parole, "the oracle problem": un nodo che intreccia integrità del dato, sicurezza, privacy e responsabilità (Chougule–Cantisani, The oracle problem in smart contracts, MediaLaws, 2024).

E non è teoria. Nel 2024 la manipolazione degli oracoli di prezzo è stata il secondo vettore d'attacco più dannoso nella finanza decentralizzata, con circa 52 milioni di dollari di perdite distribuiti su 37 episodi; il problema è aggravato dal fatto che oltre il 60% dei nuovi protocolli DeFi si affida ancora a oracoli a fonte singola, cioè a un unico punto che, se mente, fa franare tutto (analisi di settore, Smart Contract Oracle Manipulation; dati di mercato da verificare alla fonte primaria). La domanda giuridica diventa allora chirurgica: quando l'oracolo sbaglia, chi risponde verso la parte danneggiata? Il fornitore del dato, lo sviluppatore del contratto, la piattaforma che li ha messi insieme? Il diritto dei contratti e la responsabilità civile hanno qualcosa da dire — solo che il contratto va letto, le parti vanno identificate, e l'automatismo non cancella nessuna di queste due operazioni.

Quando il codice sbaglia: il bug, l'exploit, il caso del DAO

C'è poi l'errore che non viene da fuori ma da dentro: il bug. Lo smart contract fa esattamente quello che è scritto, ma è scritto male. E qui l'immutabilità, di nuovo, da virtù si fa condanna: una volta distribuito sulla catena, il codice difettoso non si corregge — l'errore diventa permanente (ethereum.org, Smart contract security).

Il caso scuola è del 2016, ed è la pietra tombale sopra ogni slogan. The DAO era un fondo di investimento decentralizzato su Ethereum che aveva raccolto circa 150 milioni di dollari in ether. Un attaccante sfruttò una vulnerabilità di reentrancy nel codice — un difetto che permetteva di prelevare fondi ripetutamente prima che il contratto aggiornasse il saldo — drenando oltre 60 milioni di dollari (Chainlink, Reentrancy Attacks and The DAO Hack Explained). Qui il code is law mostrò il suo volto cinico: l'attaccante non aveva "violato" il codice, lo aveva eseguito alla lettera. Aveva fatto ciò che il codice consentiva. Se davvero il codice fosse legge, quei soldi erano legittimamente suoi.

La comunità Ethereum rispose con un hard fork, riscrivendo la storia della catena per restituire i fondi. Cioè: di fronte a un furto da 60 milioni, l'immutabilità sacra fu messa da parte da una decisione umana, sociale, politica. La lezione per chi fa il mio mestiere è limpida. Il code is law regge finché nessuno ci perde abbastanza da chiamare un avvocato. Nel momento in cui la posta è seria, riemerge sempre un soggetto umano che decide chi aveva ragione — un giudice, un'assemblea, una comunità. L'automatismo è una comodità, non una sovranità.

L'Europa ci mette mano: dal Data Act ai principi ELI

Il legislatore europeo ha capito che l'automatismo perfetto è un mito pericoloso e ha cominciato a infilare valvole di sicurezza nel codice. Il pezzo più sorprendente sta nel Data Act, il Regolamento (UE) 2023/2854, applicabile dal 12 settembre 2025. Il suo articolo 36 impone, agli smart contract usati per eseguire accordi di condivisione dati, requisiti essenziali che suonano come una smentita ufficiale del code is law (EUR-Lex, Regolamento (UE) 2023/2854):

Requisito (art. 36 Data Act)	Cosa pretende davvero
Robustezza e controllo degli accessi	Lo smart contract deve essere progettato per evitare errori funzionali e resistere alla manipolazione di terzi
Interruzione e terminazione sicura	Devono esistere meccanismi per terminare o interrompere l'esecuzione — in pratica un freno, un "kill switch"
Archiviazione e continuità dei dati	Tracciabilità e possibilità di conservare i dati delle transazioni e degli accordi

Si fermi un attimo il lettore sul secondo requisito, perché è una bomba concettuale. La legge europea pretende che lo smart contract abbia un bottone per fermarsi. Cioè nega, per via normativa, il dogma dell'esecuzione inarrestabile. Un contratto che deve poter essere interrotto non è più "legge che si applica da sola": è uno strumento sotto controllo umano. Chi vende o impiega questi smart contract deve svolgere una valutazione di conformità e rilasciare una dichiarazione UE di conformità (art. 36, Data Act).

Onestà intellettuale, però — e qui la regola del "da verificare" è d'obbligo: la stessa norma è già contestata. Nel 2025 la Commissione, nel quadro del cosiddetto Digital Omnibus, ha prospettato di eliminare l'art. 36, ritenuto fonte di incertezza e di oneri per gli operatori delle blockchain pubbliche (Goodwin, Navigating the EU Data Act, ottobre 2025). Allo stato, la norma è in vigore e va rispettata; il suo destino, da verificare alla luce dell'iter legislativo.

Sul piano dottrinale, infine, c'è un faro a cui guardare: i Principi ELI su blockchain, smart contract e tutela del consumatore elaborati dall'European Law Institute (van Erp–Hanzl), che cercano di colmare i vuoti di certezza sulla natura e sugli effetti giuridici di blockchain e smart contract con un approccio "funzionalmente equivalente" al diritto esistente e tecnologicamente neutro (ELI, ELI Principles on Blockchain Technology, Smart Contracts and Consumer Protection). Il senso è sempre lo stesso: lo smart contract non crea un mondo a parte dove il diritto non arriva; semmai il diritto deve adattare i suoi strumenti per arrivarci.

Il rapporto con MiCA e il quadro DLT

Una precisazione per non confondere i piani, perché nei numeri precedenti di questa rubrica abbiamo già camminato su questo terreno. MiCA, il Regolamento (UE) 2023/1114 sui cripto-asset, e il DLT Pilot Regime (Reg. UE 2022/858) regolano cosa gira sulla blockchain — i token, gli strumenti finanziari tokenizzati, le infrastrutture di mercato. Lo smart contract è il come: il motore che esegue. MiCA, peraltro, contiene una sua definizione di smart contract e impone requisiti di affidabilità per quelli usati nei servizi su cripto-attività, in linea con la filosofia del Data Act: robustezza, protezione dalla manipolazione, possibilità di interruzione. I due piani — la qualificazione civilistica nazionale e la regolazione di settore europea — convivono e si parlano. Il diritto dei contratti dice se e come il vincolo nasce e si scioglie; la regolazione finanziaria detta i requisiti tecnici di chi quei contratti li costruisce e li vende.

Dove l'avvocato pianta i paletti

Tiriamo le somme con le tre questioni che decideranno le cause prima che nascano.

Primo: il codice esegue, ma non qualifica. Stabilire se uno smart contract sia un vero contratto, quali obbligazioni crei e quali rimedi attivi è un'operazione giuridica, non informatica. La macchina trasferisce valore; la qualificazione resta umana. Chi costruisce sull'automatismo deve sapere che l'automatismo non lo mette al riparo dal codice civile.

Secondo: l'immutabilità è un fatto, non uno scudo. Che la transazione sia irreversibile sul registro non significa che sia inattaccabile in diritto. Vizio del consenso, inadempimento, indebito arricchimento, responsabilità da oracolo o da bug aprono rimedi fuori catena. L'esecuzione non si annulla; il dopo si riequilibra. Chi progetta smart contract per il mercato europeo, oggi, deve anzi prevedere il freno: l'art. 36 del Data Act lo impone (salvo gli sviluppi del Digital Omnibus, da verificare).

Terzo: la responsabilità non sparisce, si nasconde. Quando il codice sbaglia o l'oracolo mente, c'è sempre un soggetto a monte — sviluppatore, fornitore di dati, deployer, piattaforma. Identificarlo è metà del lavoro; l'altra metà è capire a quale titolo risponde, contrattuale o extracontrattuale. La decentralizzazione è ottima per diluire il potere. È pessima, per la vittima, quando serve trovare un responsabile.

Cosa portarsi a casa

Il code is law è uno slogan da palco, e come tutti gli slogan funziona finché non costa nulla. Il giorno in cui costa — un bug che svuota un fondo, un oracolo avvelenato, un consumatore raggirato da una clausola che si è eseguita da sola — riemerge il diritto vero, con le sue categorie vecchie di secoli che si rivelano sorprendentemente capaci di mordere anche il software. L'Italia lo ha scritto nell'art. 8-ter; l'Europa lo ha confermato chiedendo allo smart contract di avere un bottone di spegnimento. Il messaggio, sotto la vernice tecnologica, è antico: nessun automatismo è sovrano. Dietro ogni macchina che esegue c'è sempre qualcuno che, quando le cose vanno storte, deve rispondere.

Non prometto a nessuno che vincerà la causa contro uno smart contract impazzito — la deontologia me lo vieta e l'onestà pure. Quello che posso dire è che la causa si può fare, e che il codice, davanti a un giudice, non è legge: è una prova come le altre. Da leggere, interpretare, e all'occorrenza smontare.

Tutte le affermazioni di questo articolo sono ancorate a fonti verificabili e datate, citate inline. I dati riflettono le informazioni disponibili al 24 giugno 2026 e vanno verificati alla luce degli sviluppi successivi.