Understanding Blockchain
You will often hear blockchain defined as a decentralized, distributed ledger platform that shares (both publicly and privately) and processes, in encrypted form, transactions through the use of private, public, or private and public digital “keys” between parties. Originating in the world of bitcoin and other cryptocurrencies, blockchain has evolved to its use in the transportation of goods, payment of claims, tracking of inventory, health care claim processing, etc. Blockchain transactions are ensured transparency and authenticity through validation and recordation on a global ledger by “miners”—individuals who confirm each step of a transaction by majority consensus. Each segment of a blockchain transaction occurs within a “block” of tens of thousands of transactions until filled and then uniquely and sequentially connected (i.e., “chained”) to another “block” of transactions. In so functioning, the blockchain process eliminates the need for a central authority, such as a government body or financial institution, to verify the transactions. Think of blockchain as a digitized form of generally accepted accounting principles with respect to the recordation of each line item by miners, without any “erasures”—with payment immediately following such confirmation. In certain situations, especially where payment is conditional, an added layer is placed on a blockchain transaction—an externally verifiable, self-executing program called a smart contract.
Benefits of Blockchain
One reason blockchain is in such demand by companies is it provides participants within multi-tiered technology, processing and payment platforms to increase opportunities among vendors, shippers, regulators, and customers to engage in transparency while maintaining the integrity of proprietary systems. In enterprise fashion, blockchain engages competitors to work cooperatively within a common, distributed ledger system to better promote product chain efficiency and reduce costs. The IBM Food Bank is such an example of this type of blockchain enterprise system.
It is therefore unsurprising that proponents of enterprise blockchain pitch its balance among privacy, transparency, and near hack-proof design as eliminating the concern for trust between transactional parties. Indeed, some advocates—including the purported “inventor” of smart contracts—see blockchain as a digital sea change that minimizes the need for central authorities and intermediaries who either seek a “piece of the action” or get in the way of expeditious and “real time” transactions. While this all presents the potential to eliminate the need for trust, decrease transaction times, and minimize fees paid to intermediaries, time will tell whether this technology necessarily dictates the lack of a need for the attorney as meddling intermediary.
The Purpose of Blockchain-Based Smart Contracts
As such, the smart contracts serve to enforce, confirm, and process the execution of legal, contractual obligations through “self-executing” codes, thereby greatly reducing transaction costs and risks. However, what about those blockchain transactions that are conditioned on the happening of an event, such as weather conditions? A smart contract’s programmable code of if/then conditions that are written into a blockchain transaction would seek to confirm external data to ensure conditions are met. As put by Cardozo Law School professor Aaron Wright, a smart contract is a “small computer program or some computer script that will transfer an asset that’s managed, maintained, or recorded to a blockchain.” Put another way, a smart contract is not, in the traditional sense, a legal “noun,” i.e., a meeting of the minds; rather, it is a “verb,” i.e., a self-execution of digitally coded conditions.
Blockchain-Based Smart Contract Vulnerabilities
So this all begs the question: If the purpose of blockchain was to avoid human interaction in the form of a “middleman,” therefore eliminating the concern over a breach of trust, then doesn’t layering into the blockchain a smart contract based on human-operated or -programmed (and therefore untrustworthy) channels serve to undermine that very purpose? The answer seems to be a resounding “yes” given the level of human interaction or “oracles,” which are trusted data enforcement mechanisms provided by third-party services to confirm an executable code based on external data. The potential for human error through smart contracts can take the form of anything from customizing and writing the smart contract program, to the core development of the software, to the developers of smart contract applications, to the miners and oracles that validate conditions rooted in smart contracts, to the users who execute smart contracts on the blockchain. As one cybersecurity expert noted in the context of the hack into an Ethereum-based smart contract program used by an adult entertainment site, smart contracts “are only as secure as their least flagrant bug.” And therein lies the irony of the marriage between blockchain technology and smart contracts that has led to the legitimate criticism that the smart contract is neither “smart” nor a “contract.”
Complicating things is the explosive growth of devices on the Internet of Things (or IoT, the term used to describe the interaction between computers and digital devices, by businesses and people, in transferring data over networks, such as inventory tracking, GPS, and remote security devices) and artificial-intelligence-based interconnectivity to those very factors relied on by oracles in making the call on whether a condition has been met. Due to smart contracts, exponentially greater threats are arguably open to hackers, ransomware, and malware seeking to do harm by the innocently negligent acts of an oracle.
Insurability of Smart Contract Claims
Given the element of human error added in the context of smart contracts to an otherwise human-free blockchain paradigm, the question for companies engaged in blockchain is whether insuring against the level of exposure to liability claims by virtue of errors of judgment made in confirming smart contract conditions can ever be cost-effective. Indeed, failure to “introduce robust cybersecurity protection features . . . could have significant detrimental effects on the manufacturer’s prospects of selling the device without running significant liability . . . even rendering it uninsurable or, alternatively, too expensive to insure”—for purposes here under cyber liability coverage policies.
The insurable risk from a potential blockchain cyber attack increases significantly by virtue of smart contracts because they are only as “smart” as the code on which they’re built—thereby necessitating the need for lawyers in programing smart contracts. In such a circumstance, even an innocent coding error within the smart contract could present significant losses to an insured engaged in blockchain. Indeed, this error can take place even where lawyers with coding experience are integrally involved in overseeing the computer programming process, because their involvement is to address the processing of nuanced, more subjective, “soft standard” terminology, such as “reasonable efforts,” and “time is of the essence”—all of which is ripe for subjective interpretation and therefore covered as a covered act of negligence, rather than an intentional cyber breach or contractually agreed upon indemnity, both of which may not be covered under most policies.
Such errors have already taken place. In 2016, the hack of a smart contract in “The DAO” public offering of cryptocurrency over a 28-day period created an endless loop such that the act of sending funds immediately triggered successive, repeated requests to send more funds, all to the tune of $150 million in losses. For that reason, assuming that the proposition of human error—or, put more simply, negligence—reemerges in blockchain-related breaches through smart contracts, how would a court treat coverage for claims related to a smart contract under certain “silent,” non-cyber coverage policies?
Coverage for Losses Related to Smart Contracts
Where a first- or third-party loss results in damage to or loss of use of a company’s computer hardware, software, or the data contained therein as the result of a cyber event, insurer attempts to argue the inapplicability of coverage are encountering greater obstacles. Take, for example, a loss arising from the vulnerability of a blockchain-based smart contract. In such a scenario, a typical defense to coverage is to argue the data loss as not being “property” under commercial general liability (CGL), business personal property, and product liability coverage lines or endorsements and, thus, a non-covered loss. However, the recent trend is toward finding coverage, especially in the absence of a specific electronic media or data exclusion, e.g., a carve-out, from the coverage grant: “Some third-party complaints alleging negligence by an insured” will likely turn on the issue of whether “the loss involved is one of ‘property’ (and, if so, is it tangible or intangible) or only economic loss. . . .”
On that front, I wrote a piece regarding the IoT’s integration of software and hardware software in “turnkey” transactions (those involving the integration of software and hardware) as blurring the “tangible”/“non-tangible” distinctions and thus redefining losses from data breaches as “falling more in line with products such as natural gas, which has been found to be tangible, covered “property damage.” Indeed, just this year, the U.S. District Court for the District of Maryland similarly found the distinction to be of no moment in ruling that a Businessowners Special Form Computer Coverage endorsement provided coverage for a ransomware attack that resulted in a “direct physical loss of or damage to” its computer hardware, software, and data that the hardware needs to function properly.
As a result, in the absence of specific exclusionary language for data breach claims, expect more courts overseeing cyber-related coverage actions to rely less on the tangible/non-tangible distinctions in determining whether there was a property loss, especially in the context of the IoT and other turnkey devices and programs under Uniform Commercial Code Article 2. Similarly, in the context of whether malware affecting third-party software affects a service (as opposed to a tangible good or product) and whether resulting liability from the cyber event constitutes property damage, the trend is to find the traditional software versus hardware coverage argument as amounting to a distinction without a difference.
Applicability of Breach of Contract Exclusions to Third-Party Losses
Under the Restatement (Second) of Contracts, the basics of contract formation are that there must be a “meeting of the minds” between commercially “competent parties, sufficiently definite terms, mutual assent and performance, and an exchange of value or another form of consideration.” It is due to the “meeting of the minds” requirement that many make the strong argument that smart contracts are not legally enforceable contracts, given that they merely serve as an automated, conditional function to execute actions that do not require parties to make an offer and acceptance. Such is the case with “browsewrap” agreements—a very basic form of smart contract—which have been held not to be a manifestation of mutual assent or meeting of the minds:
Contracts formed on the Internet come primarily in two flavors: “clickwrap” (or “click-through”) agreements, in which website users are required to click on an “I agree” box after being presented with a list of terms and conditions of use; and “browsewrap” agreements, where a website’s terms and conditions of use are generally posted on the website via a hyperlink at the bottom of the screen. . . . “Unlike a clickwrap agreement, a browsewrap agreement does not require the user to manifest assent to the terms. . . .”
In the context of third-party claims, most CGL policies have exclusions that preclude coverage for damages resulting from the assumption of liability in a contract or agreement, including, as insurers would argue, breach of contract claims. A typical breach of contract exclusion reads as follows:
This insurance does not apply to any claim or “suit” for breach of contract, whether express or oral, nor claims for breach of an implied in law or implied in fact contract, whether “bodily injury”, “property damage”, “advertising injury”, “personal injury” or an “occurrence” is alleged. . . . Furthermore, no obligation to defend will arise or be provided by the Company for such excluded claims[.]
However, if a smart contract is, as at least one C-suite-level expert put it, “an executable piece of code that can automatically use what can be promised and what is supposed to be delivered,” and nothing more, then it is doubtful that smart contracts would be subject to this exclusion.
Though there is a dearth of case law on smart contract liability exposure, there is one decision by the U.S. District Court for the Southern District of Florida that gives ammunition to insureds seeking to do battle with insurers that disclaim coverage under a breach of contract exclusion for defense and indemnity due to third-party smart contract claims. There, the court ruled that purchasers of cryptocurrency “tokens” in an initial coin offering (ICO) were not bound to the terms of an arbitration provision appearing in a user agreement where the purchase of tokens takes place through a digital wallet web address via a self-executing smart contract:
A party making a purchase via the smart contract, would not have had to agree to any of the terms contained in the Token Sale Agreement in order to complete the purchase and would have automatically received a corresponding amount of [tokens] based on the amount of Ether sent to the Centra Token Smart Contract Address. . . . (“When ICO purchasers send their Ether to the relevant wallet address, the smart contract is automatically executed and the purchaser receives the appropriate number of tokens in exchange.”)
As in the browsewrap cases, the court specifically found no mutual assent or meeting of the minds to form a contract, given that customers purchasing tokens through the ICO smart contract “were NOT required to check any boxes or click any buttons in order to complete their purchase; the transaction was completed automatically upon transmission of consideration to the smart contract wallet address.”
In the context of cryptocurrency, at least one other court found that an alleged mishandling of code changes in the launch of a new cryptocurrency trading platform resulting in futures losses to bitcoin cash holders was not exclusively governed by the terms of a user agreement, but rather sounded more in negligence due to the cryptocurrency exchange developer’s “duty to maintain a functional marketplace” for its bitcoin holders. “[T]he company’s responsibility goes above and beyond those contracts. Since Coinbase created a platform where a market for a commodity is established and presides over its exchange, it has an obligation to be careful with users’ money regardless of its user agreement.”
The Commodity Futures Trading Commission has also identified negligence-based scenarios, such as are built-in operations risks to a blockchain transaction, such as insufficient backup mechanisms, vulnerabilities from dependent systems, hard and soft “forks,” or the complete loss of a virtual asset due to software or hardware hacks and other cyber breaches—all of which make the case for the inapplicability of breach of contract exclusions to third-party losses derived from smart contracts.
While blockchain advocates may have inadvertently harkened back to a time of Holmesian theory of contract—i.e., an original contract theory espousing that all that matters is the contract’s objective meaning—smart contracts serve to keep the law grounded in more modern, equitable contract doctrines that serve as a counterweight to classic contract theory. In a blockchain world where “the contract-breaker’s motivation . . . makes no legal difference whatever,” the smart contract offers tort-based considerations that may not only remove it from the exclusionary aspects of CGL and other traditional coverage lines but also redefine what it is to provide coverage for “property” as that term becomes redefined as an indistinguishable hybrid of hardware, software, and data.
