BitLaw

What is a Smart Contract

An agreement is generally a "meeting of the minds" (to use standard legal terminology), where two or more entities come to a common understanding, in which each party performs some action, provides some benefit, or incurs some detriment in order to complete the agreement. The actual legal definition of what is required to form an enforceable contract will vary from country to country, but at a high level this type of agreement will typically create an enforceable contract. If an enforceable contract has been created, the legal system will get involved when one of the parties breaches that contract.

As for what constitutes a "smart" contract, one author (in the Georgetown Law Review) defined smart contracts "as agreements wherein execution is automated, usually by computers." A smart contract, for instance, can be formed through a human interacting with a vending machine. The human purchaser makes a selection by interacting with the vending machine, and then provides payment for the selected goods. The computer inside the machine identifies the selection, receives the payment, verifies that the payment is sufficient for the selection, and then vends the desired product to complete the contract.

The automated execution in a smart contract can relate to the entire agreement, or to just part of the agreement. In the case of the vending machine, the automated portion does not take over execution of the agreement until after the user has input a selection and provided payment to the machine.

A more complicated smart contract that relates to the entire agreement may take the form of a lending agreement. One party may wish to borrow three Bitcoins and promises to return the Bitcoins plus 20% interest in one year. Computer code can be programmed to execute this agreement. The code itself can receive the Bitcoins from the lender, and then distribute the Bitcoins to the borrower. At the end of the year, the borrower will send 3.6 Bitcoins back to the computer code, which then returns the original three Bitcoins, plus 20% interest, to the lender. The computer code could even acquire control over a digital asset of the borrower during the original transaction to act as collateral. If the borrower does not return the 3.6 Bitcoins at the end of the year, the computer code could then transfer the collateral at that time to the lender. In this example, the smart contract code needs to have the ability to receive, hold, and transfer digital assets such as cryptocurrencies. Blockchains, such as the Ethereum blockchain, have been written to allow exactly this type of scenario.

Smart contracts are usually stored as computer code on a blockchain. Since all of the data on the blockchain (on most blockchains) is viewable by the public, any user is able to examine the code that implements the smart contract. This usually is a benefit to the strength of smart contracts because participants in the contract can fully understand the agreement and how it will be executed on the blockchain. Provably fair gambling contracts, such as sports betting contracts, can be examined by betters so that they know how winners are calculated and how odds are paid out. This public accessibility also means in that bugs can be easily discovered through a careful review of the code by interested parties. However, because contracts that have been saved in the blockchain are unchangeable, it can be difficult or impossible to fix any bugs that are discovered, and public knowledge of these bugs can lead to them being exploited by bad actors.

A Trustless Smart Contract

In most cases, a discussion of "smart contracts" focuses on automated agreements that are implemented, at least in part, through programming operating on a blockchain. Thus, although the broadest definition of a smart contract will include operation of a vending machine, vending machine smart contracts are less interesting because they rely so heavily on trust. The concept of trust means that an individual will need to have knowledge about a machine before they are willing to engage into a smart contract with that machine. For example, a person wishing to purchase a new iPhone from a vending machine may be willing to do so if they approach this machine:

The user is physically present at the machine, can confirm that the machine appears to be operating correctly, can see the iPhone behind the glass, will recognize the brand name "Best Buy" and therefore will know the party on the other side of this transaction, and can conclude that it would be rationale to provide a $1,000 credit card payment to this machine in the hopes of receiving a new iPhone. Even if the transaction fails, the user trusts that there will a recourse to correct this problem, either by complaining at a local Best Buy store, or by asking their credit card company to reverse any charges made because of an incomplete transaction. Each of these factors effectively establishes the trust that the user needs to complete this transaction.

In contrast, a user approaching this machine is much less likely to enter into the same transaction:

The user in this case is also present at the machine. Even if the machine indicated that an iPhone would be vended on the insertion of $1,000 of coinage, the user is much less likely to trust this machine and therefore less likely to enter into this smart contract. The user may recognize the DyDo brand as a good, reliable brand. However, the user will see that the machine is old, may not be powered on, and does not appear to contain the desired iPhone. Even if the machine is working appropriately, the user may wonder whether the "intelligence" in the machine even has the ability to accept $1,000 in payment.

Smart contracts that exist on the blockchain are considered "trustless" because the type of trust described above is not required. The code that defines the smart contract is public, as all data on the blockchain is public. Thus, a lender that wants to enter into the lending smart contract described above can examine the underlying code and determine that it will function properly. The operation of the blockchain is decentralized, which means that there is no fear that the failure of a computer (or even the failure of multiple computers) will stop the performance of the smart contract. The lending user does not need to trust, or even be able to identify, the other side of the loan transaction, as the smart contract will be performed according to its terms as long as the lender performs their side of the transaction.

How the Ethereum Blockchain Aids Smart Contracts

