Smart Contract VS Traditional Contract - Defining Legal Elements
One of the difficulties in discussing smart contracts is that the term is used to capture two very different paradigms. The first involves smart contracts that are not created and implemented on the basis of a written, enforceable contract. For example, two parties reach a verbal understanding regarding the business relationship they wish to formalise and then translate this understanding directly into executable code. We refer to these below as “code-only smart contracts”. The second paradigm involves the use of smart contracts as vehicles to stipulate certain provisions of a traditional written contract, where the text itself refers to the use of the smart contract to stipulate certain provisions. We refer to these as “ancillary smart contracts”.
Are smart contracts enforceable?
A discussion of the enforceability of smart contracts must begin with the fundamental distinction between an understanding and a “contract”. States generally recognise that, while two parties may reach a variety of “understandings”, a contract means that the agreement is binding and enforceable in court. To determine enforceability, state courts traditionally examine whether the common law requirements of offer, acceptance and consideration are met. These basic requirements can certainly be satisfied through ancillary smart contracts. For example, an insurer could develop a flight insurance product that automatically provides the insured with a payment if the flight is delayed by more than two hours. Key terms, such as delineating how the delay is calculated, can be set out in a written contract, with the actual formation of the contract (payment of the premium) and its execution (automatic payment upon a verifiable delay) handled through an ancillary smart contract. Here, the insurer has made a definite offer for a flight insurance product which is accepted by the insured upon payment of the premium as consideration.
Thus, many code-only smart contracts will also be enforceable under state contract laws. Szabo's famous vending machine example is useful in this regard. There, while the buyer has many implied rights, a contract was formed without any other written provision beyond the display of the price for each product. Thus, the fact that an agreement is expressed only in code, as is the case with code-only smart contracts, presents no special barrier to contract formation beyond the barriers imposed by the UCC and statutes of frauds. Indeed, a variety of laws and legal constructs have long taken into account the role of information technology in contract formation.
Although understanding the current legal framework is important for assessing the enforceability of smart contracts today, those who use smart contracts in the future may not need to rely on laws that predate the development of blockchain technology. For instance, Arizona and Nevada have already amended their state versions of the UETA to explicitly include blockchains and smart contracts. The fact that these states have adopted substantially different definitions of those fundamental terms suggests that, as more states follow suit, there may be growing pressure to adopt unified definitions so as to reflect developments in blockchain and smart contracts.
Challenges relating to the widespread adoption of smart contracts
Given the existing legal frameworks recognising electronic contracts, it is highly likely that a court today would recognise the validity of code executing the provisions of a smart contract - what we have classified as ancillary smart contracts. There is also precedent suggesting that a code-only smart contract could enjoy similar legal protection. The challenge of widespread adoption of smart contracts may therefore have less to do with the limits of the law than with potential clashes between how smart contract code operates and how parties conduct business. Below are some of these challenges:
How can non-technical parties negotiate, draft and adjudicate smart contracts?
A key challenge in the widespread adoption of smart contracts is that parties will need to rely on a trusted technical expert, either to capture the parties' agreement in code or to confirm that code written by a third party is correct. While some compare this to hiring a lawyer to explain the “legalese” of a traditional written contract, the analogy is flawed. Ordinarily, non-lawyers can understand simple, short agreements, as well as many provisions of longer agreements, particularly those setting out general terms of business. But a non-programmer would be completely at a loss to understand even the most basic smart contract, and is therefore far more dependent on an expert to explain what the contract “says”.
To a certain extent, the inability of contracting parties to understand smart contract code will not be an obstacle to entering into ancillary code agreements. This is because, for many basic functions, text templates can be created and used to indicate what parameters must be entered and how those parameters will be executed. For example, suppose a simple smart contract function withdraws a late penalty from a counterparty's wallet if a defined payment is not received by a specified date. The text template could ask the parties to enter the expected payment amount, the due date, and the late penalty amount. However, a party may wish to confirm that the underlying code will actually perform the functions specified in the text and that there are no additional conditions or parameters, particularly where the template disclaims any liability arising from the accuracy of the underlying code. This review will require a trusted third party with programming experience.
In cases where no such templates exist and new code must be developed, the parties will need to communicate the intent of their agreement to a programmer. Simply handing that programmer a copy of the legal agreement would be inefficient, as it would require the programmer to attempt to decipher a legal document. Therefore, parties relying on ancillary smart contracts may need to draft a separate "term sheet" of the functionality the smart contract should perform, which can be provided to the programmer.
Parties may also wish to obtain written representations from the programmer to the effect that the code functions as intended. The net result is that, for bespoke arrangements not based on an existing template, the parties may need to enter into a written agreement with the smart contract programmer, unlike the agreement the parties might enter into with an Electronic Data Interchange (EDI) service provider today.
Insurance companies could also create policies to protect contracting parties against the risk that smart contract code fails to perform the functions specified in the text of an agreement. While the parties would also want to review (or have third parties review) the code, insurance could provide additional protection, given that the parties might overlook errors when reviewing the code. Parties would also take comfort from the fact that the insurance company has likely conducted its own code audit before agreeing to insure the code.
Code-only smart contracts used for business-to-consumer transactions could raise an additional set of issues that will need to be addressed. Courts are reluctant to enforce agreements where the consumer has not received adequate notice of the terms of the agreement, and may hesitate to enforce a smart contract where the consumer has also not been provided with an agreement text setting out the complete terms.
Finally, as the validity or performance of smart contracts becomes increasingly subject to judicial determination, courts may need a system of court-appointed experts to help them decipher the meaning and intent of the code. Today, parties commonly use their own experts when technical issues are central to a dispute. While both federal courts and many state courts have the authority to appoint their own experts, they rarely exercise that authority. This approach may need to change should the number of standard contractual disputes focused on the interpretation of smart contract code increase.
What is the "final" agreement between the parties?
When examining traditional written contracts, courts will look to the final, written document agreed upon by the parties to determine whether the parties are complying with it or breaching it. Courts have long emphasised that this final agreement represents the mutual intent of the parties - the "meeting of the minds".
In the case of code-only smart contracts, the code that is executed - and the outcome it produces - represents the sole objective evidence of the terms agreed by the parties. In such cases, email exchanges between the parties regarding what functions the smart contract "should" perform, or oral discussions to that effect, may crystallise into the final lines of code as the determinative manifestation of the parties' intent.
With regard to ancillary smart contracts, a court would likely view the text and the code as a single, unified agreement. The issue becomes complicated where the traditional written agreement and the code do not align. In the crop insurance example described above, suppose the text of an agreement specifies that insurance will be paid if the temperature falls below 32 degrees, while the smart contract code triggers payment if the temperature is equal to or below 32 degrees. Assuming the written agreement does not specify whether the text or the code governs in the event of a discrepancy, courts will need to determine - perhaps on a case-by-case basis - whether the code should be treated as a mutually agreed amendment to the written agreement, or whether the text of the agreement should prevail. In some respects, the analysis should not differ from a case where the provisions of a master agreement differ from what is reflected in an attached schedule or exhibit. The fact that here the conflict would be between written text and computer code, rather than between two written documents, should not be determinative, but courts may take a different view.
One solution would be for the parties to use a written contract in which the parameters triggering the execution of the smart contract are not merely visible in the text, but are actually built into the smart contract itself. In our example, "less than 32 degrees" would not simply appear in the written text but would also create the parameter within the smart contract, thereby reducing the chances of any inconsistency.
The automatic nature of smart contracts
One of the key attributes of smart contracts is their ability to execute transactions automatically and continuously, without the need for human intervention. However, this automation, together with the fact that smart contracts cannot be easily modified or terminated unless the parties build such capabilities in when creating the smart contract, presents some of the greatest challenges to the widespread adoption of smart contracts.
For instance, with traditional written contracts, a party can easily justify a breach simply by not activating the available penalties. If a loyal client is a month late with payment, the seller may decide, in real time, that preserving the long-term business relationship is more important than any right of unilateral termination or late payment fee that may be available. However, had this relationship been reduced to a smart contract, there would probably be no option not to enforce the agreement on an ad-hoc basis. A late payment would result in a late fee being automatically deducted from the client's account, or in the suspension of the client's access to a software program or an internet-connected device, if that is how the smart contract was programmed. Consequently, the automatic execution offered by smart contracts may not align with the way many companies operate in the real world.
Similarly, in a contractual relationship based on written texts, a party may be willing, on an ad-hoc basis, to treat partial performance as full performance. This may be due to an interest in preserving a long-term relationship or because a party determines that partial performance is preferable to non-performance. Here again, the objectivity required for smart contract code may not reflect the realities of how contracting parties actually interact.
Modification and termination of smart contracts
At present, there is no straightforward way to modify a smart contract, which creates certain challenges for contracting parties. For example, in a traditional written contract, if the parties have mutually agreed to modify the parameters of their business agreement, or if there is a change in the law, the parties can quickly draft an amendment addressing that change or simply alter the course of performance. Smart contracts do not currently offer this kind of flexibility. Indeed, given that blockchains are immutable, modifying a smart contract is far more complicated than modifying standard software code that is not on a blockchain. As a result, modifying a smart contract can generate higher transaction costs than modifying a written contract and increases the margin of error, in the sense that the parties may not accurately reflect the changes they wish to make.
There are similar challenges when it comes to terminating a smart contract. Suppose a party discovers an error in an agreement that grants the counterparty more rights than intended, or concludes that performing its stated obligations will be far more costly than anticipated. In a written contract, a party may engage in - or threaten - what is known as an "efficient breach", that is, knowingly breaching a contract and paying the resulting damages if it determines that the cost of performance exceeds the damages it would owe. Moreover, by ceasing performance or threatening to do so, a party can bring the counterparty back to the table to negotiate an amicable resolution. Smart contracts do not yet offer similar mutual remedies.
Projects are currently underway to create smart contracts that can be terminated at any time and modified more easily. Although, in certain respects, this is antithetical to the immutable and automated nature of smart contracts, it reflects the fact that smart contracts will only be accepted for use in commerce if they reflect the business reality of how contracting parties actually behave.
Conclusions
Although considered not yet mature enough to be the subject of sector-specific regulation, the legal implications of smart contracts are of considerable interest and are currently being assessed, along with the exploration of situations in which they can be used. Smart contracts have the capacity to reproduce elements of traditional legal contracts, expressing the parties' agreement of will in computer code rather than legal language, and offer the advantage of reduced costs of contracting, performance and compliance. They therefore allow participants, regardless of their legal form, to create digital agreements with the certainty that these will be honoured across all databases or accounts of the parties involved.