This is perhaps the most interesting article about the prospects for the use of smart contracts in business practice, which I came across (though not many came across them). It is written by lawyers and published at the end of May on the Harvard website. Although the example of the United States, the text reveals such issues as the application of legislation to transactions on smart contracts, the problem of understanding the code by the parties, the problem of oracles, risks, and others.

Including you will find an explanation why vending machines (as an example of the most visual and simple implementation of a smart contract) people have been using for a long time and successfully, and the use of more complex smart contracts, for example in logistics or insurance, is still difficult.

Smart contracts are a crucial component of many platforms and applications built on the basis of the blockchain, that is, distributed registry technology. Below, we look at the work of smart contracts, find out whether they can be considered legally binding legal agreements under US law, and discuss the legal and practical issues that need to be resolved before smart contracts are widely used in commercial relations.

1. Introduction to smart contracts

1.1. How smart contracts work

The term “smart contract” describes computer code that automatically executes the entire agreement or parts of it. The code is stored on a blockchain-based platform. As we will see below, the code is the only announcement of an agreement between the parties or complements the traditional text contract and executes only certain provisions, such as the transfer of money by A party to B. , safety and immutability. Replication also means that as each new block is added to the blockchain, the code can in fact be executed. If the parties initiated a transaction and thus showed that the conditions are met, this will become a trigger and the code will perform some actions. If the transaction is not initiated, then the code does nothing. Most smart contracts are written in one of the programming languages ​​created specifically for this purpose (for example, Solidity).

It is necessary that the input parameters and stages of the smart contract execution are specific and objective. In other words, “if X happens, then make Y”. Therefore, smart contracts perform simple tasks, for example, automatically transferring cryptocurrency from the purse of one side to the purse of the other, if the necessary conditions are met. As the blockchain spreads and the funds invested in tokens or sent within the blockchain (on-chain) grow, smart contracts will become more complex and will be able to process complex transactions. Many developers are already creating more complex smart contracts, combining several stages of transactions in them. Nevertheless, we will have to wait many more years until the code can define subjective legal criteria, such as “do the actions of the party meet the criteria of commercially reasonable efforts” or “is it worth it to fulfill the reimbursement clause and pay compensation”.

Before the compiled smart contract is executed, it is required to pay the transaction fee for adding the contract to the blockchain. For example, in the Ethereum blockchain, smart contracts are executed in the Ethereum Virtual Machine (EVM) virtual machine, and the ether cryptocurrency commission is called gas (gas, although a more correct translation is “fuel”) [1]. The more complicated the smart contract, the more gas you need to pay. That is, gas is a kind of gateway that protects EVM from executing too complex or multiple smart contracts [2].

So far, smart contracts are best suited for the automatic execution of two types of transactions:

• payment initiated by certain events
• imposition of financial sanctions for failure to comply with objective conditions.

When the expanded contract became operational, these two types of transactions do not require the participation of people, including trusted escrow holders or representatives of the legal system. This allows to reduce the overhead costs of execution and enforcement in the conclusion of contracts.

For example, smart contracts can save you from the so-called cash gap (procure-to-pay gap). As soon as the goods arrive at the warehouse and are registered, the smart contract is able to instantly send confirmation requests. Having received them, he will immediately transfer funds from the buyer to the seller. At the same time, sellers will receive payment faster, they will not have to remind customers to pay, and buyers will save on banking transactions. All this can reduce the requirements for working capital and simplify financial operations for both parties. With regard to the mandatory execution, the smart contract can be programmed so that it closes access to assets connected via the Internet (for example, to content) until payment is received.

1.2. History reference

The term “smart contract” was invented about 20 years ago by computer science expert Nick Szabo, a cryptographer who was then a graduate student at Washington University:

Thanks to the digital revolution, new state institutions and new ways of formalizing relationships that make up these institutions became possible. I call these contracts “smart” because they are much more functional than their lifeless paper predecessors. They do not use artificial intelligence. A smart contract is a set of promises that are defined in digital form, including protocols for the parties to fulfill these promises [3].

Please note: Sabo took the word "smart" in quotes and said it was not using artificial intelligence. Smart contracts are smarter than paper contracts because they automatically execute pre-programmed steps. But they cannot be regarded as intelligent tools capable of analyzing more subjective requirements. Sabo gives a classic example of a smart contract: this is a vending machine. If the conditions of the "contract" suit the buyer (i.e., he puts the money in the machine), then the machine automatically observes the terms of the unwritten agreement and provides the purchase.

Another source of modern smart contracts is the Ricardian Contract . This idea appeared in 1996 in the work of Ian Grigg (Ian Grigg) and Gary Howland (Gary Howland), dedicated to the payment system Ricardo. Grigg presented the Ricardian contract as a bridge between text contracts and code with the following parameters:

1) a single document - a contract that the issuer offers holders;
2) on the property right of holders, managed by the issuer;
3) easily recognized by people (as well as a regular paper contract);
4) is read by programs (parsed as a database);
5) is digitally signed;
6) contains keys and server information;
7) combined with a unique and protected identifier [4].

2. Relationship with traditional textual conventions

In discussions about smart contracts, the term itself is complicated, which is used for two different paradigms.

The first is smart contracts created and deployed without binding text contracts. For example, the two parties verbally agree what business relationships they want to establish, and immediately translate the agreement into executable code. Let's call this “purely software smart contracts” (code-only smart contracts).

The second is smart contracts that are used as a means to implement specific provisions of a traditional text contract, the text of which refers to the use of a smart contract to implement these provisions. Let's call this ancillary smart contracts.

3. Are smart contracts binding?

In the United States there is no federal treaty law. How to interpret contracts and whether to enforce them is determined at the level of state legislation. Thus, while key principles apply throughout the state, and the National Assembly of Commissioners on Uniform State Laws calls for harmonizing state laws, any conclusions about smart contracts should take into account the fact that different points of view may prevail in different states.

The discussion about the obligation to execute smart contracts should begin with a fundamental separation of the concepts of “agreement” and “contract”. States generally agree that the two parties can enter into agreements, but the concept of "contract" means that the agreement is legally binding and must be enforced in court. [5] To determine compliance, state courts traditionally assess whether the requirements of the proposal, acceptance and consideration are satisfied. These basic requirements can certainly be met with ancillary smart contracts. For example, an insurance company creates a flight insurance product that automatically pays the insured person insurance if the flight is delayed for more than two hours [6]. Key conditions like the procedure for calculating the delay are prescribed in advance in the text contract, while the auxiliary smart contract processes the subject of the agreement (this is insurance payment) and its execution (automatic payment as a result of the checked delay). Thus, the insurer offers to insure flights, and the insured person accepts the offer by paying an insurance premium.

Today, certain contracts must be submitted in writing. Additional formalities may also be required, for example, under the Uniform Commercial Code (UCC) [7] or state laws to combat fraud. However, agreements do not always have to be written in order for them to be enforced [8]. Consequently, many purely software smart contracts will be applied in accordance with the laws governing contractual relationships. In this sense, the example of Sabo with a vending machine is instructive: although the buyer has many implied rights, the contract is drawn up without significant prescribed conditions, except for displaying the price of each product. Thus, the fact that the agreement is reflected only in the code, as in the case of code-only smart contracts, does not particularly impede the formation of a contract outside the framework designated by the UCC or laws to combat fraud. A number of laws and legal structures have long taken into account the role of information technology in drafting contracts.

For example, the Uniform Electronic Transactions Act (UETA), adopted in 1999 and taken as the basis in 47 states, reads as follows. Electronic records, including those created by computer programs, as well as digital signatures using public key encryption have the same legal force as text records (with certain restrictions) [9]. UETA even recognizes the legitimacy of electronic agents, which are defined as “computer programs, electronic or other automated means independently used to initiate an action or response to electronic records or to all or part of an activity without control or human participation” [10]. According to UETA, an electronic agent “is able, within the parameters of its program, to initiate actions, respond to records, or interact with other parties or their electronic agents, after it has been activated by one of the parties, without additional attention on that side” [11]. Perhaps this is a preliminary recognition of smart contracts.

Similarly, the Federal Electronic Signatures Recording Act (E-Sign Act) not only recognizes the legality of electronic signatures and electronic records in commercial relations between states, but also states that a contract (or other transaction related record) “does not may be deprived of legal force, legality or compulsory execution only because its design, creation or delivery implies the action of one or several electronic agents, if the action of any such electronic agent is legally GSI a person associated obligations "[12]. The term “electronic agent” means a computer program, electronic or other automated means, independently used to initiate an action or response to electronic records or to all or part of an activity without control or human participation [13].

Understanding the legal framework is important to strengthen the binding nature of smart contracts, but their use in the future may not be based on laws created before the era of the blockchain technology. Arizona and Nevada have already changed local versions of UETA to explicitly use the blockchain and smart contracts [14]. Note: the two states have taken seriously different definitions of critical concepts. Therefore, it can be assumed that the more states follow their example and change local versions of UETA, the stronger will be the need to adopt uniform definitions reflecting the development of the blockchain and smart contracts.

4. Challenges to the widespread use of smart contracts