There are many blockchains in existence. While the Bitcoin blockchain is the most well-known, it is the Ethereum blockchain that is most commonly used for smart contracts. Like the Bitcoin blockchain, Ethereum has its own digital currency (known as Ether). Ethereum uses a slightly more complex system to manage accounts and balances in the account, but Ether transactions nonetheless look very similar to Bitcoin transactions. But unlike the Bitcoin blockchain, Ethereum was designed from the beginning with the ability to execute complex scripts (programming code) that can be embedded into the blockchain. In other words, instead of just holding data, the blockchain contains code that can perform calculations, store data, and change the ownership of Ether.

Smart contracts are generally written in a high-level programming language and then compiled down to a bytecode (such as the Ethereum Virtual Machine, or EVM, bytecode) and then stored on the blockchain in binary code. Interaction with a contract is made through a public ABI (similar to an API but on the binary level). Smart contracts can have both short-term memory and long-term storage to hold data related to the contract. Smart contracts can also initiate other transactions, such as the transfer of Ether from one account to another, and can even hold (own) cryptocurrencies.

Smart Contracts and Gas

When a smart contract is executed on the Ethereum blockchain, every node on the network is required to execute the code of that smart contract. If there are a thousand nodes on the Ethereum blockchain, and you have a smart contract that pays another 1 Ether, every one of the thousand nodes will execute the same smart contract to determine that the person should get paid. This is obviously not computationally efficient.

Each contract must pay for this computing power by providing “gas” for the transaction. Every computational step in a contract costs gas for performance. Interaction with a contract usually includes a pre-paid gas amount. While gas is purchased in Ethers, the price varies according to demand. To have a smart contract transaction accepted for placement into a new block on the blockchain, a bid price for the required gas is submitted along with the transaction. The miner can then accept whichever transactions they desire for inclusion in their generated block.

The monetary costs for any significant computation are very high. One researcher found that a certain task performed on the Ethereum blockchain would use $26 in gas charges but would cost $0.00000006 on an Amazon web platform (the blockchain calculation costs 400 million time as much). Blockchains also charge for data storage on the blockchain, which can make it prohibitively expensive to store large amounts of data on the blockchain.

Gas prices (which are set in Ether) can vary as much or more that the value of Ether. On May 1, 2022 (the date of an important Bored Ape land sale), the gas cost for a typical transaction (including a simple 32-byte storage of data) was almost $200. Less than three months later, this cost was under $2.

To avoid such charges for computation and data storage, most complex smart contracts move data storage and complex complications off the blockchain. Off-blockchain storage is verified by computing a hash and storing the hash on the blockchain. This blending of on-blockchain steps and off-blockchain steps complicates the programming of smart contracts, but it generally remains possible to ensure the integrity of such data and computations steps using the blockchain.

The Oracle Problem

One example of a recent startup that focused on using smart contracts is Robomed. Robomed started in Russia as a way to pay for medical appointments using digital currencies. The system used smart contracts as a way to ensure that standard medical practices are used during the procedure. Patients can request a medical appointment from a clinic that accepts Robomed referrals and payment. The patient requests a procedure or a treatment through a web interface. The smart contract is the responsible for identifying specific steps that the doctor should perform to meet the needs of the patient. These steps are identified using a database of standard medical practices. The doctor then must verify that all of the steps have been performed. If the doctor fails to so indicate, the smart contract will not release payment to the clinic. If the doctor has performed all of the specified steps, the smart contract will release the digital currency payment to the clinic.

One obvious limitation with the Robomed smart contract is that the physician/clinic being paid is the same individual responsible for confirming to the smart contract that all of the steps have been performed. This is a common problem in smart contracts—who is responsible for providing the inputs necessary to trigger conditional performance within the contract, and can that actor be trusted. As others have noticed, the need to trust third parties to provide truthful data to a smart contract makes it difficult to call smart contracts “trustless.”

Conceptually, the linkage between the smart contract and the real world is accomplished by using an accepted “Oracle.” An Oracle is someone that can provide trusted data. Oracles can also be trusted to perform any real-word task that is prompted by the smart contract. The need to trust such a party or entity is often referred to as the “Oracle Problem” in smart contracts. For example, if a smart contract requires 36 monthly payments before ownership of a real-world asset is transferred, some party or mechanism must exist to ensure that legal transfer of the asset occurs after the smart contract confirms that all of the payments have been made. Even if the asset has been digitized or “tokenized” so that the ownership of the asset is now embodied in a token that exists on the blockchain (see the Bitlaw discussion on NFTs), some type of Oracle is required to ensure that transfer of that digital asset has legal effect in the jurisdiction where the asset is located.

