What is Liability?

Generally speaking, between common law and civil law legal codes, precedents, and legal doctrines, liability is a fairly well-defined concept requiring a couple of things:

1. Damage → Distinctions are drawn here between pecuniary and non-pecuniary damages generally.

2. Causality → Behaviour of the liable party has to be conditio sine qua non, meaning that the damage in question would not have occurred were it not for a specific behaviour taking place. This can also refer to a ‘lack of action’ that was contractually required. If a causal link is established between the action and its outcome, causality requirement is likely established.

These concepts are very broad, and will be more finely defined depending on the kind of liability sought, for example Negligence, Breach of Contract, Unjust Enrichment, etc. All these specific tort claims will have specific liability tests that speak to the two concepts above.

How do Smart Contracts Reduce Liability?

Spotify Use-Case → In one notable example from the music industry, music streaming company Spotify acquired Mediachain Labs, a blockchain startup company, in order to develop a decentralized database to connect artists and licensing agreements with the songs listened to by Spotify users. This acquisition took place after a licensing dispute over unpaid royalties between Spotify and the National Music Publishers’ Association. In the settlement, Spotify agreed to pay over twenty million dollars to music publishers. “Spotify had claimed that it didn’t pay out the royalties because it simply didn’t have the necessary data to help it figure out whose claims were legitimate, or even how to locate the parties. It said it lacked an authoritative database that covered all existing music rights.” The decentralized database being developed by Spotify is essentially a smart contract between artists, streaming services, and consumers. The database will utilize peer-to-peer technology to monitor where and when an artist’s songs are being played.

Takeaway: Implication here is that smart-contracts allow for the natural layering for funnels and AI to funnel from a data structures perspective, where none existed previously, and where lack of one exposes you to contractual or statutory breaches; All txns are always live, and all data is always pullable, regardless of time or status, and Spotify would have saved 20M bucks…

IBM’s TradeLens Use-Case → The use of shared-ledger technology in logistics reduces fragmentation between the involved parties, which reduces costs and avoids unnecessary confusion and delays in the supply chain process.The technology implements smart contracts to automatically distribute and execute business processes such as import and export clearance, adding security and efficiency to the transaction. As with any other blockchain implementation, the “full audit history [is] maintained on the blockchain” and is possessed by every member of the transaction—rather than a central authority—which increases the reliability and security of the process.

Takeaway: Clarity on-chain re shipments status, and increased efficiency will have knock-on effects on liability since less contracts will be breached or defaulted on. This same logic applies to intl financial instrument markets, and any other logistics knock-ons and analogues…

Where to Look for Liability in Smart Contract Txns?

There are 4 key parties to any smart contract blockchain ecosystem:

the core developers of the blockchain software;
the miners that validate transactions;
the developers/propogators of the smart contract applications; and
users of the smart contracts.

Generally, it will be impossible to attribute any liability to 1 and 2, since these are not privy to the smart contract itself, merely the substrate on which contract development and performance occurs. This leaves us with the devs/propogators/legal engineers and the end users. These parties are ultimately where liability will fall in the case of a smart contract going awry in any one of a million ways.

Attorney Malpractise Liability → A lawyer should always watch that their competency (or lack thereof) with a new technology does not expose them to a malpractice suit.

There are two possible tracks to interacting with Smart Contracts as a lawyer: (1) the attorney must utilize a third party who is qualified to understand code to an extent necessary to ensure that the contract will work as intended, or (2) the attorney himself must obtain such knowledge and qualification. Legal engineering explicitly encourages the latter (2), which obviously leads to malpractice allegations if clients’ expectations or promised outcomes are not met.

Lawyers are also exposed to liability from third party actors they have hired or leaned on to provide legal engineering services, stemming from not just rules of professional conduct, but also general fiduciary standpoint…

The Oracle Problem → An extension of the malpractice issue, assuming the oracle stems from legal recommendations from the lawyer. This occurs when an Oracle either misrepresents the will of the parties, or misrepresents specific performance on-chain that is later relied on by the parties in their contract, the lawyer who vets the oracle can obviously face issues. The Smart Contract does not think for itself, and will require that people intervene to interpret the oracle’s outputs, and this will always require human interpretation, regardless of the claims made by Oracle provision services…
Decentralized Contract Platforms → Do the parties want that or are they seeking to record their obligations on a truly immutable ledger? If not, and a lawyer/ legal-engineer pushes them towards this option, whereby their information is subsequently forever on a blockchain, downstream liabilities will emerge that are extremely hard to plan for.

