Legal Aspects of Blockchain Technology — Liability

Preamble

This article is the seventh publication of the series “legal aspects of blockchain technology” by the Frankfurt School Blockchain Center (FSBC), Datarella, and CMS Hasche Sigle. This research is part of the KOSMoS project, a research project funded by the German Federal Ministry of Education and Research (BMBF) under the funding code 02P17D020. The Frankfurt School Blockchain Center gGmbH and Datarella GmbH are part of the “KOSMoS” consortium. Together with partners from the industry (Schwäbische Werkzeugmaschinen GmbH, Alfred H. Schütte GmbH & Co. KG, ASYS Automatisierungssysteme GmbH), academia (Universität Stuttgart, Hochschule Furtwangen), and software development (inovex GmbH, Ondics GmbH), they create a blockchain-based solution allowing manufacturing companies to establish a DLT-based framework for producing machines in order to (a) execute dynamic leasing contracts, (b) provide transparent maintenance documentation and © ensure high-quality documentation of manufactured products.

Introduction

Decentralized blockchain business models based on decentralized finance (DeFi) are flourishing. DeFi applications are mostly built on the Ethereum blockchain and thus via smart contracts. One of their main features is automatization of payment execution. Smart contracts function in a decentralized manner, i.e., the responsibility in legal and technical terms is distributed amongst multiple participants instead of one single entity. They enable interoperable, transparent, and open protocol pendants to existing financial services and products. Their technical design is inherently different from existing financial services and products. However, their legal liability compares to a great extent to their more traditional counterparts. Predictive models are another emerging product that also needs to be embedded in the existing regulatory framework. They include learning algorithms which are capable of approximating any kind of relationship in the data that they examine. They are used to extract the repetitive and consistent patterns across the dataset. Predictive models focus on information that is relevant and useful for the prediction of important outcomes. One such use case for predictive models is the maintenance of cars. Since the reliability of these models can only ever be asymptotically close to being 100% correct, misjudgements need to be accounted for. This means that even to the best of their abilities and set up, predictive models will always have a certain margin of error in what they forecast.

Protection in case of misjudgements

Mathematical models used for predictions in the industrial context (e.g., in the field of predictive maintenance) are based on statistical assumptions and are by their very nature never able to make a 100% reliable prediction. They are rather best guesses. How can one protect against misjudgements? The answer to this question depends on the individual case, since liability is influenced by the applicable legal relationship (what type of contract, tort) and this, in turn, depends on all circumstances of the individual case. In the following, we will have a closer look at a breach of duty, limitation of liability and producer liability.

Breach of duty

In principle, liability always requires a breach of a duty. The obligation to perform can be described within certain limits. The obligations that parties have to fulfil are contractually predetermined and depend on individually agreed terms and also on the type of contract that the parties concluded. The obligations arising from the type of contract are defined by law:

Limitation of liability

Irrespective of the question whether a breach of duty exists, the question is whether liability for a breach of duty can be limited or even excluded. In principle, a debtor is only liable if she is responsible for a breach of duty, i.e., if she is at fault (§§ 280 (1) 2, 276 (1) 1 BGB). This includes intent and negligence. If a debtor has neither intentionally nor negligently violated a duty, for example, if damage has occurred despite the application of the greatest care, the BGB does not provide liability coverage (in principle). However, there are a few exceptions, such as in tenancy law in the case of defects existing at the time of conclusion of the contract (§ 536a (1) BGB) or in the case of guarantees; in such cases a debtor is liable regardless of whether he is responsible for a breach of duty, i.e. whether intent or negligence is involved.

Liability in case of incorrect implementation of smart contracts

If the smart contract is coded in a wrong way: Who is liable?

  1. The developers of the smart contract create the code (analogy: manufacturer of a vehicle)
  2. The operators of the smart contract put it into operation and are perceived by third parties as responsible (analogy: holder of a vehicle)
  3. The users of the smart contract access it, regardless of the purposes and reasons for why they do so (analogy: driver of a vehicle)
  4. Damaged parties are those who suffer a loss, e.g. due to an error in the smart contract (analogy: e.g. passengers of another vehicle, passers-by)

Liability reasons

Three different liability scenarios are conceivable (see figure 1):

Contract

Any liability arising from a breach of a contractual obligation (§§ 280 ff. BGB) shall initially require the existence of a contract. If the damaged party is the user, only a contract between the operator and the user can be considered, but not between the developer and the user. If the injured party is the operator, however, she will invoke a contract with the developer.

Product liability

The German Product Liability Act (“ProdHaftG”) also gives third parties who are not bound by a contract the opportunity to claim damages. The term product within the meaning of § 2 ProdHaftG arguably also includes software and, thus, also smart contracts. The term “manufacturer” of § 4 ProdHaftG is very broad and includes everyone who has manufactured the end product, a basic material or a partial product. Thus, the term “manufacturer” includes in particular the developers of the smart contracts, but typically not the pure operators of the smart contracts.

Producer liability

The producer’s liability under tort law is specified in §§ 823 ff. BGB. The producer (manufacturer) is also liable to third parties, a contractual basis is not required. Just as in the case of product liability under the German Product Liability Act, producer liability does not protect the interest of equivalence (i.e. the usability and functionality), but the interest of integrity (integrity of the injured party’s legal interests in the form of life, body, health and property).

  • Design flaw: The smart contract does not meet the legitimate security expectations of an average user, even after its design.
  • Manufacturing defects: Although the manufacturing process was correct, there is an unplanned deviation in individual pieces — in the case of software this is rather rare, for example in the case of damaged data carriers.
  • Errors in instructions: The manufacturer omits necessary warnings and instructions for use.
  • Product monitoring obligation: After the product has been placed on the market, the manufacturer must monitor the product and, if necessary, initiate a recall in order to prevent risks emanating from the product — this also seems rather unlikely in the case of a smart contract, but may still occur if security gaps subsequently arise.

Who is liable if the smart contract was audited?

Apart from the fact that third parties find errors in smart contracts and thus make damage scenarios less likely, the procedure when an auditing company or law firm examines a smart contract remains unchanged. This is because it seems quite untypical for them to assume their own liability towards users of the smart contract. Legally, this would be possible, but the matter at hand is a contract in favor of third parties (§ 328 BGB): The operator of the smart contract and the accountancy firm or attorney conclude a contract and agree that users of the smart contract are entitled to claims against the accountancy firm or attorney under this contract. The latter would, however, be offering a kind of insurance, which would be untypical for the profession. It seems more obvious that such an insurance is actually taken out to cover claims against the operator of the smart contract.

About KOSMoS

KOSMoS is a research project funded by the German Federal Ministry of Education and Research (BMBF) under the funding code 02P17D020. More information about the project can be found on the website.

Remarks

If you like this article, we would be pleased if you would forward it to your colleagues or share it on social networks. More information about the Frankfurt School Blockchain Center on the Internet, on Twitter or on Facebook.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jonas Gross

Jonas Gross

Jonas Gross is Chairman of the Digital Euro Association (DEA) and Head of Digital Assets and Currencies at etonec. Further, Jonas holds a PhD in Economics.