Lost in Translation – Rechtliche Herausforderungen von Smart Contracts

„Code is law" – dieser Satz des Rechtsprofessors Lawrence Lessig ist zum geflügelten Wort der Blockchain-Bewegung geworden. Er beschreibt eine Welt, in der Regeln nicht mehr von Gerichten ausgelegt, sondern von Computerprogrammen unerbittlich durchgesetzt werden. Smart Contracts scheinen genau das zu versprechen: automatische, unparteiische, unveränderliche Vertragsabwicklung, frei von Intermediären. Doch die Realität ist komplizierter. Denn das Recht – das deutsche wie das europäische – hat die Existenz von Smart Contracts bisher kaum zur Kenntnis genommen. Was entsteht, wenn eine Welt, die auf Auslegung, Billigkeit und Interessenabwägung gebaut ist, auf eine Technologie trifft, die weder Gnade noch Kontext kennt? Eine juristische Bestandsaufnahme.

Was ist ein Smart Contract überhaupt – rechtlich betrachtet?

Technisch gesehen ist ein Smart Contract ein auf einer Blockchain gespeichertes Computerprogramm, das automatisch ausgeführt wird, sobald vordefinierte Bedingungen eintreten. Zahlt Person A einen bestimmten Betrag in Kryptowährung, überträgt der Contract automatisch ein digitales Gut an Person A – ohne Notар, ohne Bank, ohne menschliches Eingreifen. Der Begriff „Smart Contract" ist dabei irreführend: Es handelt sich weder zwingend um etwas „Intelligentes" noch notwendigerweise um einen „Vertrag" im Rechtssinne.

Im deutschen Privatrecht ist ein Vertrag das Ergebnis zweier übereinstimmender Willenserklärungen (§ 145 ff. BGB). Der Smart Contract ist aber zunächst nur Code – eine Abfolge von Wenn-Dann-Anweisungen, die mechanisch abläuft. Ob hinter diesem Code ein rechtswirksamer Vertrag steht, hängt davon ab, ob die Parteien eine entsprechende Willenserklärung abgegeben haben. Ein Smart Contract kann ein Vertrag sein, muss es aber nicht. Er kann ein Vertrag sein, der per Code erfüllt wird; er kann ein Werkzeug sein, das einem Vertrag dient; oder er kann ein reines Automatisierungssystem ohne rechtliche Bindungswirkung sein.

Die Rechtswissenschaft unterscheidet daher zwischen „Smart Contracts" im technischen Sinne und „Smart Legal Contracts" – also solchen, die bewusst eine rechtliche Vereinbarung kodieren. Die meisten DeFi-Protokolle fallen eher in die erste Kategorie: Sie sind technische Systeme, über deren Rechtsqualität sich die Parteien selten im Klaren sind.

Einbeziehung ins BGB: Willenserklärung, Angebot und Annahme

Das Bürgerliche Gesetzbuch kennt keine spezifische Regelung für Smart Contracts. Die allgemeinen Vertragsregeln gelten grundsätzlich auch hier – aber ihre Anwendung wirft praktische Fragen auf. Ein Vertrag kommt zustande, wenn Angebot und Annahme übereinstimmen (§§ 145, 147 BGB). Im Smart-Contract-Kontext stellt sich die Frage: Ist das Deployen eines Contracts durch den Entwickler ein Angebot? Ist das Interagieren eines Nutzers mit dem Contract die Annahme? Wann genau liegt eine Willenserklärung vor, wenn die einzige Handlung des Nutzers das Signieren einer On-Chain-Transaktion mit seinem Private Key ist?

Die herrschende Meinung in der deutschen Rechtsliteratur geht davon aus, dass das Interagieren mit einem Smart Contract – also das Einleiten einer Transaktion – als konkludente Willenserklärung gewertet werden kann, sofern der Nutzer die Bedingungen des Contracts kennt oder kennen musste. Problematisch ist dabei die Transparenz: Die meisten Nutzer lesen weder den Smart-Contract-Code noch die technische Dokumentation. Hier greift ein klassisches vertragsrechtliches Problem: Wer nicht weiß, was er signiert, kann keine wirksame Willenserklärung abgegeben haben – zumindest nicht mit dem gebotenen informierten Konsens.