Given the existing legal framework for the recognition of electronic contracts, it can be noted that it is highly likely that today the courts will begin to recognize the legitimacy of the code executing the provisions of smart contracts (which we have called supporting smart contracts). There is also a precedent suggesting that a smart contract, which consists only of code, can receive the same legal recognition. Therefore, the difficulties in the way of widespread dissemination of smart contracts are associated not so much with legislative restrictions, as with the contradictions between the way the smart contract code operates and the way the parties do business. We identified four major difficulties.

4.1. How far from technology can parties negotiate, design, and adjust smart contracts?

The main obstacle to the widespread adoption of smart contracts: the parties will have to rely on trusted technical experts who will implement the agreements in the code or confirm the accuracy of the code written by a third party. If you come up with the analogy with hiring a lawyer to explain legal terms in a plain text contract, then it is incorrect. People without a legal education are able to understand simple, short agreements, and numerous provisions of longer agreements, especially those that determine the conditions for doing business. But if you do not know how to program, you won’t understand even the most primitive smart contract at all. Therefore, the importance of an expert who can explain what is “said” in the code is much higher.

To some extent, the inability of the parties to understand the code of the smart contract does not prevent them from entering into auxiliary software agreements. The fact is that you can create and use a lot of basic functions and text patterns, denoting which parameters to enter and how they will be executed. Suppose a simple function of a smart contract deducts from the wallet of one of the parties a late payment fee if no payment has been received by the appointed date. However, the party may need to confirm that the program code actually performs what is defined in the text, and that there are no additional conditions and parameters, especially when the smart contract template does not provide for liability for the inaccuracy of the program code. To analyze the code, you will have to involve a third party, an expert in programming.

If there is no template and you need to develop a code from scratch, the parties will need to explain the purpose of the agreement to the programmer. It is inexpedient to simply give a copy of a legal document, since the programmer will have to understand it. Therefore, parties relying on auxiliary smart contracts will need to compile and show the programmer a list of conditions that the smart contract must fulfill.

Also, parties may want written confirmation from the programmer that the code works as intended. As a result, to implement the requirements that are not included in the template, the parties will need to enter into a written agreement with the programmer of the smart contracts; this is in addition to the contract that the parties may conclude with the provider of electronic data interchange services.

Insurance companies can also develop methods to protect the parties from the risks of improperly performing the smart contract functions defined in the text agreement. Although the parties may analyze the code (or assign it to a third party), insurance will provide additional protection in case the parties do not notice errors when analyzing the code. In addition, the parties will be psychologically more comfortable if the insurance company checks the code itself before insuring them.

Software-only smart contracts used in the relationship between companies and consumers can bring additional problems. Courts are reluctant to enforce agreements if consumers have not received an adequate description of the terms of agreements, and may be skeptical about the idea of ​​enforcing smart contracts, if consumers are not provided with a basic text agreement that includes all definitions [15].

Finally, as the legality or validity of smart contracts will increasingly be recognized legally, courts may need a system of nominated experts who will help to understand the computer code. Today, the parties resort to the help of their experts when technical issues are at the center of the discussion. Although federal and state courts have the right to nominate their own experts, they rarely use them [16]. This approach may require changes if the number of standard proceedings around the interpretation of the code of smart contracts increases.

4.2. Smart contracts and dependence on off-chain resources

It is often assumed that a smart contract will receive information or parameters from non-blockchain resources, from so-called off-chain resources. For example, a smart crop insurance contract is programmed so that insurance will be paid if the air temperature falls below 0 degrees Celsius. The smart contract will receive information about the temperature from an external source. There are two problems here.

First, smart contracts cannot themselves take data from off-chain-resources: the transfer of information must initiate the source.

Secondly, the code is replicated to a set of nodes of the blockchain network, and if the data is flowing in a constant stream, then the nodes will receive different information. For example, information came to node-1 that the temperature was –0.5 degrees, and to node-2 that the temperature was 0 degrees. To validate a transaction, there is a need for consensus between the nodes: inconsistency in the data may cause the condition of the smart contract to be considered unfulfilled.
The parties to the agreement will be able to solve this problem with the help of the so-called oracles - trusted third parties, who receive information from external systems and transfer it to the blockchain at predetermined points on a schedule. In the above case, the oracle will monitor the temperature, determine the onset of frost and send this information to the smart contract.

Oracles are a great way to access off-chain-resources, but using them means involving a third party. We will have to conclude with her a separate contract for the supply of data, only to implement the target smart contract. As a result, the benefits of decentralizing smart contracts are declining. Also, the oracle is a potential point of failure. For example, if an oracle fails, it will provide erroneous data or stop working altogether. These risks need to be considered before the widespread use of smart contracts.

4.3. What is the "final" agreement of the parties?

Analyzing traditional text contracts, the courts examine the final written document adopted by the parties to determine whether they are honoring their obligations or violating. The courts have long stressed that the final agreement reflects the mutual intention of the parties.

