Smart contract e Electronic Transactions Act 2010

Leggi l’edizione PDF (2 pagine)

Il codice può essere un contratto?

Uno smart contract è un programma su una blockchain che esegue azioni predeterminate al verificarsi di determinate condizioni. Se esso sia anche un contratto in senso giuridico dipende dalla presenza, nei rapporti tra le parti, degli elementi ordinari di proposta, accettazione, consideration e intenzione di creare rapporti giuridici. Il diritto di Singapore non prevede alcuna regola secondo cui un contratto debba essere redatto in linguaggio naturale. L'Electronic Transactions Act 2010 dispone che alle informazioni non può essere negata efficacia giuridica per il solo fatto che siano in forma elettronica e che i contratti possono essere conclusi mediante comunicazioni elettroniche. A un contratto concluso tramite l'interazione tra un sistema automatizzato di messaggi e una persona fisica, o tra sistemi automatizzati di messaggi, non può essere negata validità per il solo fatto che nessuna persona fisica abbia verificato le singole azioni.¹

La legge fornisce altri tre strumenti. La section 13 imputa una comunicazione elettronica alla persona che l'ha inviata o per conto della quale è stata inviata, il che consente di imputare al titolare della chiave una transazione firmata con una chiave privata.² La section 16 consente alla persona fisica che commette un errore di immissione nell'interazione con un sistema automatizzato di messaggi di revocare la parte errata, a condizione che il sistema non le abbia offerto la possibilità di correggere l'errore e che essa lo comunichi tempestivamente senza averne tratto beneficio.³ La section 16 è una disposizione di tutela del consumatore di portata ristretta e non aiuta il trader che inserisce un ordine a un prezzo errato su un exchange che offriva una schermata di conferma. Le modifiche del 2021 hanno aggiunto la Part 2A sui documenti trasferibili elettronici, che attua la UNCITRAL Model Law on Electronic Transferable Records e consente a polizze di carico, pagherò e strumenti analoghi di esistere in forma elettronica quando un metodo affidabile assicura il controllo esclusivo.⁴ La First Schedule continua a escludere dalle disposizioni di riconoscimento della legge i testamenti, la costituzione di determinati trust e procure, nonché i contratti di disposizione di beni immobili, aspetto rilevante per le questioni successorie del Capitolo VII.⁵

Codice, volontà e testo prevalente

Tre problemi si ripresentano costantemente. Il primo riguarda la volontà. Molte interazioni on-chain, come lo scambio di token su un automated market maker, non comportano alcuna controparte identificata né alcuna comunicazione oltre alla transazione stessa. Se sorga un contratto tra l'utente e i fornitori di liquidità, tra l'utente e l'entità che governa il protocollo, o con nessuno, è una questione a cui i tribunali di Singapore non hanno dato risposta. L'analisi della finanza decentralizzata svolta dal Consiglio federale svizzero, esaminata nella Parte D, Capitolo V e nella Parte E, Capitolo IX, conclude che in molti casi non esiste una controparte contrattuale, sicché all'utente, se qualcosa va storto, restano soltanto azioni di arricchimento senza causa o di responsabilità extracontrattuale. A mio avviso un tribunale di Singapore giungerebbe alla stessa conclusione sulla base degli stessi fatti.

Il secondo problema è il rapporto tra il codice e le condizioni in linguaggio naturale. Quando una vendita di token è documentata da un contratto di acquisto ed eseguita da uno smart contract, i due possono divergere: il contratto di acquisto può promettere un piano di vesting che lo smart contract non implementa, oppure lo smart contract può contenere una funzione che consente all'emittente di coniare ulteriori token, vietata dal contratto di acquisto. La soluzione redazionale ragionevole è una clausola di gerarchia che stabilisca quale testo prevalga. In sua assenza, un tribunale interpreterà il contratto di acquisto e tratterà il codice come modalità di esecuzione, cosicché una divergenza costituisce un inadempimento della parte responsabile del codice. Il terzo problema sono i difetti del codice. Un bug che consente a un terzo di svuotare un pool è un evento non voluto dalle parti, e se la perdita gravi sull'utente, sullo sviluppatore o sull'entità di governo dipende dal contratto, ove esista, e dalla responsabilità extracontrattuale, ove manchi (Capitolo VI).

Note

1. Electronic Transactions Act 2010, ss 6 (riconoscimento giuridico dei documenti elettronici), 11 (conclusione e validità dei contratti) e 15 (uso di sistemi automatizzati di messaggi per la conclusione dei contratti). La section 2(1) definisce il sistema automatizzato di messaggi come un programma o un mezzo automatizzato utilizzato per avviare un'azione o rispondere a messaggi di dati senza verifica da parte di una persona fisica. ↩
2. Electronic Transactions Act 2010, s 13 (imputazione delle comunicazioni elettroniche). ↩
3. Electronic Transactions Act 2010, s 16 (errore nelle comunicazioni elettroniche), che attua l'art 14 della UN Convention on the Use of Electronic Communications in International Contracts 2005. ↩
4. Electronic Transactions (Amendment) Act 2021, che ha inserito la Part 2A (electronic transferable records) nell'Electronic Transactions Act 2010 con effetto dal 19 marzo 2021. ↩
5. Electronic Transactions Act 2010, s 4 e First Schedule (materie escluse). ↩

Solo a scopo informativo generale. Il presente articolo non costituisce consulenza legale o fiscale, non sostituisce la consulenza sul singolo caso e non instaura alcun rapporto tra avvocato e cliente. Riflette la situazione giuridica aggiornata a novembre 2026.