11. Vertragsdurchführung mit Smart Contracts – rechtliche Rahmenbedingungen und Herausforderungen

Der verwendete Algorithmus kann nach heutigem Stand der Technik ausschließlich eineindeutige „Wenn-dann-Beziehungen“ abbilden (Eschenbruch und Gerstberger 2018, S. 3; Eschenbruch et al. 2020, S. 7). Eine solche automatisierbare „Wenn-dann-Beziehung“ liegt aus juristischer Sicht grundsätzlich beim Zahlungsverkehr vor (dies hat anhand des FIDIC Yellow Book für den Zahlungsverkehr im internationalen Bauwesen auch Rupa, 2021 S. 371, 375 f. noch einmal herausgearbeitet). Zentral und zwingend notwendig für den Abschluss eines Bauvertrages ist eine Abrede über die sogenannten Hauptleistungspflichten, welche nach § 650a Abs. 1 Satz 2 BGB i. V. m. § 631 Abs. 1 Satz 1 BGB für den Auftragnehmer die Erbringung der Bauleistung, für den Auftraggeber die Zahlung der Vergütung ist. Die Logik des Bauvertrages lautet also vereinfacht gesagt: „Wenn Fertigstellung der Bauleistung – dann Zahlung der Vergütung“. Diese beiden Vertragspflichten können daher im Rahmen des BIMcontracts-Systems in digitaler Form Teil des Bauvertrages werden, um eine Automatisierung der Zahlungsabwicklung zu ermöglichen. Das Vertrags-Soll wird durch das nach der Methode BIM erstellte digitale Gebäudemodell sowie eine ebenfalls digitale Leistungsbeschreibung definiert. Diese beiden Dateien lösen die in rein analogen Bauverträgen anzutreffenden Planunterlagen (meist CAD-Modelle) und die analoge Leistungsbeschreibung beziehungsweise das Leistungsverzeichnis ab. Daneben – und dies stellt eine zentrale Fortentwicklung der bislang erhältlichen Tools dar – wird zur Definition der Vergütungspflicht des Auftraggebers ein digitales Abrechnungsmodell geschaffen, das den analogen Abrechnungsplan ablöst. Da die Methode BIM es erlaubt, einzelne Bauteile mit Attributen zu versehen, können die Kosten für die Ausführung des jeweiligen Bauteils unmittelbar aus dem digitalen Gebäudemodell abgeleitet werden. Auf Grundlage eines solchen mit Kosten attribuierten Modells werden Abrechnungseinheiten für das Abrechnungsmodell gebildet, die von den Vertragsparteien im Vorhinein im Rahmen der Vertragsverhandlungen festgelegt werden müssen (zu der Softwarearchitektur und insbesondere dem Abrechnungsmodell s. Sigalov et al. 2021, S. 7653).

Die vorstehend beschriebenen digitalen Vertragselemente (digitales Gebäudemodell, Leistungsverzeichnis und Abrechnungsmodell) werden, sobald sich die Parteien hierauf verständigt haben, zu einem BIMcontracts-Container (BCC) zusammengefasst. Hierbei handelt es sich technisch gesehen um eine ZIP-Datei, welche auf einer Datenbank gespeichert wird. Bei der Nutzung der Methode BIM wird bei dieser gemeinsamen Datenumgebung von einem „Common Data Environment“ oder CDE gesprochen (Sigalov et al. 2021). Hash-Werte des BCC sowie des gesamten Textes des Bauvertrages werden zudem unveränderlich und dezentral abgespeichert. Hierzu wird die Blockchain-Technologie verwendet, die zusätzlich die einzelnen Schritte der Umsetzung des Zahlungsverkehrs unveränderlich dokumentiert. Daneben wird die Blockchain-Technologie auch dafür verwendet, den Vertragsparteien eine rechtssichere Bestätigung der vereinbarten digitalen Elemente des Bauvertrages zu ermöglichen. Den Parteien wird im Bauvertrag jeweils eine eineindeutige Blockchain-Identität verliehen, mittels derer nach Vertragsschluss auf der Blockchain bestätigt werden muss, dass der referenzierte Smart Contract tatsächlich der Parteivereinbarung entspricht. Erst dann kommt es zur Ausführung des Smart Contract, dem Deployment. Im Projekt BIMcontracts (2020) wurde entschieden, statt einer öffentlichen Blockchain eine sogenannte Konsortialblockchain zu verwenden, um den Datenschutz bestmöglich zu realisieren. Denn bei einer öffentlichen Blockchain kann nicht gesteuert werden, wer die redundant gespeicherten Daten hält und wo dies geschieht. Bei einer Konsortialblockchain wird dagegen die Speicherung der Daten auf einige wenige sogenannte „Nodes“ begrenzt, die mittels eines Vertrages (Konsortialblockchain-Abrede) auf die Einhaltung des Datenschutzes verpflichtet werden können. Hierdurch können die Betroffenenrechte nach Art. 13 ff. DSGVO am effizientesten realisiert werden, ohne dass die Sicherheit und Transparenz der Blockchain darunter litte.

