I’ve mentioned the term “smart contract” numerous times in my blogs related to blockchain and distributed ledger technology. It seems worth drilling down on what exactly a “smart contract” is and whether such a “contract” is enforceable as a legally binding contract. Smart contracts are generally computer code designed to automatically execute all or part of an agreement that is stored on a blockchain, such as the automatic transfer of assets upon the completion of specific programmed criteria. A smart contract may be the only agreement between parties, or it may be used to implement all or part of the provisions of a separate written contract.

Since a smart contract is programmed code, it will only perform each step or item of execution when the pre-programmed criteria has been completed. That is, if “x” occurs, then the code will automatically execute step “y.” Accordingly, all contractual actions must be capable of being completed within the parameters of the programmed code. For instance, if the smart contract requires the moving of an amount of cryptocurrency, the computer code must have access to both the source and target of the currency.

Blockchain technology and smart contracts can be used for any contract asset as long as that asset can be tokenized through the creation of a digital representation of the contract subject. Ownership in almost any asset can be tokenized (such as diamonds, gold, precious metals, art, etc.), but the physical asset must also be considered, creating issues of custodianship and security for the underlying asset. Intangible assets are relatively easy to tokenize. Fungible assets would be easier than non-fungible assets, with unique assets being the most difficult.

The performance parameters of a smart contract are still relatively basic and within the confines of clear objective standards. Smart contracts are actually not that “smart” in that they cannot yet learn subjective criteria such as whether a party has satisfied a best efforts requirement. Currently smart contracts are typically used for the payment of funds, which can be either for proper performance or contract fees, or penalties for non-performance.

Smart contracts can reduce transaction costs by reducing or eliminating the need for third-party intervention, such as escrow account holders. Smart contracts automate internet usage as well. For example, a smart contract could be used to prevent access to a subscription-based website if payment is not made. Smart contracts can also interact with the physical world. For instance, when a product is delivered to a warehouse and scanned in, a smart contract could automatically inform the buyer and seek approval for payment. Generally this will only work for wholesale deliveries as retail buyers still generally like to inspect a product before approving payment.

Although costs are reduced, they are not eliminated. To start, there are the programming costs of the smart contract itself, which can still be very expensive for complicated or multi-step transactions. Over time, these costs will reduce as more open-source, user-friendly software becomes available. Also, most blockchains charge a transaction fee for a contract to be added to the chain and executed upon. In the case of the Ethereum blockchain, the contract fee is known as “gas.” The more complex a smart contract is, the more gas must be paid.

ENFORCEABILITY OF SMART CONTRACTS

There is no federal contract law in the U.S.; rather, the enforceability and interpretation of contacts is determined at the state level. The fact that an agreement is rendered only in code, such as the case with code-only smart contracts, presents no particular barrier to contract formation. Rather, the limitation remains in the ability to program complex transactions or matters that require subjective judgment.

The basic elements of an enforceable contract include (i) an offer; (ii) acceptance of the offer; (iii) consideration (i.e., payment); (iv) mutuality of obligation; (v) legality and (vi) competency and capacity. Also, each state has statutes that require certain types of contracts be in writing (known as the statute of frauds) including contracts for marriage, relating to real property or contracts that will take longer than one year to perform.

In the context of a smart contract, these are easy parameters to fill for programmable actions. Put simply, an offer is a promise to do or not do something in exchange for something else. For example, Blockchain Company X can offer to track software usage for Business Y in exchange for payment of a monthly fee. The key terms, such as delineating which software is being tracked on which computers and report generation, can all be programmed into a smart contract. Business Y accepts the offer by signing up for the service and providing the payment information. Consideration is the requirement that each party provide something of value. In this case Blockchain Company X provides a service and Business Y provides payment – both of which can be accomplished on the blockchain through the use of smart contracts. Mutuality of obligation is similar to consideration with added teeth. If, for example, Business Y could pay for the software monitoring service only if it decided it wants to, there would be no mutuality of obligation.

Competency and capacity refer to the legal ability to enter into a contract. Most states require that a person be at least 18 years of age to enter into a legally binding agreement. Again, this parameter is easily programmable into a smart contract (though maybe not easily verifiable, but that is another topic). Legality refers to the subject of the contract. A contract is only enforceable if the actions required to be taken are legal. That is, you cannot enforce a contract that requires a party to take an action that is illegal.

The Uniform Commercial Code (UCC) also requires certain formalities, including that certain contracts be signed. Since 2000, when the federal government passed the Electronic Signatures in Global and National Commerce (ESIGN) Act, electronic signatures have been legal in every state and U.S. territory. Under the ESIGN Act any law with a requirement for a signature may be satisfied by an electronic signature, electronic signatures may be presented as evidence in court, and a party cannot deny the legal effect, validity or enforceability of an electronically signed document solely because it is in electronic form.