Differentiating when a ‘closed’ application with a centralized administrator (ala Cooperativ.io) are required is key.
Jurisdictional Liabilities → A lawyer must be aware that certain blockchain applications will need to be closely designed in a way that they can work for their intended purpose in all of the internationally (ideally). Since blockchain is an internet native dependent technology, jurisdictional issues rarely enter into the development picture when considering how to bring a product to market. It is the lawyer who has to look at the functional portions of the product and determine whether or not modifications have to be made to the data structure to accommodate it working in places where the legislative environment could be more hostile to blockchain-enabled apps.

Clear examples of this are things like the EU’s GDPR requirements for ‘right to be forgotten’, which at face value seems anathema to the blockchain thesis of always-on transparency and immutability. There are ways around these issues that usually involve clever legal engineering solutions that tailor data-specs to legal requirements, but they must be understood and problem spotted before they become a problem…

Malfunctioning Code/Contractual Frustration → Frustration applies where the parties have entered into a contract but a subsequent event has rendered performance physically or legally impossible, or “radically different” from what was contemplated by the parties. Code breaks, and if the only regulated entity in the deal-chain is the lawyers, then they will likely incur the liability as the parties approving the code and the transaction…Thought should be given to these possibilities, and whether any risks can be mitigated from the outset, for example, by including a ‘kill switch’ in the code which can be deployed if termination is required before the code has fully executed. The parties might also consider whether it is appropriate to negotiate exclusions of liability connected with issues arising with the code.

There are increasingly Web3 native solutions to issues like malfunctioning code through insurance or escrow smart contracts that will try to limit the liability allocated to parties in case of contract breakage, or attempt to indemnify parties.

Regulatory Liability → The SEC, CFTC, and not to mention other foreign regulators of financial markets will look for someone to blame if a smart contract dealing with financial instruments under their purview runs afoul of regulation. Commissioner Quintenz (CFTC) stated that to ascertain the culpability of the smart contract code developers, the “appropriate question is whether these code developers could reasonably foresee, at the time they created the code, that it would likely be used by U.S. persons in a manner violative of CFTC regulations.” If such a use is foreseeable, Commissioner Quintenz believes that a “strong case could be made that the code developers aided and abetted violations of CFTC regulations.”

The Commissioner recommended that smart contract developers engage and collaborate with the CFTC prior to releasing their code to ensure that the code will be compliant with the law. The Commissioner even suggested that the CFTC is willing to rethink its existing regulations or provide regulatory relief, depending on the technology in question.
Good Old Breach of Contract → Where a contract has been agreed in natural language prior to it being recorded in code, the scope for novel contractual and other disputes is likely to be significantly lower than with contracts which are wholly recorded in and defined by code given that the first step in determining whether a contract has been breached will be to understand what obligations arose under the contract. The usual principles relating to contractual interpretation and construction would apply to a traditional, natural language contract and be deployed to assess whether an automated code has failed to perform those obligations correctly.

A contract which is only defined by code will give rise to more novel issues as regards interpretation and construction. There may be a greater reliance on evidence of discussions between the parties in the lead up to the creation of the contract/code (and parties should be mindful of that when they are negotiating terms which will be recorded in a smart contract). There may also be heavy reliance on expert evidence regarding the meaning of the coded terms both in terms of what they would mean to a functioning computer, and what the terms would mean to a reasonable person with knowledge and understanding of the code.

How do we rectify Smart Contract screw-ups?

Rectification of any of the above situation will depend on the particular fact pattern that led to the Loss event, but in general terms there are some broad concepts/rules that apply.

Situations where claims for rectification could arise:

where there is a prior natural language contract, which is subsequently converted or translated into code which one or both parties contend does not reflect their common intention;
in cases where contractual obligations are only defined in code, and the standalone smart contract fails to accurately record the common intention of the parties (ie common mistake), or;
a unilateral mistake, eg where the code is produced in draft, one party is labouring under a misunderstanding as to how the code will operate, and the other party is aware of that but does not raise it with the other party, perhaps because the error or misunderstanding works in their own favour. A claim for rectification could arise in that situation because it would be contrary to good faith for a party to enforce a contract which it knew was inconsistent with the bargain that the other party believed was being made at the time of entry into the contract.

Smart Contract Liability Overview – August 12, 2022

What is Liability?

How do Smart Contracts Reduce Liability?

Where to Look for Liability in Smart Contract Txns?

How do we rectify Smart Contract screw-ups?

Submit a Comment Cancel reply