Hinzu kommt die Frage der Geschäftsfähigkeit (§ 104 ff. BGB). Öffentliche Blockchains haben keinerlei Altersverifikation. Ein 15-Jähriger, der ETH in einen DeFi-Contract einzahlt, gibt möglicherweise eine beschränkt wirksame Willenserklärung ab – mit allen Konsequenzen für den Vertragspartner.

Formvorschriften: Wenn Code nicht ausreicht

Das BGB kennt für bestimmte Rechtsgeschäfte Formvorschriften: Notarielle Beurkundung für Grundstückskäufe (§ 311b BGB), Schriftform für Bürgschaften (§ 766 BGB), Textform für bestimmte Verbraucherverträge. Ein Smart Contract, der einen dieser Sachverhalte automatisiert, stößt unweigerlich an diese Grenzen. Ein auf der Blockchain vollzogener „Verkauf" einer tokenisierten Immobilie mag technisch in Sekunden abgewickelt sein – rechtswirksam ist er ohne notarielle Beurkundung nicht. Das Grundbuch bleibt entscheidend; die Blockchain-Transaktion ist kein Surrogat.

Für elektronische Verträge existiert seit der E-Commerce-Richtlinie (2000/31/EG) und dem Gesetz über elektronische Handelsgeschäfte ein gewisser Rahmen. Die qualifizierte elektronische Signatur (QES) nach der eIDAS-Verordnung ist dabei das digitale Äquivalent zur eigenhändigen Unterschrift – doch die typische Blockchain-Wallet-Signatur mit einem privaten Schlüssel ist keine QES im Sinne von eIDAS. Sie ist eine kryptographische Signatur, aber keine rechtlich anerkannte elektronische Signatur im engeren Sinne, weil die Identitätsprüfung fehlt.

MiCA und die neue Regulierungsebene für Krypto-Assets

Mit der EU-Verordnung über Märkte für Kryptowerte (MiCA, Markets in Crypto-Assets Regulation), die seit Juni 2023 in Kraft ist und seit Ende 2024 vollständig gilt, hat Europa einen ersten umfassenden Regulierungsrahmen für den Kryptobereich geschaffen. MiCA reguliert primär die Ausgabe und den Handel von Kryptowerten und adressiert damit einen wichtigen Kontext, in dem Smart Contracts operieren – ohne Smart Contracts selbst direkt zu regulieren.

MiCA gilt für Emittenten von Kryptowerten und Anbieter von Krypto-Dienstleistungen (CASPs, Crypto-Asset Service Providers). Wer eine neue Kryptowährung herausgibt, ein Stablecoin emittiert oder einen Kryptohandelsplatz betreibt, braucht eine Zulassung und muss Whitepapers veröffentlichen, Eigenkapitalanforderungen erfüllen und Compliance-Prozesse implementieren. Smart Contracts, die solche Funktionen automatisieren – etwa ein automatisierter Market Maker (AMM) wie Uniswap –, befinden sich in einer regulatorischen Grauzone: Sie sind keine CASP im traditionellen Sinne, da sie keinen Betreiber im klassischen Sinn haben.

Die Europäische Wertpapier- und Marktaufsichtsbehörde (ESMA) hat klargestellt, dass vollständig dezentralisierte Protokolle ohne identifizierbaren Emittenten oder Anbieter aus dem MiCA-Anwendungsbereich herausfallen können – aber eben nur dann, wenn sie wirklich dezentralisiert sind. In der Praxis haben die meisten DeFi-Protokolle Entwicklerteams, Governance-Token-Inhaber oder Multisig-Kontrolleure, die als faktische Anbieter angesehen werden könnten. Die Grenzen werden in den kommenden Jahren durch Aufsichtspraxis und Gerichtsurteile gezogen werden.

Haftung bei Fehlern im Code: Wer zahlt, wenn der Contract falsch rechnet?