Furthermore, most states (47) have adopted the Uniform Electronic Transaction Act (UETA) and the three states (Illinois, New York and Washington) that have not adopted the UETA have their own similar statutes. The UETA provides that (i) a party cannot deny the legal effect, validity or enforceability of an electronically signed document solely because it is in electronic form; (ii) if a law requires a record to be in writing, an electronic record satisfies the law; and (iii) if a law requires a signature, an electronic signature satisfies the law.

Both the ESIGN Act and the UETA provide for “electronic agents,” which are computer code or programming that can initiate an action or respond to electronic records or perfor­mances without review or action by an individual at the time of the action or response. Arizona and Nevada have already amended their respective state versions of the UETA to explicitly incorporate blockchain and smart contracts, and Vermont has passed a statute making blockchain records admissible as evidence under the Vermont rules of evidence (see HERE).

CHALLENGES

Programming

As mentioned, the limitations of smart contracts are not in the ability to create a contract that satisfies the legal elements necessary for enforceability but rather in the ability to program complex or subjective matters. Also, backing up, the ability to program at all is an impediment to the widespread usage of smart contracts. Parties still need to rely on a trusted technical expert to either capture the parties’ agreement in code or confirm that code written by a third party is accurate. As one of the biggest arguments in support of blockchain technology is the elimination of third parties or intermediaries, this hurdle is significant. Add to that the problem that there’s no way to simplify computer code to plain English. Even a layperson can understand a Form 10-Q business discussion filed with the SEC, but computer code remains pure Greek (at least for now – perhaps not for future generations).

This issue can be problematic for even the most rudimentary basic contracts. Open source and template programming is useful, but even then, a layperson must rely on an interpretation or explanation of the key terms or take the risk that the terms are not as expected. When templates are established that have been successfully used by others, a layperson can read reviews and otherwise reduce the risk that the code will not fit the intended smart contract purpose. Even then, where the code’s only smart contract is used for B2C (business to consumer) transactions, the business should provide a supplementary text -based contract for the consumer to review.

When dealing with a complex legal document, the issue is compounded. A programmer will not be able to understand the complex terms of a legal document. Generally a lawyer will have to parse a legal document into understandable, bite-sized, programmable pieces to interpret the contract for the programmer. Either the programmer must be trusted or a third party will need to review the code to ensure that it properly programmed the contract terms. It brings a whole new meaning to a language barrier.

Also, programming is an expensive endeavor. A robust written agreement including warranties as to use and functionality, an agreement as to updates and ongoing maintenance, and an agreement as to ownership of the code must be entered into with the programmer. Insurance companies could also create policies to protect contracting parties from the risk that smart contract code does not perform the functions specified in the text of an agreement.

Final Agreement

The ESIGN Act and UETA are simply methods of executing a complete final agreement. Most contracts have a “merger clause” confirming that the final written agreement is the “entire agreement” of the parties and that any prior oral or written communications (emails, letter of intent, etc.) are superseded by the final agreement. When a court of law has to judge the performance of a contract, they look to the four corners of the document itself and only consider outside evidence where provisions are ambiguous. An agreement that is entirely code-based can be amorphous.

In the case of a smart contract, a court or other reviewer must look to the code itself and the outcome or performance it created to determine the contract parameters. The reviewer would also need to consider any written communications between the parties such as emails, and testimony as to oral communications, to determine the intent of the contract and whether the smart contract properly manifested that intent. The reason for a merger clause is to avoid this messy examination into outside evidence. Accordingly, where the terms of a smart contract are complex, and the risks associated with improper coding or performance are high, I would recommend a complete written agreement to supplement the code-based smart contract. The text-based written contract should be clear as to which terms (code or written agreement) control where there is a discrepancy.

Sources of Information/Physical Assets

Where smart contract code relates to underlying physical assets, the physical assets themselves must be accounted for, including custody and security. Where those assets are intrinsically valuable such as art, diamonds, or collectibles, security and safekeeping are even more important. Insurance companies already insure valuables for single or small groups of owners, but even insurance becomes more complicated with widespread fractional ownership. Interestingly, blockchain technology and smart contracts can help manage insurance matters with tokenized ownership. A smart contract can be programmed whereby if there is a loss of a physical asset, all owners of tokens that represent a fractional ownership of such digital asset automatically receive their pro rata share of the insurance proceeds.

Where any element of a transaction or business is in the physical world (“off chain”), off-chain sources of information become necessary. A person must verify that a piece of art has been stolen or destroyed and provide the information to a smart contract to process the payment of insurance proceeds.

Off-chain resources can sometimes be digital or computerized as well. For example, a smart contract could be programmed in a securities hedging transaction to provide for a sale or contract cancellation if the trading price of a certain security falls below a set price for a certain number of seconds. However, if the security is traded on multiple exchanges at the same time and in different countries, the price may fluctuate such that the conflicting information makes it difficult or impossible to reach an accurate consensus on the blockchain. In that case, the contract parties may use a third-party digital source to gather conflicting or fluctuating information and use an agreed-upon methodology to deliver the information (in this case, a single price of the security) to the chain that will be used to determine the contract performance.