Vertragsrechtlich muss schließlich sichergestellt werden, dass sich die Fälligkeit der Vergütung am konkreten Baufortschritt orientiert. Hierzu soll konkret auf den mit Hilfe der Methode BIM erstellten Baufortschrittsplan Bezug genommen werden und nicht nur eine abstrakte Betrachtung stattfinden – wie dies das Gesetz in §§ 632a BGB und 16 der Vergabe- und Vertragsordnung für Bauleistungen Teil B (VOB/B) vorsieht. Ein digitaler Baufortschrittsplan in Verbindung mit dem digitalen Abrechnungsmodell führt dazu, dass der Auftragnehmer nach Fertigstellung einer im Vorhinein definierten Abrechnungseinheit Zahlung verlangen kann. Alle Zahlungen im Rahmen des BIMcontracts-Systems sind juristisch gesehen Abschlagszahlungen. Die Schlussrechnungslegung erfolgt nach wie vor analog, da das Gesetz hieran Folgen knüpft, die nicht ohne Weiteres in ein „Wenn-dann-Paradigma“ einzubetten sind. Wie weit oder eng diese Abrechnungseinheiten gezogen werden, ist den Vertragsparteien bei Vertragsschluss überlassen. Der Auftragnehmer soll grundsätzlich nur bei Fertigstellung einer vollständigen Abrechnungseinheit automatisch eine Zahlung erhalten. Zentraler Diskussionspunkt zwischen Auftraggeber und Auftragnehmer wird dann sein, wie weit oder eng die einzelnen Abrechnungseinheiten zu ziehen sind. Eine eingehende Verhandlung über die Verteilung der Leistungspositionen des (analogen) Leistungsverzeichnisses entspricht aber auch heute bereits gängiger Praxis, sodass an dieser Stelle kein völlig neuer Aufwand für die Vertragsparteien entsteht. Da es bei der Definition von Abrechnungseinheiten keine Rolle spielt, ob die Parteien eine Pauschalvergütung vereinbart haben („300.000 Euro bei Fertigstellung des Rohbaus Erdgeschoss“) oder eine Abrechnung nach Einheitspreisen („Einheitspreis für Ortbeton je Kubikmeter ist 100 Euro“), ist die Vertragsform unerheblich. Das BIMcontracts-System kann daher auch in den in der Praxis gängigen Vertragsketten verwendet werden. Dies gilt sowohl im Verhältnis zwischen einem Bauherrn und einem Generalunternehmer, hier werden häufig Pauschalpreisverträge geschlossen, als auch für das Verhältnis zwischen dem Generalunternehmer und seinen Nachunternehmern meist Einheitspreisverträge verwendet werden. Die übrigen Klauseln des Bauvertrages werden lediglich punktuell modifiziert, um der Zahlungsabwicklung mittels des BIMcontracts-Systems Rechnung zu tragen. So müssen etwa Nutzungsbedingungen für das BIMcontracts-System, die CDE sowie die Blockchain Vertragsgrundlage werden. Daneben müssen Regelungen für die Haftung bei Fehlfunktion des Algorithmus geschaffen und das Thema Datenschutz muss adäquat adressiert werden.

