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 critical 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 money transfer by party A to party B. The code itself replicates to several blockchain nodes, which means it takes advantage of the blockchain: this is security , 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.

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 determine the subjective legal criteria,

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), 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, which 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, It does not specifically impede the formation of a contract outside the framework designated by the UCC or anti-fraud laws. 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]. As UETA, the electronic agent says“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 the additional attention of that party” [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 says 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 below0 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 in payment will result in automatic transfer of interest from the client’s account or 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. For example, for the sake of preserving all the same long-term relationships - or because the parties decided that it was better to execute the contract in part rather than not fulfill it at all. And the objectivity required in the case of a smart contract may not correspond to the realities of interaction between the parties.

4.5. Change and break smart contracts

At the moment there is no easy way to change a smart contract, which creates difficulties. For example, in the case of a text contract, if the parties mutually agreed to the new terms of the transaction or if the laws changed, then the parties can quickly agree on changes in the contract or correct their behavior. Smart contracts do not provide the same flexibility. Modifying an immutable smart contract is much more complicated than the code of ordinary software, which is not built on the basis of the blockchain. As a result, a change in a smart contract can lead to much higher transaction costs than rewriting a text contract, and will increase the likelihood that the desired changes will not be accurately reflected in the code.

Similar difficulties are associated with breaking a smart contract. Suppose one of the parties discovered an error in the agreement, giving the other party more rights than they agreed; or one of the parties came to the conclusion that fulfilling obligations is much more expensive than expected. In the case of a text contract, a party may resort to a so-called effective violation (or threat to them), that is, deliberately violate the agreement and pay damages if it is cheaper than fulfilling contractual obligations. Moreover, by ceasing to comply with the terms of the contract or by threatening to do so, you can sit down the other side at the negotiating table and discuss the peaceful settlement of the dispute. Smart contracts generally do not imply such options.

We are developing projects of smart contracts that are easier to change and can be broken at any time. In a sense, this is unethical with respect to the immutable and automated nature of smart contracts, but they will benefit from innovations that reflect business realities, the way participants in a contract act.

4.6. Objectivity and limits of implementation in smart contracts of the desired ambiguity

The objectivity and automation required for smart contracts may conflict with the actual manner in which the parties negotiate agreements. During the negotiations, the parties secretly analyze expenses and incomes and understand that at some point the return from thinking and thinking about possible problems decreases. The parties may decide that it is enough to spend time on negotiations and funds for lawyers, or decide that instead of discussing the problems, it is better to start profitable activities within the framework of the contract. If an unforeseen event occurs, then a solution will be worked out. Similarly, the parties may intentionally leave the agreement ambiguous in order to be able to insist on interpreting the situation in their own favor in the future. Implementing such an approach using smart contracts is more difficult: computer code requires precision, which is not in the negotiations on text contracts. Smart contract is not able to include ambiguous conditions, is not able to leave unresolved some scenarios. As a result, it may turn out that the transaction costs of negotiating complex smart contracts will be comparable to the costs of regular text contracts.

Those who implement smart contracts in a certain area will take time to figure out which provisions are sufficiently objective to be executed in a smart contract. As already mentioned, today the majority of smart contracts perform relatively simple tasks, in which the parameters of if / then expressions are clearly defined. As the smart contracts become more complex, the parties may not agree whether it is possible to reflect a certain position objectively, as required by the smart contract.

4.7. Do smart contracts guarantee payment?

It is often said that smart contracts can automate payment without reminders and other efforts, without the need to go to court to enforce payment. This is true for simple cases, but in more complex commercial relationships it turns out to be not quite so. The fact is that money constantly passes through the accounts of organizations that have concluded a contract. No one is booking the full amount for payment under the terms of a long-term contract. For example, a person who receives a loan is unlikely to keep the entire amount on a wallet tied to a smart contract. Rather, the borrower will put money into the business, allocating funds for payments as needed.

If a party that, according to the terms of the smart contract, has to pay some amount, did not manage to timely put the due funds on the wallet, then the smart contract, turning to the wallet for payment, will face a shortage of funds. The introduction of an additional level (such as checking a smart contract with other wallets or the mechanism of “self-financing” of the wallet from other sources) will not solve the problem if the required amount is not found in other wallets and sources too. The parties may state in the text contract a requirement that there must always be some amount on the wallet tied to the smart contract, but such a decision will simply give one of the parties a legally stronger argument if a dispute arises. This will not make the payment fully automatic. Consequently, although smart contracts allow you to pay more efficiently, they do not guarantee that

4.8. Risk distribution in attacks and failures

Smart contracts add additional risks that are not found in most of the agreements recorded in the text: contract hacking, unintentional software errors in the code or protocol. Given the relative safety of the blockchain, these concepts are closely interrelated. Most of the “hacks” associated with the blockchain are actually exploits of unintended errors in the code. As in the case of many bugs, these errors are not glaring, but after use they become obvious. For example, in 2017, the attacker pulled out $ 31 million from several wallets with multi-signatures [17]. Wallets with multi-signatures are safer because they require more than one private key to access. However, the attacker intercepted the flow of data in the code of the company Parity, reinitialized the smart contract and made himself the sole owner of the multi-signature wallets. Therefore, parties to a smart contract need to understand how the risk and responsibility for unintentional errors in the code and their use by attackers are shared between the parties and, possibly, the third party developers or insurers of the smart contract.

4.9. Regulatory legislation and territorial jurisdiction

One of the main promises of the blockchain, and therefore of smart contracts, is the creation of reliable, decentralized global platforms. But global implementation means that parties can use smart contracts under a much wider range of jurisdictions than text contracts. Therefore, governing legislation and territorial jurisdiction should best protect the conditions proposed for inclusion in a smart contract. Provisions of the governing law determine the courts of which jurisdiction will adjudicate disputes. If laws and territorial jurisdiction are not determined, the claimant may be relatively unlimited in choosing where to file a complaint or in a dispute as to which substantive law should be applied in view of a wide range of jurisdictions under which a smart contract can be used. Considering,

5. Best practices

We are only at the beginning of the introduction of smart contracts, and best practices have not yet been developed. However, this checklist will help developers create effective smart contracts and advise companies planning to use them.

• Now the parties entering into any contractual arrangements are best to adhere to a hybrid approach - a combination of text and code. There are strong arguments in favor of the fact that only software smart contracts must be enforceable, at least within the framework of local laws in the United States. However, until there is more clarity about their legality and binding nature, only software smart contracts should be used only for simple relationships. The parties will need textual versions of the agreements in order to read the discussed conditions and enter the conditions that the smart contract does not take into account; you will need to have at hand a document that will be accepted in court.
• In a hybrid contract, the text should clearly identify the smart contract code with which it is associated, and the parties should see all the variables passed to the smart contract, their definitions, and transactional events that trigger the execution of the code.
• Relying in receiving third-party data on oracles, the parties must decide what will happen if an oracle cannot transmit data, provides erroneous information, or simply stops working.
• The parties should understand the distribution of risks in case of errors in the code.
• The textual agreement accompanying the code should determine the governing law and territorial jurisdiction, as well as the priority of the code and text in case of conflicts of their contents.
• The text agreement should include messages from both parties that they have analyzed the code of the smart contract and that the code reflects the conditions described in the text agreement. Although this confirmation will not force the parties to actually analyze the code, it will help the other side to defend itself against the charges that the code has not been analyzed at all. Parties can also insure against the risk of errors in the code. As noted earlier, the parties may involve outside experts to analyze the code.

6. The future of smart contracts

Today, smart contracts are a prototype example of Amara's Law, a concept formulated by Roy Amara, an informatics specialist at Stanford University. This concept states that we tend to overestimate new technologies in the short term and underestimate them in the long term. Although smart contracts still need to evolve before they are widely used in complex commercial relationships, they still affect the revolution in the reward and incentive structure that will shape the shape of contracts in the future. When considering smart contracts, it is important not just to think about how to transfer existing concepts and structures to this new technology. Rather, the genuine revolution of smart contracts will be triggered by completely new paradigms that we have not yet predicted.

Footnotes

1. See What is the "Gas" in Ethereum? Cryptocompare, November 18, 2016.
2. Ibid.
3. Nick Szabo. Smart Contracts: Building Blocks for the Digital Market . 1996.
4. Ian Grigg. The Ricardian Contract .
5. See, for example, “The reformulation (second) of contracts”, part 1, American Law Institute, 1981. In the United States, state legislatures are usually responsible for contractual law. Although in this article we look at the basic principles of contract law, which are characteristic of most states, it should be noted that differences in legislation can affect the binding nature of smart contracts in certain states.
6. At least one company, AXA , is now offering such a product.
7. See UCC § 2-201.
8. For example, see Lumhoo v. Home Depot USA, Inc. 229 F. Supp. 2d 121, 160 (EDNY 2002). It is believed that the plaintiffs provided sufficient evidence to confirm that the parties entered into a verbal agreement that said: the employer pays for overtime for any work that exceeds eight hours a day.
9. See Uniform Electronic Transactions Act (Unif. Law Comm'n 1999). New York, Illinois and Washington have their own laws governing the validity of electronic transactions.
10. Ibid. § 2 (6).
11. Ibid. § 2 cmt. five.
12. 15 USC § 7001 (h).
13. 15 USC § 7006 (3).
14. See 2017 Ariz. HB 2417 44-7061 and Nev. Rev. Stat. Ann. § 719.090
15. See Nicosia v. Amazon.com, Inc. 834 F.3d 220 (2d Cir. 2016) (cancellation of the decision of the district court on refusal to satisfy the claim and logical doubt that Amazon has provided the consumer with a reasonable notice of compulsory arbitration).
16. See Charles Alan Wright & Arthur R. Miller. Federal Practice and Procedure, Section 6304 (3d ed. Supp. 2011) (“Actually, rule 706 is rarely used. This is at least in part due to the fact that the appointment of an expert witness increases the burden on the judge, increases the costs of the parties and prevents adversary control over the submission evidence ”), as well as Stephanie Domitrovich, Mara L. Merino & James T. Richardson. State Judicial Court Appointments Appointment Experts: Survey Results and Comparisons, 50 Jurimetrics J. 371, 373-374. 2010
17. See Haseeb Qureshi. A Hacker Stole $ 31M of Ether — Meat for Ethereum . FreeCodeCamp. July 20, 2017.