These trusted off-chain resources are referred to as “oracles.” Although an oracle can present a solution to a smart contract issue, it adds a needed trusted third-party intermediary in a world that is designed to eliminate the need for third-party intermediaries.

The conundrum of custody issues and trusted third-party sources is at the heart of intersecting blockchain and the clearing and settlement of U.S. securities. For an in-depth discussion on FINRA’s study of blockchain and the many issues raised by incorporating the technology, and use of smart contracts, into the U.S. securities markets, see HERE.

Contract Automation

As programmed code, smart contracts cannot be subjectively enforced nor easily amended or terminated. In the business world, valued customers are sometimes given leeway on contract terms, especially payment terms, taking into account the history of a relationship and size of the client. A smart contract cannot make any of these subjective determinations and would automatically shut down service, impose a penalty or take other pre-programmed actions upon a default by a party.

Similarly, there is currently no easy way to amend or terminate a smart contract. In a traditional text-based contract, if the parties mutually agree to change the parameters of their business deal, or if there is a change in law, they can draft an amendment or alter their course of conduct. A smart contract does not offer this flexibility. Furthermore, where the blockchain is open or decentralized (as opposed to controlled or closed), an amendment can be much more complicated than simply adding new code. An amendment may require a fork in the chain. Even simple amendments can require expensive programming costs.

The requirement that a smart contract be fully programmed in advance of its use together with its automated nature is often disconnected from the realities of business interactions. Objective decisions are often made regarding the enforcement, or partial enforcement of contract terms. One or both parties to a contract often decide to waive or partially modify contract terms during performance. The reality of the performance of a contract may have unintended consequences or disproportionate benefits to a party requiring an amendment or re-negotiation of terms. Furthermore, contracts frequently have intentional ambiguities (possibly for the parties to see “how it plays out” or to avoid the continued legal and time expense of anticipating every scenario).

As a result, it is unlikely that smart contracts will find widespread adoption for complex contract matters or personalized business interactions anytime soon. However,

Further Reading on DLT/Blockchain and ICOs

For a review of the 2014 case against BTC Trading Corp. for acting as an unlicensed broker-dealer for operating a bitcoin trading platform, see HERE.

For an introduction on distributed ledger technology, including a summary of FINRA’s Report on Distributed Ledger Technology and Implication of Blockchain for the Securities Industry, see HERE.

For a discussion on the Section 21(a) Report on the DAO investigation, statements by the Divisions of Corporation Finance and Enforcement related to the investigative report and the SEC’s Investor Bulletin on ICOs, see HERE.

For a summary of SEC Chief Accountant Wesley R. Bricker’s statements on ICOs and accounting implications, see HERE.

For an update on state-distributed ledger technology and blockchain regulations, see HERE.

For a summary of the SEC and NASAA statements on ICOs and updates on enforcement proceedings as of January 2018, see HERE.

For a summary of the SEC and CFTC joint statements on cryptocurrencies, including The Wall Street Journal op-ed article and information on the International Organization of Securities Commissions statement and warning on ICOs, see HERE.

For a review of the CFTC’s role and position on cryptocurrencies, see HERE.

For a summary of the SEC and CFTC testimony to the United States Senate Committee on Banking Housing and Urban Affairs hearing on “Virtual Currencies: The Oversight Role of the U.S. Securities and Exchange Commission and the U.S. Commodity Futures Trading Commission,” see HERE.

To learn about SAFTs and the issues with the SAFT investment structure, see HERE.

To learn about the SEC’s position and concerns with crypto-related funds and ETFs, see HERE.

For more information on the SEC’s statements on online trading platforms for cryptocurrencies and more thoughts on the uncertainty and the need for even further guidance in this space, see HERE.

For a discussion of William Hinman’s speech related to ether and bitcoin and guidance in cryptocurrencies in general, see HERE.

For a review of FinCEN’s role in cryptocurrency offerings and money transmitter businesses, see HERE.

For a review of Wyoming’s blockchain legislation, see HERE.

For a review of FINRA’s request for public comment on FinTech in general and blockchain, see HERE.

For my three-part case study on securities tokens, including a discussion of bounty programs and dividend or airdrop offerings, see HERE; HERE and HERE.

For a summary of three recent speeches by SEC Commissioner Hester Peirce, including her views on crypto and blockchain, and the SEC’s denial of a crypto-related fund or ETF, see HERE.

For a review of SEC enforcement-driven guidance on digital asset issuances and trading, see HERE.

For information on the SEC’s FinTech hub, see HERE.

For the SEC’s most recent analysis matrix for digital assets and application of the Howey Test, see HERE.

For FinCEN’s most recent guidance related to cryptocurrency, see HERE.