Im Juni 2016 wurde die DAO (Decentralized Autonomous Organization) auf Ethereum durch einen Reentrancy-Angriff geleert: Ein Angreifer nutzte eine Schwachstelle im Smart-Contract-Code aus und zog rund 60 Millionen US-Dollar in ETH ab. Die technische Frage war schnell beantwortet – der Code hatte einen Bug. Die rechtliche Frage ist bis heute ungeklärt: Wer hätte dafür gehaftet?

Im deutschen Recht kommen verschiedene Haftungsgrundlagen in Betracht. Eine vertragliche Haftung (§ 280 BGB) setzt voraus, dass zwischen Angreifer/Opfer und dem Contract-Entwickler eine vertragliche Beziehung besteht. Das ist bei Open-Source-Protokollen, die anonym entwickelt und deployed werden, kaum gegeben. Eine deliktische Haftung nach § 823 Abs. 1 BGB erfordert die schuldhafte Verletzung eines absolut geschützten Rechtsguts – Vermögensschäden allein sind nur unter engen Voraussetzungen des § 823 Abs. 2 BGB (Schutzgesetze) oder § 826 BGB (vorsätzliche sittenwidrige Schädigung) ersatzfähig.

Das Produkthaftungsgesetz (ProdHaftG), das die EU-Produkthaftungsrichtlinie umsetzt, galt traditionell für körperliche Produkte. Eine Reform der EU-Produkthaftungsrichtlinie (2024/2853/EU), die seit 2024 in Kraft ist, bezieht nun explizit Software und KI-Systeme ein. Smart Contracts könnten daher künftig als fehlerhafte Software unter das Produkthaftungsregime fallen – vorausgesetzt, ein identifizierbarer Hersteller oder Inverkehrbringer existiert. Bei anonym deployed Contracts ist auch das problematisch.

Die Praxis hat gezeigt, dass Projektteams oft versuchen, Haftung durch Disclaimers auszuschließen: „Use at your own risk." Im deutschen Recht sind solche Haftungsausschlüsse in AGB (§ 305 ff. BGB) gegenüber Verbrauchern stark eingeschränkt und bei grobem Verschulden gänzlich unwirksam (§ 309 Nr. 7 BGB). Ein Haftungsausschluss für Bugs in einem Smart Contract, der Millionen Euro verwaltet, dürfte einer AGB-Kontrolle kaum standhalten.

Das Oracle-Problem: Wenn die Außenwelt in den Vertrag kommt

Smart Contracts auf einer Blockchain sind von Natur aus geschlossene Systeme. Sie können auf Daten reagieren, die auf der Blockchain selbst liegen – aber nicht auf Ereignisse der Außenwelt. Um externe Daten einzuspeisen, werden sogenannte Oracles verwendet: Dienste, die Daten wie Börsenkurse, Wetterdaten oder Ereignisergebnisse in die Blockchain übertragen. Diese Oracles sind die Achillesferse vieler Smart-Contract-Anwendungen – technisch und rechtlich.

Das Oracle-Problem hat eine rechtliche Dimension, die über Technik hinausgeht: Wenn ein Smart Contract automatisch Zahlungen auslöst, sobald ein Oracle einen bestimmten Preis meldet, und das Oracle fehlerhafte Daten liefert, stellt sich die Frage der Haftung. Wer ist verantwortlich – der Oracle-Anbieter, der Contract-Entwickler oder der Nutzer, der auf die Korrektheit vertraut hat? In der Rechtsprechung fehlen hierzu Präzedenzfälle.

Darüber hinaus stellt sich die Frage, ob eine Vertragsklausel, die auf ein Oracle verweist, dem deutschen Recht standhält. Das Risiko manipulierter Oracle-Daten (sogenannte Oracle Manipulation Attacks) ist in DeFi-Protokollen gut dokumentiert. Ein Vertrag, der eine derartige Manipulation als „vertragsgemäße Erfüllung" behandelt, weil der Code es so vorsieht, mag technisch korrekt ausgeführt worden sein – rechtlich ist die Zahlung auf Basis manipulierter Daten möglicherweise kondiktionsfähig (§ 812 BGB, ungerechtfertigte Bereicherung). Der Auslöser der Zahlung – ein falsches Signal des Oracles – war kein willentlicher Akt des vermeintlichen Schuldners.

Jurisdiktionsprobleme: Welches Recht gilt auf der Blockchain?