Wenn sich die Parteien dafür entscheiden, die Vertragsabwicklung teilweise mithilfe eines Smart Contracts zu automatisieren, muss aus Sicht der Vertragsgestaltung sichergestellt werden, dass sowohl das Ob als auch das Wie der automatisierten Abwicklung rechtssicher in den Vertrag aufgenommen werden. Wenn es sich bei der Klausel im analogen Papiervertrag, durch die eine Teilautomatisierung aufgenommen wird, um Allgemeine Geschäftsbedingungen (AGB) einer Vertragsseite handelt, sind erhöhte Vorgaben des zwingenden Gesetzesrechts zu beachten. AGB liegen immer dann vor, wenn die Vertragsbedingungen für eine Vielzahl von Verträgen vorformuliert sind und eine Vertragspartei, die Verwender genannt wird, der anderen Vertragspartei bei Abschluss eines Vertrages diese Bedingungen einseitig stellt (vgl. § 305 Abs. 1 S. 1 BGB). Da es nach der Rechtsprechung bereits ausreicht, dass der Verwender der AGB die Absicht hat, dieselben Vertragsbedingungen auch in anderen Vertragsverhältnissen zu nutzen, ist der Anwendungsbereich des Rechts der AGB recht weit (s. Abschn. 10.​2). Es greift sowohl zum Schutze von Verbrauchern als auch von Unternehmern, wobei der Schutz von Unternehmern stärker eingeschränkt, aber gleichwohl sichergestellt ist. In der Praxis wird es sich bei den Klauseln, mit denen Smart Contracts in Verträge einbezogen werden – gerade wenn es zu einer Typisierung von Smart Contracts für bestimmte Abwicklungsschritte in Vertragsverhältnissen kommen wird – um Allgemeine Geschäftsbedingungen im Sinne der §§ 305 ff. BGB handeln (näher zu den durchaus problematischen Einzelfällen, in denen die AGB-Eigenschaft einer Klausel in Abrede gestellt werden kann, Wilhelm, 2020, S. 1849, 1852 f.). Daher ist bei der Vertragsgestaltung hinsichtlich der Einbindung eines Smart Contracts ein erhöhtes Augenmerk auf die besonderen Voraussetzungen der §§ 305 ff. BGB richten. Zu denken ist hier vor allem an die allgemeine Inhaltskontrolle nach § 307 BGB, die Einbeziehungskontrolle in § 305 Abs. 2 BGB und die Regelungen in § 305c BGB.