In practice, smart contracts frequently use data sources and software that resides outside of the blockchain as their Oracle. Fizzy, for example, was a European company that utilized a smart contract to provide flight delay and cancellation insurance. After purchasing an airplane ticket, a user could purchase flight insurance up to five days before the flight through a website. An internal algorithm at the website determined the cost of the insurance. If the user purchased the policy, this fact will be embodied in the smart contract. The smart contract used an external but well-respected flight status database as its Oracle to determine when a flight has landed (or if it were canceled). If the flight were canceled or delayed more than two hours, the smart contract indicated that payment should be made to the customer. When implemented, the financial aspects of the transactions were conducted in Euros outside of the smart contract using external programming and public payment networks. It was anticipated, however, that payments in Ether would be accepted such that the purchase of the insurance and the payment to customers would be entirely within the domain of the smart contract. But in no event will the smart contract be able to function autonomously without the Oracle providing the smart contract with real-world flight data.

Is a Smart Contract a Legal Contract

Many proponents of smart contracts have argued that the public nature and immutability of the smart contract means that the legal system is no longer necessary for these transactions. Since “the code is law,” there can be no legal disputes over the terms of the agreement. All parties that agreed to participate in the smart contract have agreed to be bound by the automatic performance of the contract as defined by the code. Once the contract is entered into, there is no longer a requirement to trust the other party. There is no ability to alter the contract, or to change one’s mind on a smart contract. This is the beauty and simplicity inherent in smart contracts—it is “trustless” and removes the need for trusted middlemen. Furthermore, if the code is the law, there is no more need for lawyers.

Not surprisingly, most of these proponents are not lawyers. Lawyers have instead asked questions like “are smart contracts even contracts?” The answer to this question should, of course, be based on standard contract law principles of offer, acceptance, and consideration. Where these elements are present, smart contracts can be considered enforceable legal contracts.

While some states have passed “smart contract legislation,” the legislation does not automatically turn blockchain smart contracts into binding contracts. Rather, the legislation simply states that a binding contract does not become invalid merely because the contract includes a smart contract term (partial automation).

Hence, in reality, most smart contracts today are merely terms within, or mechanisms for the performance of, a standard legal agreement. Even in the absence of clarifying state legislation, there is no reason to believe that an enforceable contract that requires parties to abide by the computations and determinations of a smart contract is unenforceable.

Enforcing a Smart Contract under the Law

Unfortunately, there are some significant limitations to pure smart contracts when compared to legally enforceable contracts written in English (or some other human, non-code language). For example, parties that negotiate a written agreement will frequently utilize purposefully ambiguous language as part of the contract. One party may, for instance, be obligated to provide their "best efforts" to perform an act, or to utilize "commercially reasonable efforts." These phrases, while ambiguous, establish a relatively-well understood level of effort that should be expended to perform that act. A court might be required to determine whether a close case falls on one side of the line or another, but both parties accept that such phrasing best represents their intentions. A smart contract, which requires binary decision points to determine whether or not a contractual requirement has been fulfilled, cannot adequately represent these levels of efforts with their inherent ambiguity.

Furthermore, courts have established various equitable considerations that act to forgive certain types of contractual breaches, or to prevent the enforcement of unusually onerous terms. And if one party induces another to enter into an agreement through fraudulent acts and representations, the courts can invalidate the agreement. In other words, courts can smooth out the inherent unfairness of unequal bargaining positions, can correct minor mistakes in a written contract, and can conform the agreement to the understood intention of the parties. None of these legal niceties are available in a pure smart contract where the "code is the law."

In other cases, parties to a standard contract may choose to forgive partial performance of the agreement and treat the contract as fully performed. The performance may have been "close enough" to perfect performance as to satisfy all the parties involved. Alternatively, one party may forgive partial performance in order to maintain a strong relationship with the other party. This again may not be possible when performance is governed by a pure smart contract.

As explained above, most of the smart contracts that exist today are partial smart contracts, where the self-executing code that defines the smart contract exists as part of a separate (non-smart) agreement. In these cases, an underlying written agreement can establish additional terms of the agreement that are not reflected in the smart contract code. This written agreement can establish and/or resolve ambiguities and spell out the intent of the parties. If there is a mistake or disagreement as to the operation the smart-contract portion of the agreement, the parties will likely be able to resolve this dispute in a court in the same way as they would any other contract.

But what happens when the smart contract is the only agreement between the parties? When The DAO was formed, all non-code written materials were considered non-binding, and only the functionality of the code itself was to be considered binding on the participants. When a flaw was discovered in the code that allowed a nefarious individual to pull out a huge portion of other people's cryptocurrency, the binding smart contract provided no remedy. Could a court of law have intervened to protect the rights of the investors in The DAO? While legal theories certainly exist that could allow such intervention, there are very few real world instances of where this has occurred. In other words, we must still wait and see....

Smart Contract Attorney

Please see Dan Tysver's bio and contact information if you need any smart-contract legal assistance. Dan is a Minnesota-based attorney providing intellectual property advice on smart contract issues to clients across the country.