In the case of software-only smart contracts, the executable code — and the result of its work — is the only objective evidence of conditions agreed by the parties. Probably, in such cases, electronic correspondence between the parties and oral discussions on what functions the “must” carry out the smart contract will give the program code its role of defining the parties' intentions.

With regard to subsidiary smart contracts, the courts can view the text and code as a single agreement. The situation is complicated when the traditional text convention and the code do not match. For example, in the example of insurance of crops, the text states that insurance is paid if the air temperature falls below 0 degrees, and in a smart contract the payment occurs when the air temperature is equal to or below 0 degrees. The text agreement does not regulate the priority of the code or text in case of inconsistencies, and the courts will need to decide (perhaps in each case individually) whether to consider the code as a mutually agreed amendment to the text agreement - or should the text prevail? In a sense, the analysis of this situation should not differ from the analysis of the situation when the provisions of the basic agreement do not coincide with what is reflected in the annexes or the schedule of work. The fact that in one case we are talking about a conflict between text and program code, and in the other between two texts, should not be decisive; however, the courts may decide otherwise.

One of the solutions is to use a text contract, when the parameters that trigger the execution of a smart contract are not only written in the text, but also included in the smart contract itself. In the example with crops, the condition “below 0 degrees” can be written down with text and specified as a parameter in the smart contract, thereby eliminating the possibility of inconsistency.

4.4. Smart Contract Automation

One of the main features of smart contracts is their ability to automatically and tirelessly execute transactions without human intervention. However, the automation and the fact that smart contracts cannot be changed or interrupted only if the parties do not foresee such opportunities during the creation are one of the main difficulties preventing the wide distribution of smart contracts.

For example, in a normal text contract, one of the parties may forgive the violation of the other party and not force it to pay a fine. Suppose a valuable customer was late for one month’s payment, and the vendor decided that a long-term business relationship is more important than any right to terminate a contract or late payment fee. But if a smart contract is involved in the history, then the vendor physically cannot situationally refuse to enforce the terms of the contract. Delay of payment will lead to automatic transfer of interest from the client’s account or to restriction of access to the software or device, if provided for in the smart contract. Automatic execution does not match the way many companies do business.

Similarly, in a textual contractual relationship, the parties may situationally agree that partial execution of the contract is considered complete execution. , — , , . , -, .

4.5. -

-, . , , , . - . - , , . - , , , .

-. , , , ; , , . ( ), . . , . , , . - .

-, . - -, , -, , .

4.6. -

, -, , . , - . , , , . — . , . - : , . - , - . , - .

, - , , , -. , - , if/then. - , , -.

4.7. - ?

, - , , . , . , , , . . , , , , -. , .

, - - , , -, , . ( - «» ) , . , , -, - , , . . , - , , .

4.8.

- , : , . , . «», , — . , , . , 2017- 31 [17]. , . Parity, - . , -, , , , — -.

4.9.

, , - — , . , - , . , -. , . , , , -. , - ( ), , .

5.

-, . - - , .

• , , — . , - , . , - . , , - ; , , .
• -, , , -, , .
• , , , , .
• .
• , , , .
• , - , . , , . . , .

6. -

- Amara's Law — , , . , . - , , , . - , . - , .

1. . What is the «Gas» in Ethereum? Cryptocompare, 18 2016.
2. Ibid.
3. Nick Szabo. Smart Contracts: Building Blocks for Digital Market . 1996.
4. Ian Grigg. The Ricardian Contract .
5. ., ., « () », 1, , 1981. . , , , - .
6. , AXA , .
7. C. UCC § 2-201.
8. , . Lumhoo v. Home Depot USA, Inc. 229 F. Supp. 2d 121, 160 (EDNY 2002). , , , : , .
9. C. Uniform Electronic Transactions Act (Unif. Law Comm'n 1999). -, , .
10. Ibid. § 2(6).
11. Ibid. § 2 cmt. five.
12. 15 USC § 7001(h).
13. 15 USC § 7006(3).
14. C. 2017 Ariz. HB 2417 44-7061 and Nev. Rev. Stat. Ann. § 719.090.
15. C. Nicosia v. Amazon.com, Inc. 834 F.3d 220 (2d Cir. 2016) ( , Amazon ).
16. C. Charles Alan Wright & Arthur R. Miller. Federal Practice and Procedure, Section 6304 (3d ed. Supp. 2011) (« 706 . , - , »), Stephanie Domitrovich, Mara L. Merino & James T. Richardson. State Trial Judge Use of Court Appointed Experts: Survey Results and Comparisons, 50 Jurimetrics J. 371, 373—374. 2010.
17. . Haseeb Qureshi. A Hacker Stole $31M of Ether—How it Happened, and What it Means for Ethereum . FreeCodeCamp. 20 2017.