To be clear, at this point I quite regret adopting the term “smart contracts.”
I should have called them something more boring and technical,
perhaps something like “persistent scripts.”

~ Vitalik Buterin, Ethereum co-founder[1]

Contracting and contract administration processes are becoming increasingly automated, including the introduction of Artificial Intelligence, but their use of blockchain technology is still experimental. Contracting professionals can benefit from a deeper understanding of the role of smart contracts in process automation.

What’s a Smart Contract?

Smart contract is a term used to describe a self-executing computer program stored in a blockchain. In practice, they’re relatively short scripts of code. The programs define actions that software (or a network) will perform if and when certain conditions specified in the program are satisfied.

Semantics: avoiding misperception

Developers refer to smart contracts as distributed applications or Dapps (pronounced dee-apps or dapps).[2] That nomenclature avoids misperceptions about what the programs actually are, and what they can and can’t do.

So, let’s call smart contracts what they actually are: Dapps.

Smart Contract hyperbole

Misconceptions of smart contracts are common. The misnomer exaggerates how Dapps actually work. For example, according to Investopedia:

Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. Smart contracts permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. They render transactions traceable, transparent, and irreversible.

Smart Contract reality

Being generous, maybe half of the above description is accurate.

• Dapps are not contracts or agreements –no meeting of the minds is needed for Dapp code to execute, which is key to the existence of a legally-enforceable contract.
• The terms of the agreement are not directly written into lines of code – at least not contract terms as commonly understood in a legal sense.
• Dapp usage is not limited to a distributed and decentralized blockchain – they can exist on private or permissioned blockchains too.
• Transactions on a permissionless blockchain are not trusted – they’re by definition trustless (not requiring trust).
• Anonymity is not guaranteed on a blockchain – it is better to think of it as pseudo-anonymity because identity potentially can be determined forensically.
• Transactions on a blockchain are not irreversible – a blockchain record is immutable, because unauthorized changes to earlier blocks are easily detected.
• Transactions are transparent only to the extent that information is posted on a permissionless blockchain – every aspect of a transaction on a blockchain isn’t necessarily public.
• Dapps don’t realistically permit common types of agreements to be carried out without the need for some authority, legal system, or external enforcement mechanism – disputes can still occur.

Smart Contracts use simplistic logic

A Dapp will do only what it’s instructed to do, even if that instruction is flawed or leads to an irrational result.[3]  Dapps use straightforward Boolean logic: IF>THEN>ELSE. For example, the script might operate like this:

IF condition A is true, THEN execute action A, ELSE execute action B.

This basic logic can be made more complex; for example:

IF condition A is true, THEN execute action A, ELSE IF condition B is true, then execute action B, ELSE execute action C.

The more complex the coded instructions, the greater the risk of an unintended result. If there is a mutual mistake of fact, or an unforeseen condition, which makes the result grossly unfair, the Dapp would still execute the instruction.

Smart Contracts need help crossing the street

Dapps cannot independently determine whether or not a condition exists in the real world. This is called the “last mile” problem. As described in a Harvard Business Review article What Blockchain Can’t Do:

at the interface between the offline [real] world and its digital representation, the usefulness of the [blockchain] technology still critically depends on trusted intermediaries to effective bridge the ‘last mile’ between a digital record and a physical individual, business, device, or event.

To assess the state of a condition outside the blockchain, Dapps rely on exogenous input from some agent. These arbiters of fact are referred to as oracles. An oracle can be a web service, internet-connected device or human.

A trusted oracle is not necessarily trustworthy. Missing or incorrect input (deliberate or inadvertent) about the validity of an external condition can result in erroneous output from the Dapp, which can lead to a contract dispute.

Smart Contracts have no judgment

Dapps and automated oracles do not exercise judgment.[4] They cannot determine, for example, if contractual performance is reasonable in a given set of circumstances. In an agreement for sale of goods, there may need to be some external input to a Dapp about whether the goods met contractual standards (delivery, quantity, quality, timeliness, etc.) A human oracle might have to decide whether ambiguous or subjective contract terms were satisfied and then trigger a Dapp to perform.

Smart Contracts cannot address all contingencies

It is impractical to code a Dapp to address every situation that could arise in a transaction. In fact, even traditional written agreements are incomplete.[5] It’s not efficient for parties to anticipate in code or contract language unlikely contingencies.

To get around this problem, the parties to traditional written agreements can include recitals or statements of intent that can be used to fill in contractual gaps. Those statements may require a court or other arbiter to determine the parties’ mutual intent and apply it to the circumstances. Without some written agreement, however, a court or other arbiter may be unable to fill the contractual gaps.[6]

Smart Contracts can get it wrong

Even though they’re relatively short, Dapps may contain significant coding errors.[7] Input to the Dapp from an oracle might contain errors, even if the Dapp is perfect.[8] A party might even deliberately enter erroneous input in order to receive payment. Errors can lead to contract disputes when the outcome is not what all of the participants expected.

Smart Contract enforcement and disputes

When a Dapp requires external input about whether or not a condition was met, or in order to address ambiguity, error or unforeseen circumstances (whether mutual or unilateral) in a transaction, there is the potential for a dispute between the parties. A written agreement increases certainty about the mechanism for dispute resolution and the applicable law. It also offers a place to describe typical legal terms that allocate risk, such as limitations on liability or insurance provisions.

Smart Contracts supplement written agreements

Nick Sabo’s 1994 post envisioning smart contracts distinguished smart contracts from strategic contracts.  He did not predict that smart contracts would replace traditional contracts. Instead, he noted that smart contracts might allow “reducing the transaction costs of executing [i.e., performing] some kinds of contracts.” [My emphasis]

Even though Dapps are not truly smart contracts, they promise great utility.  At this point, Dapps are capable of automating relatively simple processes that are governed by a more-traditional written agreement.

It makes economic sense for contract administrators to use automation when a recurring process can be effected with minimal human intervention. So, contract drafters and contract administrators should become familiar with how Dapps can be useful in automating contracting and contract administration processes.

_____________________

[1]https://twitter.com/VitalikButerin/status/1051160932699770882

[2]Smart contracts have far more to do with computer science than with contracts or law. Thanks to the North Texas Blockchain Alliance, I attended a session on Solidity, Smart Contracts and Blockchainat the University of Texas at Dallas covering the basics of how the Solidity scripting language and the Remix IDE are used to code Dapps.

[3]This is a gross simplification. For an example of smart contract code, see https://blockgeeks.com/guides/smart-contracts/

[4]There may come a day when Artificial Intelligence imbues automated oracles with human judgment, but it’s not yet available to Dapps.

[5]See https://en.wikipedia.org/wiki/Incomplete_contracts

[6]Arrangements for the sale of goods between merchants may rely on the Uniform Commercial Code to define certain standard terms, but there nonetheless may be circumstances that leave contractual questions unanswered.

[7]The DAO hack is a notable example of a blockchain coding error that resulted in a loss of approximately $50 million See .https://medium.com/@MyPaoG/explaining-the-dao-exploit-for-beginners-in-solidity-80ee84f0d470

[8]Written contracts may contain errors, too, but they typically provide more context for interpretation of the intended agreement.