Blockchain-Netzwerke kennen keine Staatsgrenzen. Ein Smart Contract auf Ethereum läuft auf Knoten in Deutschland, den USA, Singapur und überall auf der Welt gleichzeitig. Wenn ein Schweizer Nutzer mit einem US-amerikanischen DeFi-Protokoll interagiert, dessen Entwicklerteam anonym ist, und Schaden entsteht – welches Recht gilt? Welche Gerichte sind zuständig?

Im deutschen internationalen Privatrecht gilt die EU-Verordnung Rom I für vertragliche Schuldverhältnisse. Parteien können das anwendbare Recht grundsätzlich wählen (Art. 3 Rom I). Smart Contracts enthalten jedoch selten eine explizite Rechtswahlklausel. Fehlt diese, bestimmt sich das anwendbare Recht nach dem Recht des Staates, mit dem der Vertrag die engste Verbindung aufweist (Art. 4 Rom I) – ein Kriterium, das bei anonymen, global verteilten Blockchains kaum handhabbar ist.

Für deliktische Ansprüche gilt die Rom-II-Verordnung: Maßgeblich ist in der Regel das Recht des Staates, in dem der Schaden eintritt (Art. 4 Rom II). Da Kryptowällen digitale Konstrukte ohne physischen Ort sind, ist selbst dieses Kriterium streitbar. Gerichtsstandsklauseln in Smart Contracts sind technisch schwer zu implementieren und für Verbraucher in vielen Fällen unwirksam (Art. 19 EuGVVO).

In der Praxis bedeutet dies: Wer durch einen Smart Contract geschädigt wird, steht vor dem Problem, dass Klagemöglichkeiten faktisch leer laufen. Selbst wenn ein Gericht in Deutschland zuständig ist und deutschen Schadensersatz zuspricht, fehlt es oft an vollstreckbarem Vermögen eines Beklagten – der möglicherweise anonym ist und dessen Assets sich in dezentralen Wallets befinden.

DSGVO versus Blockchain-Immutabilität: Ein unauflöslicher Konflikt?

Die EU-Datenschutz-Grundverordnung (DSGVO) gewährt betroffenen Personen unter anderem das Recht auf Löschung ihrer personenbezogenen Daten (Art. 17 DSGVO), das „Recht auf Vergessenwerden". Blockchains sind jedoch konzeptionell auf Unveränderlichkeit ausgelegt: Was einmal in einen Block geschrieben ist, bleibt – zumindest in öffentlichen Permissionless-Blockchains – dauerhaft erhalten.

Dieser Gegensatz ist kein rein theoretisches Problem. Wenn ein Smart Contract personenbezogene Daten verarbeitet – etwa einen Namen, eine Adresse, eine Gesundheitsinformation, die zur Vertragserfüllung notwendig ist –, und diese Daten on-chain gespeichert werden, entsteht ein struktureller Konflikt. Die DSGVO verlangt, dass personenbezogene Daten gelöscht werden können, wenn kein legitimer Zweck mehr besteht. Die Blockchain lässt genau das nicht zu.