Gemäß § 307 Abs. 1 S. 2 BGB sind Bestimmungen in AGB wegen unangemessener Benachteiligung unwirksam, wenn die Bestimmungen nicht klar und verständlich sind. Das hierin geregelte Transparenzgebot, das auch für Hauptleistungspflichten und das Preis-Leistungs-Verhältnis gilt (BGH, Urteil vom 15.02.2017, NJW 2017, 2346; Urteil vom 07.02.2019, NJW-RR 2019, 942), verpflichtet den Verwender dazu, einzelne Regelungen für sich genommen klar zu formulieren und diese für die Vertragsgegenseite auch im Kontext mit dem übrigen Klauselwerk verständlich zu machen (BGH, Urteil vom 26.03.2019, NJW-RR 2019, 811). Hierzu gehört vor allem auch, dass dem Vertragspartner klar sein muss, welche Rechtsfolgen gegebenenfalls auf ihn zukommen und wie er deren Eintritt verhindern kann (BAG, Urteil vom 03.12.2019, NJW 2020, 1317). Eine solche Transparenz ist bei Einbeziehung eines Smart Contracts, also letztlich von Binärcode, in den Papiervertrag nur gegeben, wenn die Vertragsgestaltung besondere Vorkehrungen trifft, um eine möglichst umfassende Einbeziehung der Vertragsgegenseite sicherzustellen (Wilhelm (2020, S. 1849, 1854) geht ebenfalls davon aus, dass die Formulierung von Abwicklungsmodalitäten ausschließlich in Programmcode, der mit Funktionen aus externen Programmbibliotheken gespeist wird, im Zweifelsfall mangels Verständlichkeit am Transparenzgebot scheitert). Dabei ist es fraglich, ob es bereits ausreicht, wenn eine Vertragsklausel lediglich abstrakt angibt, dass ein bestimmter, mittels einer Kennung identifizierter Smart Contract für die Abwicklung bestimmter Vertragsschritte herangezogen werden soll. Bei einer solchen Formulierung ist für die Vertragsgegenseite nicht unmittelbar ersichtlich, welchen Inhalt der Smart Contract hat. Wie konkret allerdings die Erläuterung der einzelnen Mechanismen des Smart Contracts im Papiervertrag sein muss, ist bislang weder in der Rechtsprechung geklärt noch lassen sich aus Sicht der Vertragsgestaltung hier abstrakte Grundsätze aufstellen. Eine Möglichkeit, dem Transparenzgebot aus § 307 Abs. 1 S. 2 BGB Rechnung zu tragen, bestünde darin, den Quellcode des Algorithmus als Vertragsanlage dem Papiervertrag beizufügen. Dieser Quellcode ist allerdings für den menschlichen Leser, der in den meisten Fällen ein IT-technischer Laie sein wird, ebenfalls nicht verständlich. Alternativ dazu sollte genügen, wenn in der Vertragsklausel, durch die die Einbeziehung des Smart Contracts in den Gesamtvertrag vorgenommen wird, eine Referenz auf den Code des konkreten Smart Contracts aufgenommen wird und dieser dann von der Vertragsgegenseite bei Interesse nachgeprüft werden kann. Damit dies gelingt, müssen allerdings die technischen Voraussetzungen geschaffen werden, um einen Smart Contract tatsächlich zu visualisieren. Eine solche einfache Konversion von Quellcode in semantische Informationen ist bislang allerdings nicht verfügbar. In zukünftigen Verträgen könnte angedacht werden, als Anlage eine Art „Smart Contract Workflow“ bereitzustellen, der den Ablauf des Algorithmus grafisch oder textlich illustriert. Dies könnte ähnlich einem Bauablaufplan bei Bauverträgen geschehen. Insgesamt betont aber auch die Rechtsprechung wiederholt, dass die Transparenzanforderungen nicht überspannt werden dürfen (BGH, Urteil vom 10.07.1990, NJW 1990, 2383; Urteil vom 20.04.1993, NJW 1993, 2054). Die Verpflichtung, den Klauselinhalt klar und verständlich zu formulieren, besteht nur im Rahmen des Möglichen (BGH, Urteil vom 04.04.2018, NJW 2018, 1544). Wenn die Parteien also im Papiervertrag übereinkommen, die für alle Beteiligten effizientere Form der Abwicklung über einen Smart Contract durchführen zu wollen, muss die Vertragsgegenseite wertungsmäßig auch in Kauf nehmen, dass das unmittelbare Nachvollziehen jedes einzelnen Schrittes im Quellcode des Smart Contracts nicht möglich und nicht abbildbar ist. Dies gilt jedenfalls im Rechtsverkehr mit Unternehmern. Bei Vorliegen von Verbraucherverträgen, wenn also die Vertragsgegenseite den Vertrag zu Zwecken abschließt, die überwiegend weder ihrer gewerblichen noch ihrer selbstständigen beruflichen Tätigkeit zugerechnet werden können, sind die Anforderungen dagegen noch höher ausgestaltet. Es muss dann sichergestellt werden, dass der Verbraucher im Sinne von § 305 Abs. 2 Nr. 2 BGB die Möglichkeit hatte, in zumutbarer Weise vom Inhalt der AGB Kenntnis zu nehmen. Auch vor dem Hintergrund dieser gesetzlichen Regelung stellt sich die Frage, ob eine Visualisierung der Inhalte des Smart Contracts im Papiervertrag, sei es als Anlage sei es als Referenz auf eine Online-Ressource ausreichend ist (Wilhelm, (2020, S. 1849, 1853) sieht bei dieser sogenannten Einbeziehungskontrolle bei Beteiligung von Verbrauchern ein häufig nicht zu überwindendes Risiko. Er geht allerdings auch davon aus, dass die Inhalte des Smart Contracts im Regelfall nicht in von Menschen lesbare Sprache übersetzt werden). Da allerdings auch hier wie bei der Inhaltskontrolle keine überzogenen Anforderungen gestellt werden dürfen, um technologische Fortschritte nicht von vorneherein zu blockieren, sollte durch eine entsprechende Vertragsgestaltung den Einbeziehungserfordernissen des § 305 Abs. 2 Nr. 2 BGB Genüge getan sein. Besonders wichtig bei dieser Vertragsgestaltung sind eine möglichst klar verständliche Formulierung der Schnittstelle zwischen Papiervertrag und Smart Contract sowie eine möglichst eingängige Visualisierung der Inhalte des Smart Contracts.

