Authors: Markus Kaulartz, Jonas Gross, Constantin Lichti, Philipp Sandner
Which influences do new technologies have on the existing liability regime, which is already complicated without the use of distributed systems? This article sheds light on contractual and product liability in general before addressing the liability question of smart contracts. A legal claim of one contractual party against another might arise due to 1) contractual breach of duty or through 2) producer and 3) product liability. The article analyzed the laws of Germany.
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.
If a smart contract is implemented incorrectly and claims would be asserted, the question arises who is liable. Similarly, the likelihood of success of predictive models must be legally secured in advance. These questions shall be addressed in the following article.
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:
Example A:
In a car repair contract the agreed obligation to perform is: “Fixing of damage of the car”.
In example A, one concrete success is owed, namely that the car is free of damage, i.e., the car must be repaired. If the car is not well repaired, the contract has been violated and warranty claims (e.g., supplementary performance or reduction) and, if applicable, liability claims (e.g., damages) can be claimed. The concrete type of contract is a contract for work (§ 631 BGB).
Example B:
In a car repair contract, the agreed service obligation is: “Search for faults and, if faults are found, carry out repair work”.
In example B, no success is owed, but an activity, i.e., the car garage must make an effort to repair the car, but does not owe any success. If the car is not repaired, the contract has only been breached if the fault was not searched for at all, if no repair work was carried out at all in the case of a fault, or if one of the two was not carried out carefully (which includes, for example, the state of the art). The specific type of contract is a service contract (§ 611 BGB). Warranty claims (e.g., supplementary performance or reduction) are not part of the law of service contracts. If there is a breach of duty, however, a claim for damages is possible (e.g., damages).
In both examples, the breach of duty underlying a claim for damages is different, although the facts of the case are quite similar (defective car is taken to a garage for repair). This example shows that in the case of predictive maintenance, a breach of duty depends largely on how the obligation to perform (i.e., the “what”) was agreed between the parties in the contract. In case A, the obligation is to repair the car. The car garage ows the successful completion of this contract and repair of the car. In case B, the obligation is the service of checking whether the car needs repairing and only if found to have any defect, to do repair work. When drafting contracts, particular attention should be paid to describing the technical background of predictive maintenance, e.g., the purpose of the models and how the models are trained. It is important that this never contradicts other statements, e.g., in advertising for the respective product. Not only the terms and conditions are legally binding, but also every piece of information in any shape or form that the parties objectively and recognizably base their agreement on, including advertising statements.
Practical note: Even if the terms and conditions were perfectly designed, an advertising brochure should not contain phrases like “our software predicts all necessary maintenance”.
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 for intent cannot be excluded by contract (§ 276 (3) BGB), but liability for negligence can. However, there is also a relevant exception to this rule: in General Terms and Conditions (GTC), liability for gross negligence cannot be excluded at all (§ 309 №7 lit. b BGB) and liability for simple negligence cannot be excluded for a) in the case of injury to life, body or health (§ 309 №7 lit. a BGB) and b) in the case of essential contractual obligations (cardinal obligations). These include obligations whose fulfilment is essential for the proper execution of the contract and on which the contractual partner may regularly rely on. Within these limits, not only an exclusion of liability but also a limitation of liability, e.g. a cap, is not permitted.
Whether or not a clause is to be considered as general terms and conditions (GTC) does not depend on whether it is in a document titled GTC. The only decisive factor is whether it has been provided by the other contracting party for a number of contracts (§ 305 (1) 1 BGB). It is already sufficient that the clause should be used at least three times. Whether the contract parties are consumers or companies is irrelevant in this respect. If the conditions for GTC are met, the specific clause falls under the so-called “GTC control” and the limitations of liability and liability exclusions mentioned above apply. The inadmissibility of an exclusion or limitation of liability can also result from legal regulations: For example, in product liability law or in the case of a violation of the general data protection regulation (GDPR), an exclusion of liability is generally not possible.
Practical note: In the case of predictive maintenance, for example, it is important to specify in the contract the data on which the model is trained and the predictions it attempts to make. It must be made clear that machine learning-based predictive maintenance is a probabilistic, not a deterministic method. Therefore, it is advisable that the algorithm represents the probability value it calculates and does not just answer with “yes”/”no”. Like this, one can circumvent being sued for incorrect forecasts as “yes”/”no” are absolute statements while probability values are more nuanced and therefore cannot be held against the accused party as easily.
Liability in case of incorrect implementation of smart contracts
If the smart contract is coded in a wrong way: Who is liable?
In scenarios with smart contracts, we differentiate between at least four roles, whereby overlaps are possible:
- The developers of the smart contract create the code (analogy: manufacturer of a vehicle)
- The operators of the smart contract put it into operation and are perceived by third parties as responsible (analogy: holder of a vehicle)
- The users of the smart contract access it, regardless of the purposes and reasons for why they do so (analogy: driver of a vehicle)
- 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)
Figure 1: Question of liability for services/products including smart contracts
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.
The product liability is a liability for consequential harm caused by a defect, which is why it also includes, according to § 1 (1) 1 ProdHaftG, an injury to body or health or another object — but only if this is used privately, § 1 (1) 2 ProdHaftG. Since both will typically not occur in local scenarios, the relevance of the ProdHaftG for smart contracts is rather low, but by no means excluded.
It, therefore, does not include liability for subsequent development work on the smart contract, nor does it include liability for financial losses. Furthermore, the injured party always has to bear a deductible of 500 euros (§ 11 ProdHaftG), liability is limited to 85 million euros in the case of personal injury (§ 10 (1) ProdHaftG), the liability claim expires according to § 13 (1) 1 ProdHaftG 10 years after the product is put into circulation (here: smart contracts) and the right to enforce a contract expires three years after the injured party had to become aware of the damage (§ 12 (1) ProdHaftG). The claims arising from the ProdHaftG are indispensable and can therefore neither be excluded nor limited by contract (§ 14 ProdHaftG). Since the ProdHaftG does not require fault, the manufacturer is liable regardless of whether or not he acted negligently or intentionally. The ProdHaftG thus also provides for liability when the greatest possible care is taken.
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).
The tort producer’s liability is based on the placing of a defective product on the market (here: smart contracts) and the violation of either a safety obligation or a separate protective law. Case law has identified the following categories:
- 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.
Only those persons are considered manufacturers who are also responsible for compliance with the above-mentioned obligations. These are especially the developers of the smart contract, but rarely the operators of the smart contract.
In contrast to the German Product Liability Act (ProdHaftG), fault is also required in this case, i.e. the manufacturer is not liable if he has exercised the greatest possible care and in particular acted in accordance with the latest state of the art in technology and science. In contrast, there is no deductible and no maximum liability limit in the case of producer liability, the statute of limitations is similar to the ProdHaftG, liability can be limited by contract, but only between those parties between whom a contract also exists, i.e. in particular not in the case of third parties as injured parties.
Practical note: Against this background, the developer of the smart contract is typically responsible if the smart contract contains errors. An exception may apply where damage is caused by incorrect application of the smart contract (e.g. by incorrect transfer of parameters). In practice, it is particularly important to specify in the relevant contracts who is subject to which obligations. In the event of damage, it is easier to trace back who has violated a duty and may therefore be liable to pay damages.
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.
Dr. Markus Kaulartz used to be a software developer and is now a lawyer at CMS Hasche Sigle. He specializes in crypto laws. Since Markus’ clients are both innovative startups and tier one global players, he has gained much experience in advising on legal issues of future technologies and new business models. Markus has particular tech expertise and insights that contribute to his legal advisory practice. His input is often sought where challenges arise at the interface of technology and law. Markus is co-editor of the legal handbook on smart contracts and the legal handbook on artificial intelligence and machine learning.
Jonas Gross is a project manager and research assistant at the Frankfurt School Blockchain Center (FSBC) and also works for the KOSMoS research project. His fields of interests are primarily crypto currencies. Besides, in the context of his Ph.D., he has been analyzing the impact of blockchain technology on the monetary policy of worldwide central banks. He mainly studies innovations as central bank digital currencies (CBDC) and central bank crypto currencies (CBCC). You can contact him via email, LinkedIn and via Twitter (@Jonas__Gross).
Constantin Lichti is a research assistant and project manager at the Frankfurt School Blockchain Center (FSBC), and also works for the KOSMoS research project. Furthermore, he is responsible for project proposals and grants as well as studies published at the FSBC. As a doctoral candidate his research interests include public blockchains and their individual adoption, as well as how the discourse on blockchain technology is reflected in (social) media. He graduated from the Technical University of Munich with a master’s degree in industrial engineering and management. You can contact him via email (constantin.lichti@fs-blockchain.de) and LinkedIn.
Prof. Dr. Philipp Sandner is head of the Frankfurt School Blockchain Center (FSBC) at the Frankfurt School of Finance & Management. In 2018, he was ranked as one of the “Top 30” economists by the Frankfurter Allgemeine Zeitung (FAZ), a major newspaper in Germany. Further, he belongs to the “Top 40 under 40” — a ranking by the German business magazine Capital. The expertise of Prof. Sandner, in particular, includes blockchain technology, crypto assets, distributed ledger technology (DLT), Euro-on-Ledger, initial coin offerings (ICOs), security tokens (STOs), digital transformation and entrepreneurship. You can contact him via Website, mail, via LinkedIn, or follow him on Twitter (@philippsandner).