Die Datenschutzkonferenz (DSK) und die Artikel-29-Datenschutzgruppe (Vorläufer des Europäischen Datenschutzausschusses) haben sich mit dieser Frage befasst, ohne einen abschließenden Ausweg zu bieten. Technische Lösungsansätze existieren: Off-chain-Speicherung personenbezogener Daten mit on-chain gespeicherten Hashes; Verschlüsselung der Daten, sodass eine Löschung durch Vernichtung des Schlüssels emuliert wird (sogenanntes „Crypto-Shredding"). Ob diese Methoden der DSGVO-Definition der Löschung genügen, ist rechtlich umstritten. Die Aufsichtsbehörden in verschiedenen EU-Ländern – darunter die CNIL in Frankreich und die BfDI in Deutschland – haben noch keine konsistente Linie gefunden.

Zusätzlich stellt sich die Frage der Verantwortlichkeit. Die DSGVO setzt einen Verantwortlichen (Art. 4 Nr. 7 DSGVO) voraus – eine natürliche oder juristische Person, die allein oder gemeinsam mit anderen über Zwecke und Mittel der Datenverarbeitung entscheidet. Bei einem autonomen Smart Contract ohne identifizierbaren Betreiber fehlt ein solcher Verantwortlicher. Das europäische Datenschutzrecht hat keine Antwort auf eine Technologie, die strukturell keinen Verantwortlichen kennt.

Der Rechtsstatus von DAOs: Zwischen Verein und Wildwuchs

Dezentrale autonome Organisationen (DAOs) sind die organisatorische Manifestation des Smart-Contract-Gedankens: Gruppen von Menschen, die sich durch Token-Besitz zusammenfinden und kollektive Entscheidungen on-chain abstimmen, die dann automatisch von Smart Contracts umgesetzt werden. DAOs verwalten mitunter Milliardenwerte – die größten DeFi-DAOs wie MakerDAO oder Uniswap DAO haben Treasuries, die mit mittelgroßen Unternehmen vergleichbar sind.

Das deutsche Recht kennt keine DAO-Rechtsform. Ohne eigene Rechtspersönlichkeit sind DAOs nach herrschender Meinung als Gesellschaft bürgerlichen Rechts (GbR, §§ 705 ff. BGB) oder – bei gemeinschaftlichem Zweck ohne Gewinnerzielungsabsicht – als nicht rechtsfähiger Verein zu qualifizieren. Beide Konstruktionen haben erhebliche Konsequenzen: Bei einer GbR haften alle Gesellschafter (also potenziell alle Token-Holder) gesamtschuldnerisch und unbeschränkt für Verbindlichkeiten der DAO. Ein Token-Holder, der nie an einer einzigen Abstimmung teilgenommen hat, könnte theoretisch für Schulden der DAO haftbar sein.

Einige DAOs versuchen, dieses Problem durch die Gründung von Wrapper-Entitäten zu lösen: Eine LLC in Wyoming (die seit 2021 DAOs explizit anerkennt), eine Stiftung in der Schweiz, eine Genossenschaft in Deutschland, die als Hülle für die DAO-Aktivitäten dient. Diese Lösung funktioniert teilweise, schafft aber eine hybride Governance-Struktur, die das dezentrale Versprechen der DAO untergräbt und zugleich neue Regulierungsrisiken eröffnet.

In Deutschland hat die Einführung der Gesellschaft mit beschränkter Haftung nach dem MoPeG (Gesetz zur Modernisierung des Personengesellschaftsrechts, 2024) die GbR mit Registrierung und Rechtsfähigkeit ausgestattet – ein kleiner Schritt, der DAO-ähnlichen Strukturen mehr rechtliche Planungssicherheit geben könnte, aber kein maßgeschneidertes Konzept für DAOs darstellt.

Praktische Fallstricke: Was Entwickler und Unternehmen beachten müssen

Für Entwickler, die Smart Contracts entwerfen, und Unternehmen, die sie einsetzen wollen, ergeben sich aus den skizzierten Problemfeldern konkrete Handlungsempfehlungen. Zunächst zur Vertragsgestaltung: Ein Smart Contract allein ersetzt keinen rechtswirksamen Vertrag. In der Praxis empfiehlt sich eine hybride Struktur: ein konventioneller Rahmenvertrag in Schriftform, der die Parteien, die Rechtsordnung und den Streitbeilegungsweg festlegt, und der Smart Contract als dessen technisches Ausführungsmittel. Das ist kein Rückschritt hinter die Idee des Smart Contract – es ist juristische Hygiene.

Beim DSGVO-Compliance-Check sollte die Faustregel gelten: Personenbezogene Daten gehören nicht on-chain. Wo das unvermeidlich erscheint, sollte Crypto-Shredding-Design von Anfang an eingeplant werden. Die Datenschutzfolgenabschätzung (Art. 35 DSGVO) ist bei neuartigen Blockchain-Anwendungen in der Regel obligatorisch.

Hinsichtlich der Haftungsfrage sollten professionelle Audits von Sicherheitsfirmen (wie Trail of Bits, OpenZeppelin, Certik) für jeden Smart Contract, der signifikante Werte verwaltet, selbstverständlich sein. Fehlerhafte Audits schützen nicht vollständig vor Haftung, dokumentieren aber die angemessene Sorgfalt. Bug-Bounty-Programme und Governance-Mechanismen für Emergency-Pauses (sogenannte „Circuit Breaker") sind zusätzliche Schichten professionellen Risikomanagements.

Zur Jurisdiktionsfrage: Rechtswahlklauseln und Gerichtsstandsvereinbarungen sollten, wo immer möglich, explizit in begleitende Off-chain-Dokumente oder zumindest in die Dokumentation des Protocols aufgenommen werden. Schiedsgerichtsklauseln können für B2B-Konstellationen sinnvoller sein als staatliche Gerichtsbarkeit, da Schiedssprüche international leichter vollstreckbar sind (New Yorker UN-Übereinkommen).

Fallbeispiele aus der Praxis

Der DAO-Hack von 2016 ist das bekannteste Beispiel für die Konsequenzen eines Smart-Contract-Fehlers. Die Ethereum-Community entschied sich für einen Hard Fork, um die gestohlenen Gelder zurückzubringen – eine Entscheidung, die die Unveränderlichkeits-These der Blockchain fundamental erschütterte und zur Abspaltung von Ethereum Classic führte. Rechtlich war dieser Fork eine Entscheidung ohne klare Rechtsgrundlage, die zeigt, dass die Community im Ernstfall die reale Welt nicht aus der Kette halten kann.

Im Fall Ooki DAO (früher bZx) hat die US-amerikanische Commodity Futures Trading Commission (CFTC) 2022 erstmals erfolgreich eine Vollstreckungsmaßnahme gegen eine DAO als unincorporated association durchgesetzt und deren Token-Holder in die Haftung einbezogen. Dieses Urteil hat keine unmittelbare Bindungswirkung in Deutschland, ist aber ein deutliches Signal dafür, wie Regulatoren zunehmend willens sind, die juristische Person DAO aufzudröseln.

Im europäischen Raum hat die spanische Datenschutzbehörde (AEPD) 2023 ein Unternehmen, das biometrische Daten auf einer öffentlichen Blockchain gespeichert hatte, wegen Verstoßes gegen die DSGVO sanktioniert – ein Präzedenzfall, der zeigt, dass europäische Aufsichtsbehörden die DSGVO-Konformität von Blockchain-Anwendungen aktiv prüfen.

Ausblick: Wird das Recht die Blockchain einholen?

Die Rechtsentwicklung hinkt der Technologieentwicklung naturgemäß hinterher. Dennoch gibt es Anzeichen für eine steigende Regulierungsbereitschaft und -kapazität. MiCA ist ein erster Schritt auf EU-Ebene. Der AI Act (KI-Verordnung, 2024/1689/EU) enthält Vorschriften, die für KI-gesteuerte Smart Contracts relevant werden könnten. Die Reform der Produkthaftungsrichtlinie bezieht Software explizit ein. Und die DLT-Pilotregelung (2022/858/EU) schafft einen regulatorischen Sandkasten für Blockchain-basierte Wertpapierinfrastrukturen.

In Deutschland hat das eWpG (Gesetz über elektronische Wertpapiere) seit 2021 kryptobasierte Wertpapiere rechtlich anerkannt. Die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) hat erste Krypto-Verwahrlizenzinhaber zugelassen und akkumuliert Expertise in diesem Bereich. Das sind kleine, aber bedeutsame Schritte in Richtung eines kohärenten Rechtsrahmens.

Die eigentliche Herausforderung liegt jedoch nicht nur im Regulieren, sondern im Umdenken. Das klassische Rechtssystem ist auf das Vorhandensein identifizierbarer Akteure, verortbarer Handlungen und reversiblen Zustände aufgebaut. Smart Contracts untergraben alle drei Prämissen: Akteure können anonym sein, Handlungen sind global verteilt, und einmal ausgeführte Transaktionen sind prinzipiell unveränderlich. „Code is law" mag eine attraktive Parole sein – aber in einem Rechtsstaat sind Gesetze keine Zeilen Solidity-Code. Solange diese Lücke nicht überbrückt ist, bleibt jeder Smart Contract ein kleines Experiment am Rand des Rechts.