Nach § 305c Abs. 1 BGB werden daneben solche Bestimmungen in AGB nicht Vertragsbestandteil, die nach den Umständen, insbesondere nach dem äußeren Erscheinungsbild des Vertrags, so ungewöhnlich sind, dass der Vertragspartner des Verwenders mit ihnen nicht zu rechnen braucht. Dies kann etwa der Fall sein, wenn eine Klausel eine Zahlungspflicht für den Vertragspartner des Verwenders vorsieht, mit der dieser nach den Umständen des Vertragsschlusses nicht zu rechnen brauchte. Eine Vertragsklausel, mit der ein Algorithmus Vertragsbestandteil werden soll, muss daher sicherstellen, dass die konkreten, im Algorithmus definierten Abläufe nicht dem widersprechen, was die Parteien semantisch im Vertragstext festgehalten haben. Zudem darf die Klausel keine Abläufe vorsehen, über die die Parteien überhaupt keine Abrede getroffen haben. Dies führt für Vertragsgestaltende zu einer doppelten Herausforderung: Einerseits müssen sie sicherstellen, dass die Parteien im Vertragstext eine möglichst umfassende Regelung hinsichtlich der Abwicklung des Vertrages getroffen haben oder sich die Abwicklungsmodalitäten jedenfalls aus dem subsidiär geltenden Gesetzesrecht ableiten lassen, sodass sich die Programmierenden des Smart Contracts darauf beschränken können, die vereinbarten Modalitäten IT-technisch umzusetzen. Andererseits muss sichergestellt sein, dass für den Fall einer Divergenz zwischen dem Inhalt des Papiervertrages und den im Smart Contract festgehaltenen Abläufen eine klare Vorrangregelung im Papiervertrag geschaffen wird. Dabei scheint jedenfalls die Regelung rechtlich unbedenklich zu sein, nach der im Zweifelsfall die Regelungen des Papiervertrages vorgehen, sodass der Smart Contract gegebenenfalls ausgesetzt oder umprogrammiert werden müsste. Schwieriger vor dem Hintergrund des § 305c Abs. 1 BGB ist es dagegen, wenn die Vorrangregelung festhält, dass der Inhalt des Smart Contract vorgehen soll, da in diesem Falle die Vertragsgegenseite keinen Überblick mehr über den Inhalt der Abwicklungsmodalitäten hätte. Gleichwohl erscheint auch eine solche Regelung dann realisierbar, wenn im Vertrag gleichzeitig festgehalten würde, dass der Vorrang des Smart Contract im Falle von Abweichungen von den Regelungen im Papiervertrag gleichzeitig zu einem Leistungsbestimmungsrecht des Verwenders im Sinne von §§ 315 ff. BGB führte. Die Vertragsgegenseite wäre dadurch geschützt, dass nach § 315 Abs. 1 BGB die Leistungsbestimmung im Zweifel nach billigem Ermessen zu treffen ist.

