
The notion of smart contracts, a translation of the American notion of smart contracts created in the 1990s by Nick Szabo, is currently undergoing a major boom, particularly due to the development of blockchains. Many companies are touting the advantages of smart contracts. However, from a legal point of view, these contracts could pose more problems than traditional contracts.
In 1996, Nick Szabo wrote an article entitled “Smart Contracts: Building Blocks for Digital Markets“. In this article, he explains that the digital revolution allows for new ways of formalizing relationships, and in particular economic relationships. Nick Szabo calls these new relationships smart contracts because he believes that they are far more functional than their paper-based ancestors. Specifically, he explains that a smart contract is a set of promises implemented in digital form. His definition is very broad and seems to include all automated relationships. Nick Szabo considers the ancestor of smart contracts to be the vending machine.
Today, the term “smart contracts” is often used in a narrower sense, although there is no precise definition. It should be noted that smart contracts are not necessarily contracts in the legal sense. For example, the documentation for the Solidity computer language, which allows smart contracts to be created on the Ethereum blockchain, explains that smart contracts “are programs that govern the behavior of accounts in the Ethereum state “, i.e., for computer scientists, smart contracts are lines of code stored on a blockchain. More precisely, they are conditional computer programs based on “if-then” functions. The concept of automatism invoked by Nick Szabo is thus present.
The Ethereum documentation explains that the term “intelligent” was chosen because “when the conditions for the execution of these commitments are met, they automatically execute on the blockchain, considering all the conditions and limitations that were originally programd into the contract”. It may seem curious that intelligence is equated with automatism and not with the possibility of adapting. David Weshler, for example, considered that “intelligence is the comprehensive or complex capacity of the individual to act with a purpose, to think rationally and to relate usefully to his environment “. In contrast, intelligent contracts do not interact with their environment and apply lies of code mechanically. This irrevocability, which is very often equated with the impossibility of non-performance, is often put forward by the advocates of so-called smart contracts. Nick Szabo explained back in 1996 that smart contracts would make it very costly to break promises made and that, as a result, parties to a smart contract would necessarily fulfil their obligations. Today, for example, the slogan of the Bithalo company is: “The world’s first unbreakable contracts, no more intermediaries, no more money lost in exchanges. No more fear, uncertainty, and doubt! The few reflections that follow will question the reality of his claims. However, it is appropriate to begin by questioning the legal validity of smart contracts concluded on a blockchain.
The validity of smart contracts
According to Article 1101 of the Civil Code, ‘a contract is an agreement of wills between two or more persons intended to create, modify, transmit or extinguish obligations’. Furthermore, according to Article 1109 of the Civil Code, ‘a contract is consensual when it is formed by the mere exchange of consents, regardless of the way they are expressed’. It is therefore entirely possible for computer programs to formalize contractual obligations, i.e. the mere fact that a smart contract is lines of code inserted in a blockchain will not automatically render it null and void. However, as smart contracts are based on “if-then” functions, the obligations that can be formalized using this process are relatively limited. These will mainly be impersonal contracts, such as the transfer of funds. The Fizzy insurance, launched in 2017 by the insurance company AXA6 , for example, allowed travelers to be automatically compensated when their plane was more than 2 hours late. The compensation was done through a computer program stored on a blockchain, i.e., through a smart contract7. More complex contracts, such as relational contracts, cannot be reduced to “if-then” functions. It is nevertheless possible to foresee that certain obligations of a relational contract are implemented in a smart contract. This could be the case, for example, of a franchise agreement where the royalties are paid through a smart contract.
It is possible to consider that some smart contracts can be the basis for consensual contracts, although in the event of a dispute the question of the interpretation of the lines of code will arise. On the other hand, when the formation of a contract requires a written document, it seems difficult to consider that lines of code will suffice to meet the formal requirements. Article 9 of Directive 2000/31/EC lays down the principle of the validity of contracts concluded by electronic means and provides that the Member States shall ensure that their legal system makes it possible to conclude such contracts. In France, Article 1125 of the Civil Code provides that “electronic means may be used to make contractual provisions or information on goods or services available”. Moreover, according to Article 1366 of the Civil Code, “an electronic document has the same evidential value as a paper document, provided that the person from whom it originates can be duly identified and that it is drawn up and stored in conditions that guarantee its integrity”. The notion of “electronic means” in Article 1125 of the Civil Code can undoubtedly include lines of code stored on a blockchain, since the latter, if it exists, is accessible on the Internet. However, will judges consider that lines of code can be contractual stipulations or an electronic writing? This is because both concepts require the writing of sentences, which is not the case with lines of code. Lines of code are written in a computer language, such as Solidity for the Ethereum blockchain, which looks like this:

This language is therefore not easily accessible to non-English speaking computer scientists. Moreover, each blockchain may have its own computer language. It should be noted that since storage on blockchains has a cost, only the necessary lines of code will be stored. It would not be economically efficient to store on the blockchain the contract written in European and its electronic language version. In any case, as the blockchain only understands computer language, only this version would be applied in practice. Because of their language, smart contracts seem difficult to envisage as a replacement for formal contracts. However, such a contract stored on a blockchain would be enforced, even if a party went to court to have it declared invalid. Indeed, we will see that smart contracts stored on a blockchain are automatically executed, i.e., it is not possible to modify them, except for the program lines provided for this purpose. Moreover, once a smart contract has been executed, it is not possible to go back, at least on the blockchain.
As smart contracts can formalize contracts, it is necessary to check whether they have the qualities put forward by the companies using them.
An unbreakable or immutable contract?
The term ‘unbreakable’ can be understood, on the one hand, as qualifying a contract which cannot be altered and, on the other hand, as qualifying a contract for which contractual non-performance is impossible. The first assertion is probably the least disputable, even if it is not absolute. This characteristic derives from the fact that a smart contract is stored on a blockchain. The latter, thanks to decentralized management, prevent in principle the falsification of stored data because each new block added is irremediably linked to the previous one and because a copy is transmitted to all members of the network. Consequently, changing one element of an old block would require rewriting the entire history of the blockchain at a faster rate than adding new blocks, or would require taking control of the blockchain by owning more than 50% of the network. The Ethereum blockchain, for example, was modified, with the agreement of most of its members, in 2016 in order to return funds that had been misappropriated9. The security of a blockchain is therefore entirely dependent on the number of its members, and members depend on the rewards they obtain10. The data stored on a powerful blockchain, such as Ethereum or Bitcoin, is virtually unforgeable. Moreover, it cannot be lost because every computer on the network has a copy. On the other hand, data stored on a blockchain with few members are vulnerable, which is the case with private blockchains.
A smart contract stored on a powerful blockchain will not be alterable, but in return, it can be freely consulted. However, since the parties are only identified by an identification key, their anonymity is relatively guaranteed. Nevertheless, the knowledge of an identification key makes it possible to find all transactions, with their content, made with this key. In addition, US researchers, by studying Bitcoin money transfers, have been able to trace in detail the interactions of merchants with their consumers11.
While smart contracts stored on a powerful blockchain are virtually unforgeable, they will not make contractual default disappear. If we take the Fizzi insurance, which allowed travelers to be compensated automatically when their plane was more than 2 hours late, if the account in the programd was empty, travelers would not have received any compensation. The “if” function (more than 2 hours delay) would have been fulfilled, but the “then” function could not have been executed due to lack of money. Moreover, a smart contract may have been perfectly executed from an IT point of view but not from a legal point of view. For example, a smart contract can be used to pay the price of a sold good. Let us imagine that a computer programd provides that the price, deposited in an escrow account, will be automatically paid to the seller when the buyer electronically signs12 the postman’s receipt. A few days later, the buyer signs the receipt, and the agreed price is paid to the seller. As a result, the computer programd has worked perfectly. However, if the goods received do not conform to the goods sold, there is a breach of contract. The question then arises again of the interpretation of the smart contract. The latter simply provides for payment of the agreed price (“then” function) after signing an electronic receipt (“if” function). The computer program cannot incorporate the expected characteristics of the good sold, or even just its nature. It is perfectly possible to specify these elements in the commentary of the program. However, this would increase the cost of the smart contract and would not affect its execution in the blockchain. To solve this difficulty, the companies Bithalo or BlackHalo, for example, require the seller and buyer to deposit the sale price in an escrow account. If they do not validate the payment of the price to the seller within the given time limit, the deposited funds are then sent to a third party (whose name the parties do not know) and are then irrecoverable for both parties. However, it is not clear that this system is more secure or practical than traditional contracts, particularly as the seller must have sufficient cash to make the deposit.
A contract without intermediaries
The advocates of smart contracts point out that, since they are automatically executed, intermediaries, in particular banks, are no longer necessary. Indeed, the direct and unconditional transfer of money on a blockchain, since the money transferred is the currency on the blockchain (Bitcoin or Ether for example), does not require a central bank. However, smart contracts, especially on the Ethereum blockchain, are not limited to direct money transfers. Therefore, to execute, a smart contract using if-then functions needs to know if the condition is met. Two situations arise. The most automatic and objective is to refer the program to a database. For example, the Fizzi insurance computer program connected to the Flightstats site to determine if the plane was more than 2 hours late. There was no human intervention, and the smart contract was executed automatically. However, the use of a database does not eliminate all difficulties, especially as the database can disappear. It is therefore important to include this possibility in the program to avoid, for example, funds being permanently blocked. Although the use of databases makes it possible to limit human intermediaries, it is not always possible to link the triggering of a condition to such a database. In this case, the program can refer the decision making to a trusted third party. For example, the program may provide that the trusted third party will decide whether the funds blocked in an account will be transferred to the seller or returned to the buyer. So smart contracts do not eliminate all intermediaries. On the contrary, their power is increased, hence their name of oracles.
Would you like to get more information about smart contracts? Contact us today.