The commercial world is increasingly reliant on technology, while the legal field has begrudgingly followed suit in order to remain relevant, and competent, in the wake of the digital revolution. Business partners no longer rely on physical handshakes and inked documents. In fact, technology is revolutionizing the art of deal-making. We now expect to make most purchases online through e-contracts, sealed with a click on the “accept” button. Even corporate leaders now use e-mails and texts to negotiate deals, which they eventually “sign” online through services like Docusign.
Despite our current comfort with these new types of online contracts, “smart contracts” on the blockchain push the envelope even further into the digital age. Smart contracts are different from common e-contracts in that they are essentially computer code. Those with no coding background cannot easily interpret a smart contract in its rawest form. Notably, smart contracts are not necessarily contracts and not necessarily “smart.”
Instead, smart contracts are made up of “nodes” which consist of computer coded algorithms that live in a decentralized ledger. A decentralized ledger, such as blockchain or ethereum, is a computer-coded ledger spread throughout computers instead of being centralized in one computer or database. This decentralization helps make smart contracts nearly unhackable. Furthermore, these decentralized ledgers are immutable, meaning that the code generally cannot be altered. In other words, most distributed ledgers are “append only,” meaning that parties may add to, but not alter, information placed in the ledger.
This immutability and decentralization foster data safety. Accordingly, companies place data in the blockchain or another distributed ledger in order to manage risk. Furthermore, blockchain-based smart contracts create efficiencies and resolve transactional trust issues. The idea is that smart contracts may largely eliminate the need for complicated and costly letters of credit, bonds, and security agreements by digitizing automatic enforcement or payment in immutable computer code. At core, smart contracts codify if-then actions that may mimic contracts if built on a prior agreement, or could simply carry out payment or enforcement based on objectively delineated facts. Examples of if-then actions are “If it rains, X gets an umbrella,” or “If the goods reach port A, B gets paid.”
The problem is that no amount of computer code can eliminate conflicts. An oracle, or third-party fact verification system, could incorrectly detect rain, code may be flawed, there may be disputes about what qualifies as “rain” (mist, fog, sleet), etc. Furthermore, parties may fight about delivery of defective goods, leaving parties with no choice but to attempt litigation to recoup losses. Aside from resetting – i.e, shutting down – the whole “if/then” system, these kinds of disputes present a challenge for immutable blockchain architectures.
Accordingly, parties are wise to plan ahead and build arbitration into their smart contracts, in order to have a dispute resolution plan should smart contracts go awry. Indeed, users of smart contracts may want to build arbitration into their code to promote efficiency, protect privacy and ensure an expert decisionmaker. Furthermore, users may want to specify allowance for online arbitration to augment this efficiency, especially given the cross-border nature of most smart contracts. Smart contract dispute resolution should honor and support the efficiency of smart contracts. Furthermore, smart contract users may want to even further support these dispute resolution mechanisms by placing disputed funds in escrow while arbitration takes place to help ensure trust and enforcement of decisions. To read a longer version of this article, with further specifics on smart contract, blockchain, and how arbitration fits into this mix, see Amy J. Schmitz, Making Smart Contracts “Smarter” with Arbitration, Articles for Technology Disputes (American Arbitration Association 2020), at https://go.adr.org/technology-adr.html.