Ist die Schnittstelle zwischen Papiervertrag und Smart Contract mit Blick auf die rechtssichere Einbeziehung des Algorithmus in den Vertrag geklärt, muss näher in den Blick genommen werden, in welchem Umfang eine (Teil-)Automatisierung der Vertragsabwicklung mit algorithmischen Instrumenten überhaupt möglich ist und wie diese Abwicklung konkret gestaltet werden kann.

„Denn eine Automatisierung bringt wenig, wenn es zu viele Friktionen zwischen der Rechtslage und den Regeln der Software gibt. Automatische Rechtsdurchsetzungsmechanismen eignen sich daher vor allem für den Vollzug von Tatbeständen, deren Voraussetzungen sich im Internet der Dinge nahezu fehlerfrei prüfen lassen, die dem Rechtsanwender nur geringe Wertungsmöglichkeiten einräumen und deren Rechtsfolge sich automatisch auslösen lässt – etwa durch die Sperrung oder Freigabe von Gegenständen oder durch die Einziehung und Auszahlung eines Geldbetrags.“ (Fries 2019, S. 901, 902)

Insgesamt eignen sich Vertragsklauseln, die weniger komplexe Regelungen enthalten und aufwertende Adjektive oder Adverbien verzichten, besser zur Automatisierung als solche Verträge, die sich eines komplexen juristischen Vokabulars bedienen, um den Gegenstand der vertraglichen Pflichten der Parteien zu beschreiben (Patel et al. 2018, S. 153). Abstrakt unterscheidet die Literatur zwischen den operationalen Klauseln eines Vertrages und den nicht operationalen Klauseln (ISDA und Linklaters 2017; ebenso aus der Sicht des Schweizer Rechts (Gillioz 2019, S. 16)). Operationale Klauseln folgen einer Konditionallogik. Sie bilden eine „Wenn-dann-Beziehung“ ab (diese Einschränkung auf „Wenn-dann-Beziehungen“ hebt auch schon Guerlin (2017, S. 512) hervor). Nicht-operationale Klauseln hingegen sind solche, die sich auf die rechtliche Beziehung der Parteien im Weiteren beziehen, und nicht lediglich als „Wenn-dann-Regelung“ interpretiert werden können und daher Wertungen enthalten. Nur operationale Klauseln können mittels Aussagenlogik dargestellt werden.

Der Anwendungsbereich von Smart Contracts ist daher keinesfalls auf Bauverträge beschränkt. Die vom Forschungsverbund geführten Untersuchungen haben jedoch gezeigt, dass eine automatisierte Abwicklung nur dann infrage kommt, wenn das Vertragsverhältnis hinsichtlich der zu automatisierenden Teile in seiner Komplexität möglichst reduziert worden ist. Die Kunst des Vertragsgestalters wird bei der Beratung von Parteien, die sich eines Smart Contracts bedienen wollen, also darin bestehen, bereits vorhandene „Wenn-dann-Beziehungen“ zu identifizieren und gegebenenfalls komplexere Vertragsstrukturen auf eine einfache Konditionallogik herunterzubrechen. Hierbei muss die Praxis ein Gespür dafür entwickeln, ob Automatisierbarkeit überhaupt vorliegt und ob die Effizienzgewinne durch automatisierte Abwicklung nicht durch langfristige Auseinandersetzungen über das konkret gewählte Vertragskonstrukt zunichtegemacht werden.

