1
‘Smart Contracts: the latest challenge for Contract law’
Master’s Thesis European Private Law European Contract Law University of Amsterdam Supervisor: C. Leone Final version: 26.07.2019 Author: Umberto Verri, 12297682
2
Abstract: This thesis examines the regulatory issues arising from placing (blockchain-based) Smart Contracts into the realm of legal contract. The term ‘Smart Contract’ refers to programmes consisting in protocols within which a set of obligations can be defined and performed. Due to their characteristics, Smart Contracts can sometimes be deemed as legal contracts. This nevertheless leads to several problems in terms of compatibility between the technologic functioning of Smart Contracts and the requirements posed by (contract) law. After having discussed why Smart Contracts can be sometimes deemed as legal contracts, the thesis will focus in particular on the formal requirements provided for by contract law and the way law could solve the legal issues arising from the relationship between Smart Contracts and the abovementioned requirements.
1. Introduction
The word “contract” never had, in different times and across different countries, a single meaning. The meaning of contract varies depending not only on the definition given by the legislator, but it changes also according to the functions that the definition of contract is aimed to fulfil. Private law (and Contract law being a part of it) in Europe in the last two millennia has developed a sort of self-adaptability to the forms and characteristics of any particular society. In particular Private law, along with changing according to the aims that different legislators intended to provide it with1, has indeed changed following the expansion of commerce in terms of width and complexity, expansion often following and allowed by technological advances.
In ancient Rome for instance, different types of contracts were introduced to satisfy the needs of a complex reality and the demands of a growing commercial power 2. The commercial expansion, allowed by means of transport’s developments, called for new legal solutions as well, as for example the birth of a medieval ‘lex merchatoria’ or the evolution of chartered companies into listed companies.
As one can notice, contract law has been subject both to top-down influences (i.e. States’ purposes) and to bottom-up ones, namely arising from people’ necessities linked to the developments of technologies mainly conceived as commercial means. Nevertheless, what has indeed changed
1 In the post-revolutionary and Napoleonic France, Contract law (as well as Private law in general) became a political
means in the hand of a State where “tout devient droit public”. Jean-Étienne-Marie Portalis, Discours préliminaire du
premier projet de Code civil, page 12, 1801.
2 A particularly relevant role in the development of Roman commerce has been played by the “locatio conductio”. See Roberto Fiori, Types and Rules of Carriage-by-Sea Contracts in Roman Law, Rivista del Diritto della Navigazione, Vol. XXXIX, Aracne Editrice, 2010.
3
starting from the 20th century is that not only phenomena arising from technology’s development were worthy of regulation, but the technology itself became subject to the legal interpretation and regulation.
If it is true, on one hand, that the era we are living is undoubtedly marked by an acceleration in technologies’ evolution that influences our everyday-life, it is equally true that legislators are often refractory in reaching the same velocity when trying to understand the phenomena and accordingly provide coherent norms, not infrequently for sound reasons. Firstly, law-makers are generally neither keen on technologies nor skilled in them, it is therefore rather time-costly putting efforts in studying them. Secondly and most importantly, technologies usually have an incubation-time only at the very end of which one can deem if the technology itself is socially relevant and therefore worthy of regulation.
A technology that currently seems to be in the limelight is certainly the “blockchain”, an extremely complex technology that can briefly be defined as a “growing list of records, called blocks, which
are linked using cryptography”3. Blockchain is, despite common perception, a relatively old technology: indeed, it has been originally conceived back in 1991, implemented and taken to the next level in 2008 when it served as a basis for the creation of the first cryptocurrency called “Bitcoin”, grabbing this way the headlines. As displayed, this technology has already come through most of its incubation period and, whereas not all its uses are deemed to survive4, it is quite sure that the underlying technology will soon be part of our everyday-life5 6. European Union and its legislator, who have always been among the most technology-sensitive especially when some impacts were expected on consumers 7, not only decided to uphold blockchain technologies and be part of its implementation in the context of the “digital single market” 8, but also started an interpretation process aimed to ascertain if the different types of that technology can fit the legal categories provided by EU legislation, starting in particular from the relationship between “crypto
3 Narayanan A., Bonneau J., Felten E., Miller A., Goldfeder S., Bitcoin and cryptocurrency technologies: a
comprehensive introduction (2016). Princeton University Press.
4https://www.cnbc.com/2018/07/02/over-800-cryptocurrencies-are-now-dead-as-bitcoin-feels-pressure.html
5 Peters G., Panayi E., Understanding Modern Banking Ledgers through Blockchain Technologies: Future of
Transaction Processing and Smart Contracts on the Internet of Money, In: Tasca P., Aste T., Pelizzon L., Perony N.
(eds) Banking Beyond Banks and Money. New Economic Windows. Springer, Cham (2016);
6https://www.visualcapitalist.com/blockchain-powering-future/;
7 Notably, EU started to address what it is called “information society” already in 1984 with its first ESPRIT
Programme (http://europa.eu/rapid/press-release_IP-85-409_en.htm). The analysis and regulation of information society is also at the basis of the Directive 2000/31 EC on electronic commerce.
8 For a hint of EU action plan on Blockchain technology see
4
assets”, i.e. assets whose performance is based on blockchain technology, and EU categories provided for by legislation on financial markets9.
The subsuming process brought forth by EU authorities clearly showed that it is itself hindered by three main factors10:
1. The lack of technical skills by the both the legislators and the regulatory authorities;
2. The absence of a consistent interpretation among Member States’ authorities on current EU legislation;
3. The absence of an EU normative means on the specific issues arising from blockchain technology.
These factors have an impact also on the analysis of another relevant and highly used system based on blockchain technology: “Smart Contracts”. The “Smart Contract” (SC) lacks of a shared definition: according to the most recent scholarship, a Smart Contract can be defined as a “computerized agreement based on an algorithm which automatically performs the terms of the
contract”11 or as a number of “pieces of code that generate transactions if the conditions encoded in
them are met” 12, but the absence of consistency explains much about the complexity of the topic.
While the legal scholarship, concerning the various forms of blockchain technology, has been mainly focussing on cryptocurrencies and their regulatory challenges, recently the legal scholarship’s interest started to be triggered by the comparability of some of Smart Contract’s features to the “legal” meaning of contract, trying this way to ascertain whether the term “Smart Contract” is just a misnomer13. The obvious main question that scholars have identified14 is whether Smart Contracts can be subsumed in the notion of contract, either as provided for by national
9 The European Securities and Markets Authority (ESMA) recently released a legal advice on cryptoassets which was
based on a survey of National Competent Authorities (NCAs) to determine the approach taken by each authority to those assets. ESMA found that, even though the majority of NCAs categorised some types of cryptoassets as securities according to the Markets in Financial Instruments Directive (MiFID), there is no consistency neither in the interpretation of the assets’ nature nor in the subsuming process. This is due to the different approaches taken by the NCAs in the implementation of MiFID, including the interpretation of the term “financial instrument”, and of course due to the understanding of the technology. In ESMA’s view those issues would require Level 1 measures (Directives) “which could be complemented by Level 2 technical standards, followed by Level 3 measures adopted by ESMA”. See par. 175 of https://www.esma.europa.eu/sites/default/files/library/esma50-157-1391_crypto_advice.pdf
10 Ibid, page 4, paragraph from 2 to 5.
11 Savelyev A., Contract law 2.0: ‘Smart’ contracts as the beginning of the end of classic contract law (2017),
Information & Communications Technology Law, 26:2, 116-134.
12 Bodó B., Gervais D., & Quintais J.P., Blockchain and smart contracts: the missing link in copyright licensing?
(2018), International Journal of Law and Information Technology, 26(4), 311-336.
13 Allen J.G., Wrapped and Stacked: ‘Smart Contracts’ and the Interaction of Natural and Formal Language, European
Review of Contract Law, Vol. 14 Issue 4, 2018, De Gruiter page 310.
14 Tjong Tjin Tai E., ‘Formalising contract law for smart contracts’ (2017), Tilburg Private Law Working Paper Series
5
legislations or as conceived by non-national normative tools. Indeed, some authors acknowledged the relevance of the contract law question but simply eluded to provide an answer 15, others by contrast allegedly took sides, nevertheless displaying great deals of inconsistency in their analysis 16.
The abovementioned inconsistency is due to the manifest difficulty to understand the technology, as well as the complexity that lies behind the legal word “contract”, in particular:
1. the heterogeneity of meanings that the signifier “contract” contains; 2. the characteristics, requisites and functioning of each meaning;
3. the shades and the different characteristics that a particular meaning can assume depending on the legal system taken into account.
Indeed, a contract can be, among many meanings, a set of facts and human conducts that the law can qualify as “agreement”, but one can also use the word contract to denote the “relationship” arising from that agreement, as well as a “text”, i.e. a complex of words through which the parties manifested their will. If one addresses one of the several meanings, e.g. contract as “agreement”, then the formation phase and characteristics of the agreement must be analysed, as well as the different structures that any legal system can give to that phase.
The main aim of my research is to give an answer to the question of “which are the regulatory solutions that the European Union and the Member States should adopt in addressing the legal issues that the technologic phenomenon of Smart Contracts gave rise to”.
In order to answer the main question, I will also provide an answer to two relevant sub-questions:
• firstly, which are the legal reasons why Smart contracts should be addressed, first and foremost, from a contractual perspective? Indeed, I will argue that SCs can constitute contracts under a legal meaning. The for this purpose, I will mainly
15 According to Balàzs Bodò et alia “legal systems lack a consensus on how code as contract fits into the traditional
concepts of contract law [..] Since the detailed analysis of all these contract law related issues is beyond the scope of this article, in the following we discuss the applicability of smart contracts in the copyright domain, thus proceeding under the optimistic assumption that such issues are resolvable in the long run”, Blockchain and smart contracts: the missing link in copyright licensing? (n. 11), page 316.
16 Pierluigi Cuccuru for instance starts its analysis saying that “in spite of their name, smart contracts are not legally
binding contracts in a technical meaning. Rather, they are an instrument for their conclusion or automatic enforcement”. Despite the premise, the author bases the whole description of Smart Contracts as if they were
fully-fledged contracts, focusing in particular on the rule of Courts in interpreting “computer-executed agreements” and addressing the rigidity of Smart Contracts “when shaping the content of (digital) relationships”. See Pierluigi Cuccuru,
Beyond bitcoin: an early overview on smart contracts (2017), International Journal of Law and Information
6
address the stage of the “formation”, which will mainly cover the analysis of the “offer and acceptance” stage. The formation stage is indeed the most relevant gate that has to be crossed if a factual phenomenon needs to be deemed as a contract. • Once ascertained that SC can be subsumed in the legal notion of contract, I will
answer to the sub-question of which the consequences and the issues are, deriving from that conclusion. In particular, I will write on the requirements that contract law poses and SCs must fulfil when considered as legal contracts. I will principally focus on the relationship between formal requirements and the “informatic” form of SCs, which is indeed the characteristic of SCs that gives rise to most of the legal issues thereof.
On the side of the law, I will use as main legal basis for comparison the “Draft of Common Frame of Reference” (DCFR) for the reason that, even if this instrument lacks either any political recognition or legal validity, it is nonetheless the most relevant comparative legal instrument aimed to synthesize the Contract law of former European Community’s countries17. The fact that is explicitly driven by a “centripetal rather than centrifugal force which tries to remove
externalities”18, being “a bridge connecting Civil and Common law” and with the aim “to
demonstrate the relatively small number of cases in which the different legal systems produce substantially different answers to common problems”19, makes it the best instrument in terms of validity and research efficiency to start a research based on legal categories rather than particular norms. Nevertheless, when that “small number of cases”20 will be encountered, resorting to national laws of EU Member States that can better solve the specific issue will not be prevented.
I will structure my work as follows: firstly, I will analyse blockchain as the underlying technology of Smart Contracts (SC) along with the functioning thereof. After having discussed this fundamental stage, I will answer the main question of my research through a process of subsumption between the technology and the structure of legal contracts. At a very last stage, I will provide my opinion on the status of European Contract law and on the question whether it is
17 It must be nonetheless stressed that the other main purpose of the DCFR, besides the comparative relevance of
synthesizing the most important national rules on contracts, is to bring “the principles of acquis communautaire in the
research on European Private Law”. See Reiner Schulze, Common Frame of Reference and Existing EC Contract Law,
Sellier, 2009, page 21.
18 Ibid 14.
19 Principles, Definitions and Model Rules of European Private Law – Draft Common Frame of Reference, Introduction
par. 7, 2009.
7
sufficiently equipped to regulate Smart Contracts and the legal issues arising thereof or, conversely, there is room for new developments in the field of European Contract Law.
Like any path that has not been yet covered, my research will be neither without useless deviations nor free from dead-ends: yet, “writing the future of contract law of the digital economic is a formidable task” 21.
2. Blockchain and Smart Contracts: an introduction
As mentioned in the previous chapter, Blockchain is currently the technology in the limelight, drawing the attention from many economic sectors 22, mainly due to the multiple uses which can be made thereof 23.
Two of the most famous and overlapping declinations of Blockchain technology consist in “Cryptocurrencies” and “Smart Contracts” 24. If on one hand the notion of the former is already well known to the public at large, giving a meaning to “Smart Contract” is conversely rather more difficult.
According to the first person to have introduced the concept of Smart Contracts, Nick Szabo 25, “the basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive” 26.
It is clear from the words of Szabo, that what he had in mind was to introduce a new standpoint from which contract law could have been seen, i.e. the perspective of computer programming. Even if the reference made by Szabo to the realm of contract law and private autonomy, when choosing the name of the new technology, was very clear, it nevertheless did not prevent some legal authors from denying the contractual nature of SC 27.
21 Beale H., Fauvarque-Cosson B., Rutgers J. & Vogenauer S., Cases, Materials and Text on Contract Law, Hart
Publishing, 2019, page 24.
22 Cooper M., Stanway H., How Blockchain is Changing Insurance, ITNOW, Volume 60, Issue 4, Winter 2018, Pages
16–17. Mattern, Max. 2018. Exploring Blockchain Applications to Agricultural Finance. CGAP Brief;. World Bank,
Washington, DC
23 Virtual Currencies and Beyond: Initial Considerations, IMF Staff Discussion Note – SDN/16/03 (January 2016), p. 35 24 “The former is a specific subtype of the latter”. Geiregat S., Cryptocurrencies are (smart) contracts, Computer Law
& Security Review (2018), n. 34
25 Szabo N., A Formal Language for Analyzing Contracts, https://nakamotoinstitute.org/contract-language/, 26 IMF Staff Discussion Note (n. 21).
8
The flaw of most recent legal works resides in the careless approach to the technologic side of the research. Instead, what it will be tried to do in this first chapter is to analyse Smart Contracts borrowing the same criteria used in the explanation of legal contracts: I will address the different stages that give life to Smart Contracts (formation), in order to ascertain if those stages can collimate with the formation process of legal contracts.
With that in mind, for the purpose of this thesis only SC based on blockchain technology will be addressed. Furthermore, it must also be pointed out that, since the first Smart Contracts implemented on blockchain consisted in the exchange of cryptocurrencies, the functional description of SC will be deeply interrelated with the analysis both of blockchain and bitcoins/cryptocurrencies. Moreover, it will be taken into account solely SC implemented on Ethereum platform, which is so far the most used programmable blockchain, due to its “Turing completeness”28, a concept which will turn to be fundamental when addressing the most structured type of Smart Contracts.
Beginning with Blockchain, this is a so-called Distributed Ledger Technology (DLT) consisting in “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. The ledger itself can also be programmed to trigger transactions automatically”29. In order to work as a distributed ledger, the Blockchain is based on a peer-to-peer network 30 that can verify the creation and transfer of digital assets.
But how does the transfer of digital assets work on (Ethereum) blockchain? For a better understanding and due to the inner nature of blockchain, the analysis will be done in a reversal order: the transactions’ registration process will be addressed first, coming to the description of transactions’ functioning only at a second stage.
28 “In computability theory, a system of data-manipulation rules (such as a computer's instruction set, a programming
language, or a cellular automaton) is said to be Turing complete or computationally universal if it can be used to simulate any Turing machine. This means that this system is able to recognize or decide other data-manipulation rule sets. Turing completeness is used as a way to express the power of such a data-manipulation rule set. Virtually all programming languages today are Turing Complete. The concept is named after English mathematician and computer scientist Alan Turing”. https://en.wikipedia.org/wiki/Turing_completeness
29 Iansiti M., Lakhani K., The Truth about Blockchain, Harvard Business Review (2017)
30 A distributed network architecture may be called a Peer-to-Peer network, if the participants share a part of their own
hardware resources (processing power, storage capacity, network link capacity, printers). These shared resources are necessary to provide the Service and content offered by the network (e.g. file sharing or shared workspaces for collaboration). They are accessible by other peers directly, without passing intermediary entities. The participants of such a network are thus resource (Service and content) providers as well as resource (Service and content) requestors (Servent-concept). Schollmeier R., A Definition of Peer-to-Peer Networking for the Classification of Peer-to- Peer
architectures and Applications, https://www.researchgate.net/publication/3940901_A_Definition_of_Peer-to-Peer_Networking_for_the_Classification_of_Peer-to-Peer_Architectures_and_Applications.
9
2.1. The functioning of Ethereum blockchain platform
Blockchain owes its name to the way it is structured. Blocks are nothing else that packages of transactions, a container where they are stored.
When a user generates a transaction, it is launched to the nodes (technological devices in the network, such as a Personal Computers) that are involved in the system. That transaction is then stored in the so called “MemPool”, an area where the nodes keep the transactions still to be verified. In order for a batch of transactions to constitute a block and this block to be added to the chain (so called “transition system”), a process of “verification” must take place.
Blocks can be verified by the network using cryptographic means: each block contains a timestamp (a value that indicates the time of the transaction), an hash (a unique cryptographic value that is provided by the previous block and constitute a reference by the new block to the “parent” block), and a nonce, which is a random number for verifying the hash. The network, in order to complete the validation process, uses those means through the following steps31:
1. The network verifies if the parent block referenced to by the new block really exists and if it is valid;
2. It checks if the timestamp of the new block is greater than the one of the parent block, in order to confirm that the new block is really subsequent to the parent;
3. It verifies if the proof of work (the hash) is valid:
4. If each of these three steps is valid, then the new block is added to the chain.
This system is not only what characterizes Blockchain and what makes the whole technology valuable, but it also embeds on of the main issues for lawyers when dealing with SC based on blockchain: the (theoretical) immutability of the chain and, consequently, of the transactions as well, whose implications will be further discussed in a later stage.
Once described the platform on which Smart Contracts can be implemented and, in particular, their role in the “state transition” of the blockchain, it is time to go into the details of how the Smart Contract itself works.
The Smart Contract, as already mentioned, is a transaction construed on and defined by a script, i.e. a program, whose object can be a simple cryptocurrencies exchange or a more complex set of instructions that the SC is aimed to fulfil (obligations).
10
Before coming to describe the possible content of SC (rectius, the script of SC), it is nevertheless necessary to describe the “parties” of SC, the “accounts”. There can be two kinds of accounts: an account “externally owned” (usually by a person), which is ruled by private keys, and a so called “contract account” ruled by their own code (which “consists of a series of bytes, where each byte represents an operation”32), autonomous due to the Ethereum Turing completeness.
In the Ethereum blockchain, “accounts” are made of four fields/information:
• A nonce: a system used to count the transaction and allowing each transaction to be processed only one time;
• The balance of Ethers (the “cryptofuel” necessary to in order to pay the transaction fees to the system);
• The account’s code; • The account’s storage.
Then, how to proceed with a transaction? In Ethereum, a “transaction” consists in a signed33 data package that embeds an instruction/message. Once the “transaction” is delivered, the Smart Contract is “concluded”.
The transaction has to provide the next set of information34: • The consignee of the message:
• The signature identifying the sender;
• The number of Ether to transfer from the sender to the consignee:
• An optional data field to be filled with the instructions that the consignee wants to deliver (so called “opcodes”);
• A “STARTGAS” value, consisting in the number of computational steps the execution of the transaction is permitted to take;
• A “GASPRICE” value, consisting in the cost the sender will pay per each computational step.
32 In the Ethereum white paper the complex notion of Contract Accounts is defined as follows: “Contracts in Ethereum
should not be seen as something that should be “fulfilled” or “complied with”; rather they are more like “authonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables”. https://github.com/ethereum/wiki/wiki/White-Paper
33 The signature is based on the cryptographic concept of “Asymmetric Cryptography”, which enables the system to
verify the full ownership and reliability of the signature without allowing the system to know the cryptographic content of the signature.
11
2.2 The three models
Depending on who (better, on what kind of account) is the sender and who is the consignee, Smart Contracts can take three different shapes, which I will divide in three categories for the sake of clarity in further discussions:
1. The transaction is sent by an externally owned account to another account of the same kind (Model 1);
2. The transaction is sent by an externally owned account to a contract account (Model 2); 3. The transaction is sent by a contract account to another contract account (Model 3).
These three shapes will assume particular importance in relation to the legal analysis since they will deserve three different layers of discussion.
To summarize, a Smart Contract is “concluded” when an account (of whichever type) sends a transaction/message to another account along with the amount of gas/money necessary in order to pay the cost of the computational steps and an algorithm serving both as ID and signature. Only if the account will be able to verify the correctness of the information provided by the sender, then the Smart Contract is concluded and executed.
It is nevertheless important to point out that, depending on the type of Smart Contract (thus depending on the type of accounts involved), different ranges of transactions’ complexity can be introduced, ranges that imply different levels of engagement by blockchain technology.
Indeed, Model 1 Smart Contracts can bear only a type of transaction 35: in fact, through this model only amounts of cryptocurrency can be sent from an account to the other, without making full use of the computational opportunities that blockchain offers.
Generally, it is with Model 2 that Smart Contracts come into the realm of everyday business life. This model can be used for the selling of e-services or e-products (if you give me a sufficient amount of money then the e-service/product), or for far more complex type of businesses, usually with the help of Oracles which are based on a system generally called Internet of Things (IoT) 36.
35 “Transaction” in general commercial terms, not in informatics terms.
36 “The basic idea of this concept is the pervasive presence around us of a variety of things or objects– such as
Radio-Frequency Identification (RFID) tags, sensors, actuators, mobile phones, etc. – which, through unique addressing schemes, are able to interact with each other and cooperate with their neighbors to reach common goals”. Atzori L., Iera A., Morabito G., The Internet of Things: A Survey, The International Journal of Computer and Telecommunications, n. 54 (2010)
12
A typical use of Model 2 Smart Contracts can be seen in the field of Insurance: we can imagine an Insurance company that wants to sell insurance policies covering the cases of flight’s cancellations. The company sets the policy’s terms in a contract account, then linking the contract account to an Oracle connected to the web. The person that wants to subscribe the policy just have to send a transaction/message (that complies with the requirements mentioned before) from their EOA to the contract account: once the message is stored in the contract account, in case of flight cancellation (verified by the Oracle through the information collected on internet) the contract account will automatically deliver to the EOA the amount “agreed”.
The logic behind the performance of Model 2 is called “if-then” and it is inherently linked to the informatic and computational nature of Smart Contracts. As it has been shown in the previous example, ‘if’ the condition of flight cancellation is met, ‘then’ the amount of the insurance coverage is delivered. It must be born in mind that, even if this logic’s conditions pertain to the performance of the Smart Contract, they are nevertheless often met at the same time of the “conclusion” of the SC: indeed, if the use of an Oracle is not necessary, the conclusion of the SC and its performance are simultaneous.
The Model 3 is instead the most complex to define and its spectrum of applications is indeed still undiscovered. This model brings smart contacting to the “next level”, where the concepts of contract, company and artificial intelligence can in principle overlap. In this case the SC consists in the only contract account and it is designed in such a way that its functioning is fully ‘autonomous’. Therefore, it is not necessary for a contract account to be triggered by an external account, but once the process of coding is done, the SC can assume ‘autonomous’ decisions, taking this way fully advantage of the Turing completeness37 proper of the Ethereum platform.
The first famous application of Model 3 can be seen in the first decentralized ‘autonomous organisation’ 38, the so called ‘DAO’. The aim of the team that created the DAO was to codify the rules and the decision-making apparatus of an organization/company, in order to get rid of the need for documents with the final purpose of creating a structure with decentralized control in which the human intervention was not needed 39.
37 Ethereum White Paper, https://github.com/ethereum/wiki/wiki/White-Paper
38 Lafarre A., Van der Elst, “Legal tech and blochchain for corporate governance and shareholders”, in Research
Handbook in Data Science and Law, edited by Mak Vanessa, Tjong Tjin Tai Eric, Berlee Anna, Edward Elgar Publishing (2018).
39 Interestingly, the DAO has also been the first case in which Ethereum system has been hacked. See
13
In Model 3 the contract itself can communicate both with other contract accounts and externally owned accounts, opening the SC system to a wide range of complex transactions.
3. The legal analysis
As it has been correctly said, there are “as many definitions of smart contracts as there are commentators”40, with legal remarkable contrast of views concerning the SC phenomenon.
The “father” of SC, as already mentioned, seemed to conceive SC as nothing but “common contractual conditions”41, where by contrast there are other scholars that deem SC as mere instruments to automatically enforce the terms of a contract 42. Other authors are less resolute when dealing with SC, limiting themselves to define SC as “contractual-type arrangements”43.
Furthermore, it has been said that it is not possible to accomplish the task of having a comprehensive and consistent legal analysis of SC since not all the contractual provisions and information can be embedded in SC through Computer Code and that, therefore, a proper legal analysis must be done “only on a case-by-case basis”44, i.e. only when the SC has the same structure and embeds the same conditions as a written contract would do.
This can be indeed true if one assumes an all-encompassing totalitarian approach, aiming to see whether the codes of SC have the characteristics in order to be deemed as a contractual paradigm. However, that does not match the purpose of this part of research: rather than see if SC can become a self-standing legal category, the task is to prove that SCs, when assuming certain shapes and when some conditions are fulfilled, can constitute a means for concluding a contract. Indeed, just as the fact that not all oral exchanges of information and intentions between two or more parties are contracts does not imply that a contract cannot be concluded in the oral form at all, the same applies with exchange of information and intention through SCs.
3.1 The subsuming processes.
The first fundamental step, when engaging the subsuming process of one phenomenon to a legal category, consists indeed in defining the content and the realm of the chosen legal paradigm. In the first chapter Smart Contract has been defined as the object of the research, whereas in the beginning
40 Athanassiou P., Impact of digital innovation on the processing of electronic payments and contracting: an overview
of legal risks, European Central Bank Legal Working Paper Series, no 16 – October 2017, page 34.
41 Szabo N., The Idea of Smart Contracts, 1997.
http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.v wh.net/idea.html
42 Cuccurru Pierluigi.
43 Athanassiou P., Impact of digital innovation on the processing of electronic payments and contracting: an overview
of legal risks, (no. 36), page 35.
14
of this second chapter space will be given to the analysis of the legal paradigm, i.e. the notion of contract.
The word “Contract” is usually a signifier that can contain at least three meanings: (i) it can consist in a set of facts and human behaviours that law may qualify as an agreement; (ii) contract can be understood as a relationship, in terms of reciprocal positions (rights and obligations) between the parties: (iii) contract can mean legal text, as a complex of words and signs through which the parties decided to define their agreement45. Although these three meanings are nothing else than sides of the same figure, only number (i) and (iii) will be fully involved in the discussion, whereas number (ii) will be marginally taken into account.
In order the accomplish my aim, I will take the standpoint of the Draft Common Frame of Reference the provisions set for in it, since DCFR is not only a principle-based normative means that suits the best to a subsuming task, but it is also assumed to be the normative means whose basis is rooted into the most relevant European legal systems46.
The DCFR at article II.-1:101 gives the following definition of "contract": “A contract is an agreement which is intended to give rise to a binding legal relationship or to have some other legal
effect. It is a bilateral or multilateral juridical act”47.
According to the definition provided for by art. II.-1:101, there are three conditions that must be present in order to have a contract: (i) a (sufficient) agreement, (ii) the intention of both parties to reach that agreement and give birth to a relationship with legal effects and, finally, (iii) the presence of at least two parties. I will discuss if these conditions can be deemed present in the three different types of Smart Contracts discussed in the first chapter. Smart Contracts are indeed “legally binding only if parties have agreed upon all essential requirements needed for the conclusion of the contract”48.
3.2 The programming language
45 Fauvarque-Cosson B., Mazeaud D., European Contract Law – Materials for a Common Frame of Reference:
Terminology, Guiding Principles, Model Rules, 2008, Sellier, page 6; Roppo V., Il Contratto, Giuffrè Editore, Milano
2001, page 123.
46 Schulze R., Common Frame of Reference and Existing EC Contract Law, (n. 15), page 21.
47 It must be noted that art. II. - 4: IO I:, dedicated to the “Requirements for the conclusion of a contract” essentially
repeats what already defined in art. II. – 1:101, in fact it provides that “A contract is concluded. without any further
requirement, if the parties: (a) intend to enter into a binding legal relationship or bring about some other legal effect; and (b) reach a sufficient agreement”.
48 Kolvart M., Poola M., Rull A., “Smart Contracts”, The Future of Law and eTechnologies, Springer International
15
Nevertheless, there is a preliminary issue that must be addressed in order to start a valid contractual analysis and it relates to the nature of SC: indeed, they consist in a set of textual instructions given in programming languages. A question that usually arises when bringing informatic-related topics into the realm of law and clearly present in the SC debate, is whether the programming language can be considered on a par with oral or written language and therefore means for concluding a contract.
The answer to the abovementioned question differs according to the different perspectives the problem is addressed from. If one takes the perspective of transparency and clarity of the information provided for by the contractual text, then using an informatic language can be eventually troublesome when the legislator requires some standards of clarity49.
However, what is indeed relevant for this stage of the research, is whether an informatic text can be a means to manifest the parties’ intent, whose encounter forms the contractual agreement. Here the text fulfils a pure subjectivist purpose that leads to a dissociation between the declaration and the text itself 50.
In order to give a solution, few considerations must be done on the correlation between the means for concluding a contract and the contract itself (conceived in this case as ‘contractual relationship’).
In the case of SC, the informatic code leaves no room for doubts: the informatic declaration constitutes first and foremost the means to accomplish will of the parties. Furthermore, that declaration must be construed in a way to allow a perfect collimation with the characteristics of the other party’s declaration. In this sense, it can be said that informatic declarations of such kind constitute both a declaration, made in a textual form, and a “conclusive behaviour”51, consisting in providing the tools for the obligations’ performance.
3.3 The Agreement
There are different possible starting points when addressing the agreement, I will thus start from the formation thereof, i.e. the encounter of (wills set in the) offer and acceptance. It must be nevertheless borne in mind that “offer and acceptance” is not the only model through which a
49 For example, in the context of B2C contracts, the DCFR requires that the information provided in the contract by the
undertaking “must be clear and precise, and expressed in plain and intelligible language”. See art. II. – 3:106.
50 Roppo, p.195
51 DCFR does not acknowledge the conclusive behaviour as a way to conclude a contract. Interenstingly, does it so the
European Contract Code drafted by the “Pavia Group”, whose article 1 paragraph 2 provides that a contract “can also be created by conclusive behaviours”.
16
contract can be concluded, it simply consists both in the most common normative scheme and in the highest in hierarchy according to the way DCFR is construed.
Before engaging in the discussion on the conclusion of the contract through the ‘offer and acceptance’ system, it is useful to underline that according to DCFR the rules set for in the section dedicated to offer and acceptance also “apply with appropriate adaptations even though the process
of conclusion of a contract cannot be analysed into offer and acceptance”52.
Furthermore, one of the difficulties of analysing the agreement when it comes to Smart Contracts given their nature of performance system, is to keep well in mind that one of the key factors is “the place” where (rectius, the means through which) the will of the parties meet each other. It is indeed well possible that the parties make a contract whose performance relies on Blockchain Smart Contracts, but still the blockchain is neither the place nor the means where and through which the will of the parties is manifested. The challenge for Contract law is to determine if, besides being a means for obligation’s performance, SC can be also an eligible means through which wills can encounter53.
In order to accomplish the abovementioned task, in must be determined if the SC is capable to embed all the requirements set forth by the chosen legal paradigm. Indeed, according to DCFR, paragraph II. – 4:201, “(1) A proposal amounts to an offer if: (a) it is intended to result in a contract if the other party accepts it; and (b) it contains sufficiently definite terms to form a contract. (2) An offer may be made to one or more specific persons or to the public.
Concerning instead the acceptance stage, II. – 4:204 provides that “Any form of statement or conduct by the offeree is an acceptance if it indicates assent to the offer. Silence or inactivity does not in itself amount to acceptance”.
In the following three paragraphs it will be seen if the three models of SC can satisfy the requirements of the “offer-acceptance” as provided for by DCFR.
3.4 Model 1
If we analyse Smart Contract Model 1 and its functioning, we can see rather easily that this model cannot constitute a contract according to DCFR. As it has already been discussed, Model 1 is indeed
52 Article II. – 4:211: “Contracts not concluded through offer and acceptance”.
53 In fact, some authors have argued that SC cannot be legal contracts if there is a previous agreement reached
“off-chain”. In those cases, they would be nothing more than “accessory agreements”, settlement mechanisms of follow-up of other contracts. The implication is that “smart contracts would only be legally binding on their parties if their execution were to in no way contradict a prior contractual arrangement between the parties nor any mandatory, public law provisions applicable thereto at the time of their formation”. See Athanassiou Phoebus, page 37.
17
construed in a way that allows only transfer of values (cryptocurrency) from an EOA to another EOA. In this case the conditions set forth in art. II – 4:201 (1)(a) cannot be met: the reason behind this conclusion is that the Model 1 is not designed to fulfil the previously discussed “if-then” logic (proper of Model 2 and Model 3), since in Model 1 no “Contract Accounts” are involved.
This issue gives the opportunity to shed light on two fundamental and linked characteristics of SC: i) only Contract Account can incorporate the conditions of a contractual offer; ii) the contractual offer (expressed in informatic code) is at the same time the means through which the contract, if concluded, will be performed. Therefore, it can be said that the offer constitutes the only means for performing the contract.
Model 1 can be deemed instead as a unilateral legal act on a par with a transfer of money from a bank account to another, with the exception that no intermediaries are involved in the process of authorization and performance of the transaction 54. The central point here is that, even if there are two accounts involved, and even if we consider the transfer of money a manifestation of will through performance from the sender and the ‘silence’ of the receiver as if a manifestation of will by both the parties through the means of the accounts themselves (and their ability to send messages/instructions).
This interpretation seems to be confirmed by the first (and so far, only) decision held by the Court of Justice of the European Union (CJEU) 55 on a blockchain-related dispute. The issue in the proceeding involved a Swedish company whose main activity consisted in the purchase of “bitcoins” directly from private individuals, companies or exchange sites and with the purpose of “selling” the cryptocoins to other individuals or companies in return for Swedish Crowns. The main question consisted in whether that kind of transaction had to be subject to VAT, considering the fee that was included in the selling price.
The CJEU, recalling the words of the Advocate General in her Opinion 56, held that “virtual currency has no purpose other than to be a means of payment” and, furthermore, that “it is common ground that the ‘bitcoin’ virtual currency is neither a security conferring a property right nor a security of a comparable nature”.
54 This is one of the most important characteristics that indeed makes blockchain so appealing. See Maupin J., Mapping
the Global Legal Landscape of Blockchain and other Distributed Ledger Technologies, 2017, Centre for International
Governance Innovation Papers no. 149.
55 Case C-264/14. 56 Ibid, par. 24.
18
The Court speaks also of a “synallagmatic legal relationship” between the parties, nevertheless the discriminant in this case consists in the offer and the request for the purchase of bitcoins made on the company’s website and not directly with a message on the chain: in this case we have definitely a contract, but it is concluded off the chain.
The analysis made by the Court shows that the understanding of a transfer of bitcoin on blockchain, in return of something else that cannot be transferred or implemented on the same platform, cannot be considered as a contractual relationship but, conversely, only a means to perform the obligations thereunder.
Apparently, there are no chances for Model 1 to constitute a contract, at least according to DCFR, not even if we think of a possible contract for the donation of cryptocoins mainly due to the necessary presence of an explicit acceptance by the donee5758.
Indeed, ‘silence’ cannot be deemed as a valid form of acceptance according to Art II. – 4:204, which clearly states that “(1) Any form of statement or conduct by the offeree is an acceptance if it indicates assent to the offer. (2) Silence or inactivity does not in itself amount to acceptance”. Nevertheless, according to the members of the “Study Group on a European Civil Code”, “nor is acceptance required when it follows from an earlier statement by the offeree, e.g. in an invitation to
make an offer, or from usage or practices between the parties, that silence will bind the offeree”59.
In order to explain this particular case, the following example has been formulated: A ask B for a bid to paint the railing surrounding A’s factory telling B that it can start painting a week after it has sent its bid unless before that time A has rejected the offer. Having sent the bid and heard nothing from A, B stars painting. A is bound to the contract.
If the theory leaves room for the formation of a contract, it is the nature of the blockchain that makes it impossible: in fact, the sending of an amount of cryptocoins can neither be preceded by an offer made through the chain, nor the message that sends the coins can both embed at the same time an offer and a program that would hold the execution for a certain period of time (as the example requires): the offer, in a certain sense, would be absorbed by the performance. Indeed, it is common
57 See art. IV.H. – 3:301.
58 It has been explicitly stated by the authors of DCFR that “the done is not obliged to take delivery and accept transfer
of ownership if the donor gratuitously, with an intention to benefit, unilaterally undertakes to transfer the ownership of goods to the done. The obligations of the done can only arise from a contractual relationship between donor and donee”. Ibid
59 Principles, Definitions and Model Rules of European Private Law – Draft Common Frame of Reference, Prepared by
the Study Group on a European Civil Code and the Research Group on EC Private Law (Aquis Group), Sellier. European law Publishers (2009), page 310.
19
ground in most of the legal systems that the execution itself can conclude a contract only if it comes from the offeree and not from the offeror, otherwise the offeree would undergo a contract imposed by the unilateral initiative made by the offeror, without any manifestation of will by the former60.
In conclusion, Model 1 is pure execution and it cannot be the means to conclude a contract since there is not a temporal space between the possible offer and the execution.
3.5 Model 2
Model 2 is what can be deemed as the ‘classical’ Smart Contract, the type that holds most of the potentialities of blockchain technology 61
To approach the legal discussion of SC Model 2, it is useful to start from the first analysis provided for by the inventor of (off-chain) Smart Contracts62. He introduces a quite simple concept to explain smart contracts, fundamentally comparing the functioning of SC to the functioning of a vending machine.
The vending machine model can in principle suit Model 2 of “on-chain” SC. Since the SC has been defined as “an agreement whose execution is automated” 63, this definition could either easily fit the system of the vending machine: in fact, the modern vending machine usually embeds a hardware programmed in a way that whenever the machine receives the pre-defined amount of money, it delivers the requested product. In this sense the machine logic holds the same “if-then” logic proper of SC.
As we have seen in the previous chapter, Model 2 can be used for several purposes and can replicate on a blockchain platform the functioning of legal contracts as for example contracts of insurance.
The particularity of Model 2 lies in the fact that the terms of the contract, in the case of an insurance contract it is more appropriate to appellate them “general conditions”64, have to be drafted in the contract account. The contract account is therefore the place that embeds all the passages and the
60 Roppo V., page 123.
61 World Econ. Forum, The Future Of Financial Infrastructure: An Ambitiouslook Athow Blockchain Can Reshape
Financial Services 29 (2016).
62 A Formal Language For Analyzing Contracts Copyright (C) 2002 By Nick Szabo;
Http://Www.Fon.Hum.Uva.Nl/Rob/Courses/Informationinspeech/CDROM/Literature/Lotwinterschool2006/Szabo.Best .Vwh.Net/Contractlanguage.Html
63 Raskin M., The Law And Legality Of Smart Contracts, Georgetown Law Technology Review, Vol. 1:2, Page 309. 64 The Principles of European Contract Law define the “general conditions of contract”, art. 2:209, as to terms
formulated in advance “for an indefinite number of contracts”. Nevertheless, it is a notion that seems too narrow: they can be named “general conditions” also if they are meant to be valid for a definite number of contracts. See Ibid 43, page 160.
20
structure of the “if-then” logic. The “contract” is concluded when an externally owned account communicates the acceptance message (with the right data) to the contract account.
Of course, the contract account can be defined in a way that the contract would fit only the request made by a targeted EOA, but it can also be programmed in a manner suitable for any EOA interested in engaging in that insurance contract.
Model 2 seems indeed to fit the requirements provided for by art. II – 4:201 and II – 4:204: the owner of the contract account define the contractual terms and manifest the offer putting it on the Ethereum platform, then the owner of the EOA, if interested in the conclusion of the contract send the acceptance through the same EOA and contract is therefore concluded (and performed).
Given the nature of the offer, whereby the offeror draw up ex ante the contractual terms, the contractual figure that would better fit this scheme of conclusion is the “contrat d’adhésion”65 66, which is a contract where the terms are “standard”, i.e. “which has been formulated in advance for several transactions involving different parties and which has not been individually negotiated by the parties”67. Classifying Model 2 SC as ‘standard contracts’ seems also “consistent with the self-executing dimension of smart contracts and their systematic performance”68
3.6 Model 3
Model 3 is indeed the most challenging from a law perspective because it slightly moves the discussion from a purely contractual discussion, where the legal analysis is focused on contract functioning, to the realm of organisations, in which the contract is involved in the discussion insofar as it gives rise to new “entities” and defines the structure thereof.
The DAO’s case is paradigmatic to understand how Model 3 can be used: the creators developed a set of SCs, interacting between each other, which allowed investors to contribute funds directed to an investment pool through a process called “initial coin offering”69. In exchange, the investors had “tokens” that provided them “the right to vote, in proportion to their token holdings, on which
start-up projects the pool should fund”70.
65 Art. 1110 French Civil Code. 66 Ibid 9, page 123.
67 DCFR article II. – 1:109.
68 Cannarsa M., Interpretation of Contracts and Smart Contracts: Smart Interpretation or Interpretation of Smart
Contracts?, European Review of Private Law 6-2019, Kluwer Law International BV, page 782.
69 For a reliable analysis of ICOs see
https://www.esma.europa.eu/sites/default/files/library/esma50-157-1391_crypto_advice.pdf
21
At a first glance it seems nothing but a venture capital fund. Yet, the DAO was much more than a fund: it had no physical place, no leadership (neither board of directors nor management) and, above all, “all of its operations were carried out in an autonomous decentralized fashion on the
blockchain itself”71.
Yet, can the DAO be deemed to be a company? And most importantly for the contractual analysis, can the SCs forming the DAO constitute a legal act (contract) forming a company? Some tech-authors gave already their answer, defining the DAO as “a corporation whose bylaws are written
entirely in code”7273.
Since there is not a European comprehensive normative tool that provides a shared definition of company74 , in order to understand if Model 3 can be considered a contractual means to incorporate a company I will take the perspective of Italian company law.
The Italian Civil Code in its article 2247 establishes that, in order to incorporate a company, there must be a contract through which two or more parties bind themselves to confer goods or services for the exercise of an economic activity75. The Civil Code thus defines the first fundamental step towards the formation of a company as a multilateral contract whereby the parties manifest their will. Can the condition set forth in art. 2247 be verified in the DAO system (as the first existing example of Model 3)?
The answer would in theory be affirmative: the code constitutes a system that oblige the parties to confer funds of some entity, in fact “the action of uploading that asset to the smart contract
provides an unequivocal communication of acceptance”76 as a manifestation of will. Furthermore, it
defines the object of the economic activity and the way it must be carried on.
71 Ibid 54, page 18.
72 Bannon, Seth, The Tao of “The DAO” or: How the autonomous corporation is already here, at
https://techcrunch.com/2016/05/16/the-tao-of-the-dao-or-how-the-autonomous-corporation-is-already-here/?guccounter=1&guce_referrer_us=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_cs=zhDt8qymqz1LT Zm-TimvXw
73 Nevertheless, it must be pointed out that, in the real case of the DAO, there was an ‘out of chain’ contract already in
place between ‘Slock.it’, the company implementing the DAO, and the community of users. The contract stated that “the term [contract] is a programming convention, not a representation that the code is in and of itself a legally binding and enforceable contract”. This fact, as previously mentioned in this chapter, does not prevent to engage in a legal analysis based on the underlying system composing the DAO. See Athanassiou P.
74 Nor REGULATION (EC) No 2157/2001 on the Societas Europea is relevant, since SE can be created only from an
existing company formed according to the national rules.
75 “Con il contratto di società due o più persone conferiscono beni o servizi per l'esercizio in comune di un'attività
economica allo scopo di dividerne gli utili”.
76 Durovic M., Janssen A., The Formation of Blockchain-based Smart Contracts in the Light of Contract Law, European
22
Nevertheless, the question, and more in general the analysis of the DAO, brings the relationship between existing law and SC technology to the ultimate clash. In this case the lawyer must cope with a set of pre-programmed informatic rules which (i) implicitly show the intention of the authors to build the system, (ii) define how the system should work according to their authors and, finally, (iii) run the system in autonomy. The SC here becomes contract, statute and corporate bodies, all at the same time.
The last reflection then gives the floor to a first evaluation. The analysis made so far takes only a partial perspective, both from the side of the contractual life-cycle (i.e. the formation) and the side of the normative tool (DCFR).
Yet, the analysis made so far brings to the first conclusion that “the formation of smart contract as the procedure of the formation of such agreements accommodates the elements of offer and acceptance”77, at least, concerning two out of the three models identified.
The analysis made so far bring to the further conclusion that SC can fulfil the requirements posed by Contract law in order to be deemed as legal contracts78.
It must be however stressed that, most of the Smart Contract concluded so far carry out only the function of executing provisions that have been already defined and agreed upon somewhere else. As already pointed out, the fact that most of the times the agreement is concluded outside the SC does not deprive the legal analysis from validity, consistency and utility. It is indeed likely that a rapid increase of SC’ use will happen in the next few years, bringing with it a need for more easiness in the conclusion thereof, with possible users being more accustomed to this technology and therefore more prone to bypass out-of-chain agreements, opting instead for concluding agreement directly on the SC.
However, some scholars came to the further conclusion, based on the flexibility and adaptability of contract law79 that “the existing contract law framework is more than adequate to accommodate even this revolutionary form of deal making, without the need to create new legal categories that,
77 Ibid, page 763.
78 This view is indeed shared in the most recent works if private lawyers, for example according to De Caria R. “smart
contracts do fall within existing contract law principles”. See De Caria R., The Legal Meaning of Smart Contracts, European Review of Private Law 6-2019, page 747.
79 Di Matteo L., Poncibò C., Quandary of Smart Contracts and Remedies: The Role of Contract Law and Self-Help
23
contrary to a common belief among regulators and policy makers, are not truly warranted in this case”80.
I do not share this view. Yet, the legal analysis made so far has been indeed useful to recognise that these technological phenomena place themselves in a dark zone of any legal system, the “interstitial spaces” between norms81. In fact, they can be something but, at the same time, from a legal standpoint be something totally different. They can be means for concluding a contract, they can be contract themselves, they can be means for enforce the contract, they can be also the assets that have to be transferred, combining all these possibilities depending on the aim they must fulfil, and on the way the are construed. SC consist in legal hybrids and they can, depending on the shape they assume and the perspective the commentators assume, trigger the question “whether there is still a contract in a legal sense and not some other kind of phenomenon”82.
Furthermore, the partial approach taken in this research and in most of the Contract law analysis completed so far, does not take into account the requirements that any legal system, whether national or supranational, pose to a contract in order to be valid. In fact, the first purpose of my research was to ascertain if SC were legal contract, that is to say if SC were contractual phenomena that could comply with the principles of Contract law. Nevertheless, my research did not address the other meaning of ‘legality’, namely whether a legal system allows to use instruments that have already been subsumed within a particular legal category, i.e. legally acknowledged.
In the next chapter some of the issues that the latter notion of ‘legality’ poses will be addressed: I will try to describe if “modern contract law must allow a contract to be formed in other ways than the traditional model”83 and therefore, if a need for a new regulation of SC arises, or whether SC can survive the contract law’s check points.
4. Regulation
Determining if the technologic phenomenon of SCs falls within the realm of contracts has not been a secondary task: rather, it is a fundamental first step in order to solve the question on if and how to regulate that phenomenon. Indeed, if we assumed that SCs could not consist in legal contracts, they would have been confined to the function they have been originally conceived for, i.e. as means for performing transactions. The regulatory analysis on SCs would thus have been directly pointed
80 De Caria R., page 748.
81 Allen J.G., Wrapped and Stacked: ‘Smart Contracts’ and the Interaction of Natural and Formal Language, European Review of Contract Law, 2018, Vol.14(4), De Gruyter
82Savelyev A., Contract law 2.0: ‘Smart’ contracts as the beginning of the end of classic contract law, page 120. 83 Ibid 36, page 139
24
towards both the rules on performance provided for by the national and non-national contract law rules, and the enforcement systems granted by the national and international civil procedural law.
Nevertheless, once acknowledged that the SC can be a contract in legal terms, it necessary to address the legal consequences of that recognition.
Blockchain-based SCs are meant to be one of the disruptive forces 84 that will drive the future economy and will render transactions more efficient, fast and cheap. Nevertheless, before being efficient fast and cheap they must indeed be valid.
National and non-national contract law can embed several grounds for declaring a contract not valid. The DCFR for instance dedicates an entire chapter85 to the grounds of invalidity. However, the characteristic that make SCs so different is the conclusion of the agreement in the form of informatic programs. Therefore, the legal scope will be reduced to those grounds of invalidity arising from the breach of mandatory rules on formal requirements.
Contract law, especially from the European perspective we assumed, is an intertwined set of check and balances where general provisions are limited or extended by specific rules. Further requirements are posed by both general contract law and special provisions meant to regulate contracts in particular fields or between parties with specific qualifications and characteristics.
Those requirements often regard the “form” that a contract must assume, and they can be either external to the contract, such as the obligation to validate contracts by a notary/solicitor (deeds in Common Law systems), or internal, such as transparency requirements for contractual terms related to prices. Not complying with those mandatory provisions usually implies some declarations of nullity.
Some authors see in external requirements a threat to the utility of SC as well as to their validity86. External requirements can be found in those contracts that need, in order to be valid or effective (ad validitatem), some form of external validation usually required by the national legislator. An example is the contract of donation: even though the legal paradigm I used so far does not provide for external requirements for the donation in order to be valid 87, those requirements are nevertheless usually posed by national legislation. Indeed, for example the Italian88 and the French
84 Gikay A.A., page 27. 85 DCFR, Book II Chapter 7.
86 Muka Tshibende L.D., Contract Law and Smart Contracts: Property and Security Rights Issues, European Review of
Private Law 6-2019, Kluwer Law International, page 875.
87 Indeed, in DCFR Book IV Part H art. 2:201, dedicated to the formal requirements of the donation, it cannot be seen
any external formal requirement.
