The Limits of Smart Contract Enforcement on the Blockchain
By: Jeremy C. Beutler
Part of the appeal of blockchain technologies is the potential that smart contracts have in reducing the transaction and enforcement costs associated with contract performance. A smart contract is a set of code stored on a blockchain that executes the terms of a contract. Because computer code controls contract execution, parties are not dependent on each other or third parties to validate the terms of the contract or provide the necessary trust that both parties will perform. As such, the costs associated with contract validation or counterparty diligence are reduced or even eliminated.
Smart contracts have myriad applications. For example, smart contracts can be implemented to handle insurance transactions whereby the smart contract automates the payment of premiums and will pay out insurance proceeds in the event a covered incident occurs. Or, if an artist creates and sells an NFT, the NFT can include a smart contract that allows the artist to receive a royalty each time the NFT is bought and sold.
Although smart contracts may offer an automated means to ensure contracts are performed according to their terms, there are technological and other limits to the types of contractual conditions that can be automated through smart contracts.
Take, for example, the insurance transaction discussed in above. To implement such a smart contract, the smart contract must have a means of communicating with the insured’s bank account to pay premiums and must receive information from an outside information provider to know when a covered event occurs such that insurance proceeds are payable to the insured.
There is also risk that the smart contract itself could be coded improperly or contain other flaws. One need only consider the experience of those who participated in The DAO, a decentralized autonomous organization that allowed participants to invest in user-submitted proposals run by smart contracts.[1] Flaws in the coding of The DAO’s smart contacts allowed a bad actor to divert about a third of the funds raised by the organization to the bad actor’s account. Given the pseudonymous nature of the Ethereum Blockchain—the blockchain on which The DAO’s smart contracts were built—it was nearly impossible to identify the bad actor and take legal action against them.
The limitations and risks associated with smart contracts and the technology underlying them highlight the need to put in place adequate safeguards to allow parties to pursue enforcement of contracts outside the blockchain. For parties seeking to implement contractual terms through smart contracts on the blockchain, they should also keep in mind a few important considerations for enforcing smart contracts outside the blockchain. Some of these considerations are discussed below.
Recognize the limits of smart contracts. Parties should understand the capabilities of smart contracts and their limitations. While smart contracts are good at implementing concepts like the payment of royalties, insurance premium payments, and other financial transactions, there are, currently, limits to what a smart contract can do, at least by itself. Common contractual terms like confidentiality, limitations of liability, force majeure, indemnification, governing law, and what happens if one party to the contract enters bankruptcy or goes out of business, are more complex and may be difficult to implement in computer code. Moreover, there is the risk that a smart contract could be coded improperly or otherwise contain flawed logic. In such an event, the parties will be left with the question who bears the risk of such a flaw.
Counterparty identity. Part of the benefit of implementing a smart contract on the blockchain is that it allows two parties to engage in a transaction without the need for either party to trust that the other will perform: the smart contract will complete a transaction as it was coded and neither party can interfere with the performance of the contract once it is executed. Such a trustless system works, however, insofar as disputes or problems do not arise outside of the proper execution of the smart contract code itself. In the event an issue arises outside of the rote execution of the smart contract, knowing the identity of the counterparty or counterparties is important for purposes of dispute resolution and contract enforcement.
The DAO experience is one such example of how the lack of counterparty identity can be problematic: participants in The DAO were unable to pursue claims against the bad actor who stole funds from the venture because identity was unknown. Similarly, other contractual elements, such as confidentiality or force majeure, may be difficult or impossible to enforce if the identity of the counterparty is unknown: suing for a breach of confidentiality is impossible if a litigant does not know the identity of the breacher.
Written agreements are critical. As noted above, there are limits to what a smart contract is capable of, and smart contracts are best implemented after the parties have concluded a standalone written contractual agreement. A written agreement has the benefit of filling in the gaps that cannot be covered by a smart contract (such as confidentiality or indemnity issues) and can allocate the risk associated with potential flaws in the smart contract code.
Moreover, a written and executed contract typically provides undisputed evidence of contract formation: the written agreement makes clear that there was an offer, acceptance, and consideration.
Without a written agreement, the parties may be left to dispute whether a contract was formed and what the terms of that contract are. In this way, a smart contract should be viewed merely as a tool to implement certain terms of a written contractual agreement easily and efficiently, not as a fully formed legally binding and enforceable contract by itself.
[1] Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934: The DAO, S.E.C. (July 25, 2017), https://www.sec.gov/litigation/investreport/34-81207.pdf.