In der Vertragsgestaltung ist darauf zu achten, dass sinnvolle Schnittstellen zwischen der analogen Vertragsabwicklung, die auf den Input der Vertragsparteien angewiesen ist, und dem automatischen Ablaufen des Smart Contract gebildet werden. Wenn etwa in einem Vertragsverhältnis nicht nur der Zahlungsvorgang automatisiert werden soll, sondern auch die Mängelhaftung, muss darauf geachtet werden, wo im Einzelfall noch manueller Input der Vertragsparteien notwendig sein wird. Dies sei am Beispiel der Kaufmängelgewährleistung illustriert: Möchte etwa ein Autohaus seine Mängelgewährleistung gegenüber den Kunden teilautomatisieren, müsste der hierfür eingesetzte Smart Contract einige Tatbestandsmerkmale der Mängelhaftung überprüfen, die nicht ohne Weiteres einer konditionalen Logik unterliegen, also keine einfache „Wenn-dann-Beziehung“ darstellen. Zuerst einmal müsste festgestellt werden, dass ein bestimmter Wagen einen Sachmangel im Sinne von § 434 BGB aufweist. Dafür müsste das Programm eigenständig entscheiden können, ob die Ist-Beschaffenheit des Wagens von der vertraglich geschuldeten Soll-Beschaffenheit abweicht. Bereits dieser Vorgang ist mit mehreren Wertungen verbunden, insbesondere muss der konkrete Kaufvertrag zwischen den Parteien analysiert und ausgelegt werden. Sollte es in diesem Vertrag keine sogenannte Beschaffenheitsvereinbarung geben, müsste festgestellt werden, dass sich der Wagen für die „gewöhnliche Verwendung“ im Sinne des § 434 Abs. 1 S. 2 Nr. 2 BGB eignet. Bereits diese ersten Schritte kann ein Smart Contract – jedenfalls ohne die Unterstützung einer Künstlichen Intelligenz – nicht leisten. Die Vertragsgestaltung könnte aber vorsehen, dass ein bestimmtes automatisiertes Regime in Gang gesetzt wird, wenn von außen der Input in das System gegeben wird, dass ein Sachmangel des verkauften Wagens vorliegt. Hierbei muss freilich definiert werden, wer diesen Input geben kann (etwa eine Mängelanzeige durch den Käufer und eine entsprechende Mängelbestätigung durch den Verkäufer). Auf dieser Grundlage wäre es dann möglich, die weiteren Rechte des Käufers bei Mängeln gegebenenfalls teilautomatisiert ablaufen zu lassen. Dies wäre jedenfalls vorstellbar, wenn der Verkäufer mit dem Käufer vereinbart hätte, dass im Zuge der Mängelgewährleistung regelmäßig eine Minderung des Kaufpreises infrage kommt (Schnell und Schwaab 2021, S. 1091, 1096 weisen ebenfalls darauf hin, dass es sinnvoll sein kann, Leistungsstörungsrechte, die sich nicht automatisiert abwickeln lassen, vertraglich zu begrenzen oder sogar ganz auszuschließen). Dann könnte auf Grundlage einer Mängelanzeige automatisch eine Teilrückzahlung des Kaufpreises an den Käufer erfolgen, vorausgesetzt der Mangel ist im Vorhinein bereits monetär bewertet worden. Dabei muss bei Verbrauchergeschäften allerdings im Einzelfall darauf geachtet werden, ob eine entsprechende Vereinbarung möglich ist oder zwingendes Gesetzesrecht entgegensteht. Dieses Beispiel soll verdeutlichen, dass in Smart Contracts zwar ein großes Potenzial steckt, das mit einer umsichtigen Vertragsgestaltung aktiviert werden kann. Zugleich zeigt es aber auch, dass Sensibilität hinsichtlich der Grenzen der Leistungsfähigkeit von Smart Contracts bestehen muss.

Unternimmt die für die Nachbesserung verantwortliche Partei nicht innerhalb der vertraglich vorgesehenen Frist die entsprechenden Schritte, sind mehrere Optionen denkbar:Sollte es zu einem automatischen Leistungsaustausch aufgrund des Smart Contracts kommen, der nach den vertraglichen Regelungen insgesamt nicht intendiert war, kann auch hier die Vertragsgestaltung bereits vorbeugend abhelfen, indem vertragliche Rückgewähransprüche für den Fall einer nicht intendierten Transaktion statuiert werden (Fries (2018, S. 86, 90) geht davon aus, dass Gerichtsprozesse in der Zukunft bei Verwendung von Smart Contracts Bereicherungsansprüche aufgrund von Vollzugsfehlern der Software, die sich aus Mängeln des eingespeisten Datenmaterials ergeben, zum Hauptgegenstand haben werden. Dem sollte durch eine vorausschauende Vertragsgestaltung vorgebeugt werden).