Herrenlose Maschinen

Die meisten Smart Contracts auf Ethereum sind herrenlose Maschinen. Ihre Mechanismen sind transparent und unaufhaltsam. Diese Transparenz und Persistenz verbürgen eine gewisse Vorhersehbarkeit für das, was passieren wird, wenn ein Nutzer mit dem Smart Contract interagiert. Eine solche Interaktion an sich hat jedoch lediglich einen technischen Effekt und keinen rechtlichen Erklärungsinhalt. Niemand steht dafür ein, dass tatsächlich auch nur das Vorhersehbare passieren wird. Smart Contracts sind daher in der Regel keine Verträge und die Interaktion mit ihnen - für sich genommen - keine Willenserklärungen.

Ein Plädoyer für die rechtliche Neutralität von On-Chain-Transaktionen.

Vorweg: Im Folgenden geht es um Transaktionen und Smart Contracts auf öffentlichen und frei abrufbaren Blockchain-Netzwerken. Um die nachfolgenden Überlegungen konkreter fassen zu können, werden wir die Mechanismen des Ethereum Netzwerks zugrunde legen. Zudem gehen wir von der Grundkonfiguration aus, dass der Smart Contract

• nicht nachträglich verändert werden kann (keine sog. "Upgradeability", etwa über einen Proxy Contract, wie sie hier erläutert wird) und
• nicht von einem Benutzer nachträglich gelöscht werden kann (sog. "selfdestruct" Funktion, wie sie hier analysiert wird).

Übertragung von Token

Um uns der Frage nach dem rechtlichen Erklärungsinhalt von On-Chain-Transaktionen zu nähern, macht es Sinn, sich zunächst mit der wohl einfachsten Transaktionsart zu befassen: Die Übertragung eines Token. Stellen wir uns vor, der Inhaber des Public Key A überträgt einen Token an den Public Key B, an dem sich noch kein Smart Contract befindet.

Rechtsneutrale Transaktion

Zwischen dem Inhaber des Private Key A und dem Inhaber des Private Key B ist zur bloßen Durchführung dieser Transaktion keine schuldrechtliche oder dingliche Einigung notwendig.  Ein Rechtsbindungswille des Inhabers des Private Key A ist daher objektiv nicht ersichtlich. Der aus dem objektiven Empfängerhorizont erkennbare Erklärungsinhalt seiner Handlungen ist vielmehr rein technischer Natur: Der Inhaber des Private Key A (der die Transaktion signiert und an das Netzwerk sendet) möchte durch die bloße Übermittlung der Transaktion weder mit dem Inhaber des Private Key B (der den Token an seinem Public Key B empfangen wird) noch mit dem Miner (der die Transaktion in den nächsten gültigen Block aufnimmt) irgendein rechtliches Verhältnis begründen.

Der Inhaber des Public Key A möchte auch keine Rechtsposition übertragen, da der Token an und für sich keine Rechtsposition ist (vgl. etwa Lukas, Zivilrechtliche Probleme um digitale Token: Die Blockchain und ihre Werte, 2019). Rechtspositionen werden allenfalls von außen an den Token herangetragen (kritisch zum Stichwort Tokenisierung habe ich hier bereits einen Artikel veröffentlicht).

Alles, was durch Übermittlung der Transaktion in Gang gesetzt wird, erfolgt rein faktisch, weil es den Regeln der Ethereum Client Software entspricht. Wird die Transaktion von dieser Software erkannt und ausgelesen, war sie aus Sicht aller, die die gleiche Software betreiben, erfolgreich. Zur Veränderung dessen, was der Ethereum Client ausliest und welchem Public Key er die Token zuordnet, gibt es keine rechtliche Handhabe. Willensäußerungen, die auf die Änderung der Rechtslage gerichtet sind, wie dies etwa im deutschen Sacheigentum etwa nach § 929 S. 1 BGB oder zur Abtretung von Forderungen nach § 398 BGB der Fall ist, werden für eine Transaktion auf Ethereum nicht benötigt. An den Token kann keine Inhaberschaft, Besitz oder Eigentum im Rechtssinne des BGB begründet werden (statt vieler Schlund/Pongratz, Distributed-Ledger-Technologie und Kryptowährungen – eine rechtliche Betrachtung, DStR 2018, 598 (600)) . Es besteht lediglich eine rein faktische Verfügungsgewalt. Rechtliche Erklärungsinhalte müssen daher auch nicht im Wege der Auslegung in das Verhalten hineininterpretiert werden.

Legitimität

Dieses zivilrechtliche Vakuum entsteht dadurch, dass schon die Miner (oder künftig Validatoren) und die Betreiber eines Nodes keinen Rechtsbindungswillen gegenüber ihresgleichen haben. Niemand haftet, da niemand alleine den Status ändern kann. Jeder einzelne der genannten Teilnehmer, durch die das Netzwerk überhaupt erst entsteht, spielt sein eigenes Spiel, ohne dabei für die Aktionen der übrigen Spieler verantwortlich zu sein. Alleine die von allen in gleicher Weise verwendete Client Software setzt die gemeinen Regeln. Ähnlich dem Internet selbst gilt also Code is Law (Lessig, Code is Law, Harvard Magazine, 2000). Wer versucht, diese Pointe Lessigs rechtsdogmatisch zu widerlegen, übersieht den praktischen Kern der Aussage. Natürlich hat der Code keine rechtsstaatliche Legitimität. Es entsteht jedoch eine Sphäre, die zwar immer von ihren Nutzern abhängig und damit keineswegs dem Zugriff des Rechtsstaats entzogen ist, sich jedoch selbst reguliert. Der Konsens ist nicht zivilrechtlicher sondern maschineller Natur. Und diese "Maschine" hat keinen Herren.

Zugleich ist niemand an die Vorgaben dieser Maschinen gebunden: Jeder kann sie für sich nach Belieben verändern. Sie ist eben nicht rechtsverbindlich. Aber ändert der Nutzer sie einseitig, dann ist die von ihm betriebene Version seine Maschine und er spielt wahrscheinlich sehr schnell alleine. Es fehlt ihr dann an Legitimität (Buterin, The Most Important Scarce Resource is Legitimacy, vitalik.ca, 2021).

Rechtsgrund: Off-Chain

Zurück zu unserer Beispiel-Transaktion: Natürlich kann eine gesonderte schuldrechtliche Vereinbarung der subjektive Beweggrund für den Inhaber des Private Key A sein, die Transaktion überhaupt zu veranlassen. Diese zivilrechtliche Vereinbarung bestünde jedoch selbständig neben der Ethereum-Transaktion und würde nicht durch diese begründet. Fehlt es hingegen ganz an einer solchen schuldrechtlichen Vereinbarung und erfolgt die Transaktion beispielsweise irrtümlich, so kämen möglicherweise auf zivilrechtlicher Ebene bereicherungsrechtliche Rückabwicklungsansprüche des Inhabers des Public Key A gegen den Inhaber des Public Key B in Betracht. Diese wären im Einzelfall zu prüfen. Mit Überlegungen zur Frage, ob ein Token ein "etwas" ist, dass nach § 812 Abs. 1 BGB "erlangt" werden kann, möchte ich jedoch an dieser Stelle nicht langweilen. In der Praxis dürften diese Ansprüche jedenfalls oft an der Durchsetzbarkeit mangels Kenntnis des Anspruchsgegners scheitern. Selbst ein Gericht könnte niemals die Rückübertragung anordnen, wenn diese nicht nach den Regeln der Software erfolgt. Auch die vollstreckungsrechtlichen Probleme sollen an dieser Stelle nicht vertieft werden.

Halten wir also zunächst fest:

Die Übertragung eines Token von Adresse A nach Adresse B hat für sich genommen keinen rechtlichen Erklärungsinhalt, weder schuld- noch sachenrechtlich. Sie ist ein schuldrechtliches und sachenrechtliches Nichts. Für die Entstehung eines zivilrechtlichen Rahmens dieser Übertragung müssen also weitere äußere Umstände hinzutreten.

Interaktionen mit Smart Contracts

Die Interaktion mit Smart Contracts ist fast identisch mit der vorstehend erläuterten Transaktion zur Übertragung von Public Key A zu Public Key B. Der einzige Unterschied ist, vereinfacht gesagt, dass an Public Key B eben ein Smart Contract bereitgestellt ist.

Bei einem Smart Contract handelt es sich um ein Programm, das auf der Ethereum-Blockchain als Bytecode ausgeführt werden kann. Es ist eine Sammlung von Code (seine Funktionen, "functions") und Daten (sein Zustand, "state"). Smart Contracts sind zugleich eine Art Ethereum-Konto wie ein regulärer Public Key. Das bedeutet, Smart Contracts können über ein Guthaben an Ether oder verschiedenen Tokens verfügen und Transaktionen über das Netzwerk senden.

Smart Contracts werden grundsätzlich nicht von einem Benutzer gesteuert, sondern im Netzwerk bereitgestellt und wie vorprogrammiert ausgeführt. Andere Benutzer können mit dem Programm interagieren, indem sie Transaktionen übermitteln, die eine im Smart Contract definierte Funktion ausführen. Dazu bedarf es keiner bestimmten Weboberfläche, keiner Genehmigung und keines Nutzerprofils. Smart Contracts können zudem standardmäßig nicht gelöscht werden und Interaktionen mit ihnen sind irreversibel. Nähere Erläuterungen dazu finden sich hier.

Persistentes Skript

Vor dem Hintergrund dieser Eigenschaften äußerte Vitalik Buterin bereits Bedauern, den Begriff "Smart Contracts" übernommen zu haben und formulierte es im Jahr 2018 auf Twitter wie folgt:

Der Ethereum Mitgründer trifft es aus meiner Sicht exakt auf den Punkt, wenn er - und ich paraphrasiere hier - letztlich zum Ausdruck bringt, dass es sich bei Smart Contracts genauso wenig um einen Vertrag handele, wie dies etwa bei einem Türschloss der Fall sei. Er bevorzugt daher den Begriff "persistent Script".

Das Bedauern Buterins ist nachvollziehbar angesichts der Tatsache, dass die Bezeichnung "Smart Contract" sicherlich für viele Missverständnisse bei technischen Laien aber auch für Aufsehen in der Rechtsbranche gesorgt hat. Es wird die Auffassung vertreten, Smart Contracts ähnelten rechtlich als "Vertrag" zu qualifizierenden Abreden insoweit, als sie Vereinbarungen in sprachlicher Form darstellten. Allein der Sprachtyp divergiere, weil die Programmiersprache an die Stelle der natürlichen Sprache träte. Smart Contracts wichen von herkömmlichen Schuldverträgen insofern ab, als sie die Durchsetzung durch technische Mechanismen sicherstellten und sie die Leistungspflichten prinzipiell unabwendbar und unumkehrbar – eben automatisiert – vollstreckten. Sie hätten damit eine Doppelfunktion, indem sie sowohl ein Pflichtenprogramm formulierten als auch für seine Durchführung sorgten (statt vieler: Kuntz, Konsens statt Recht?, AcP 220 (2020), 51 (66)).

Derartige Darstellungen sind sicherlich in sich logisch. Es wird bei der Erörterung jedoch der zweite Schritt vor dem ersten gemacht und das aus der Bezeichnung stammende Missverständnis perpetuiert: Es erfolgt eine rechtliche Subsumption ohne Darstellung des Lebenssachverhalts. Oder es wird ein Lebenssachverhalt unterstellt, der praktisch nicht relevant ist.

Lebenssachverhalte

Natürlich ist es grundsätzlich möglich, Verträge in jeder beliebigen Sprache zu schließen. Auch einen Formzwang gibt es nur in wenigen Ausnahmefällen. Ja, es ist theoretisch denkbar, einen Vertrag in Programmiersprache zu vereinbaren, die auf der Ethereum Blockchain gespeichert wird. Allerdings dürfte dies in der Praxis ein exotischer Ausnahmefall sein.

Den Vertretern der These, Smart Contracts ähnelten rechtlich als "Vertrag" zu qualifizierenden Abreden, schwebt in der Regel ein Sachverhalt vor, bei dem Smart Contracts etwa von Banken betrieben und für Dritte zur Interaktion freigegeben werden (Wilhelm, Smart Contracts im Zivilrecht, WM 2020 Heft 39, 1807 (1809), Kuntz, Konsens statt Recht?, AcP 220 (2020), 51 (80) oder Konsortien die Smart Contracts in der Lieferlogistik einsetzen (Möslein, Smart Contracts im Zivil- und Handelsrecht, ZHR 183 (2019), 254 (262)). Diese Szenarien haben sich in der Praxis jedoch meines Wissens bisher nicht durchgesetzt. Es stellt sich auch die Frage, inwiefern eine "Blockchain" oder Smart Contracts in diesen Sachverhalten überhaupt notwendig sind. Aber das ist ein anderes Thema.

Viel spannender und praktisch relevanter ist doch die Frage, was im Falle einer typischen Interaktion eines Ethereum-Nutzers mit einem Smart Contract passiert. Hier ist der Smart Contract eben nicht zwingend in ein rechtliches Rahmenwerk eingebettet, wie es bei Banken-Plattformen und Konsortial-Blockchains der Fall ist. Täglich passieren tatsächlich zehntausende Interaktionen mit den beliebtesten Smart Contracts in "freier Wildbahn". Die Frage ist hierbei, ob bei diesen hunderttausenden Interaktionen, die eine alltägliche Wirklichkeit von Ethereum-Nutzern sind, jeweils ein Vertrag (und wenn ja, mit wem) zustande kommt. Praktisch relevant sind hier vor allem durch Smart Contracts erzeugte dezentrale Finanzanwendungen.

Besonders beliebt sind hier vor allem zwei Arten: Decentralized Lending und Exchange. Beim Lending ermöglicht ein Smart Contract grundsätzlich zwei Nutzungsweisen, die eine "besicherte Leihe" (collateralized lending) simulieren:

• Nutzer können Kryptowerte in das Liquiditätsprotokoll einzahlen. Dafür erhalten sie automatisch Protokoll-Token, die sie zu einem beliebigen Zeitpunkt wieder zurücktauschen können. Beim Rücktausch erhält der Nutzer dem seiner Anzahl an Protokoll-Token entsprechenden Anteil der dann vorhandenen Liquidität der eingezahlten Kryptowerte.
• Solange die Nutzer die Protokoll-Token halten, können sie sich andere Kryptowerte aus dem Liquiditätspool entnehmen. Solange sie diese jedoch nicht wieder zurückzahlen, können sie ihre Protokoll-Token nicht einlösen. Zudem verringert sich der Anteil der Protokoll-Token an der zurücktauschbaren Liquidität.

Beim Exchange ermöglicht ein Smart Contract ebenfalls grundsätzlich zwei Nutzungsweisen, die einen Austausch von Token simulieren (sog. Automated Market Maker - AMM oder Decentralized Exchange - DEX):

• Nutzer können - wie beim Lending - Kryptowerte in das Liquiditätsprotokoll einzahlen. Dabei zahlen sie jedoch zwei Kryptowerte, nämlich beide Seiten eines Handelspaares, ein. Dafür erhalten sie automatisch Protokoll-Token, die sie zu einem beliebigen Zeitpunkt wieder zurücktauschen können. Beim Rücktausch erhält der Nutzer dem seiner Anzahl an Protokoll-Token entsprechenden Anteil der dann vorhandenen Liquidität der eingezahlten Kryptowerte des Handelspaares.
• Jeder Dritte kann sich nun Token aus einer Seite des Handelspaares der bereitgestellten Liquidität entnehmen, wobei er hierfür den durch den Smart Contract vorgegebenen Preis in dem Kryptowert der anderen Seite des Handelspaares einzahlen muss.

Diese sehr vereinfacht zusammengefassten Mechanismen sollen nachfolgend als Beispiel für die rechtliche Würdigung dienen.

Erklärungstatbestand

Zu klären ist zunächst, ob die Interaktion mit den Funktionen eines Smart Contracts überhaupt eine Willenserklärung mit Rechtsbindungswillen seitens des Benutzers ist.

Da die Abgabe von Willenserklärungen auch konkludent erfolgen könne, wird die Auffassung vertreten, es handele sich bei der Ausführung von Smart Contracts um ein schlüssiges Verhalten, wie beispielsweise das Aufstellen einer Zapfsäule an der Tankstelle oder der Münzeinwurf in den Getränke-Automaten. Weshalb einem Programmcode, der explizit Regeln und Bedingungen statuiere, demgegenüber kein Erklärungsgehalt zukommen solle, sei nicht nachvollziehbar. Der Programmcode von Smart Contracts erfülle daher die äußere Form einer Willenserklärung (Möslein, Smart Contracts im Zivil- und Handelsrecht, ZHR 183 (2019), 254 (271)).

Der Vergleich mit einer Zapfsäule oder einem Getränke-Automaten ist jedoch irreführend. Smart Contracts werden zwar von einer Person erstmalig bereitgestellt. Sie werden jedoch in dem hier untersuchten Fall nicht durch ihren Bereitsteller beherrscht, wie dies etwa bei der Zapfsäule der Fall ist. Der Smart Contract ist in der Regel ein bloßer, leerer Mechanismus, der durch niemanden nachträglich gesteuert wird und - ohne hinzutreten weiterer Umstände - niemandem zuzurechnen ist. Jedenfalls die bloße Bereitstellung des Smart Contracts kann in diesen Fällen keine Willenserklärung darstellen. Sie ist auf keinen rechtlichen Erfolg ausgerichtet. Sie ist die rein technische Erschaffung einer herrenlosen Maschine.

Ein Smart Contract ist auch nicht einfach dem Programmierer zuzurechnen (anders Heckelmann, Zulässigkeit und Handhabung von Smart Contracts, NJW 2018, 504 (506)), denn der Programmierer muss schon nicht derjenige sein, der den Smart Contract überhaupt auf dem Netzwerk öffentlich bereitstellt. Doch auch dem erstmaligen Bereitsteller ist der Smart Contract nicht ohne weiteres als Willenserklärung zuzurechnen. Zur Bereitstellung musste gegenüber niemandem eine Erklärung abgegeben werden, als dem Netzwerk selbst, das im Beispiel von Ethereum keine Rechtspersönlichkeit besitzen dürfte. Der Smart Contract ist außerdem auf den erstmaligen Bereitsteller weder angewiesen noch muss er, wenn Dritte mit ihm interagieren, wiederum mit dem Bereitsteller oder dessen Public Keys in Verbindung stehen.

Nun ließe sich argumentieren, dass nicht die erstmalige Bereitstellung des Smart Contracts die Willenserklärung verkörpere, sondern erst das "befüllen" der Maschine mit Wirtschaftsgütern, also Tokens. Um in der Analogie zu bleiben: das Befüllen der Zapfsäule mit Benzin oder die Bestückung des Getränke-Automaten mit Getränkedosen. Die Übertragung von Token an den Smart Contract könnte also den äußeren Erklärungstatbestand einer Willenserklärung darstellen. Doch auch dieser Transaktion möchte ich die "Verkörperung" einer Willenserklärung absprechen. Hierzu verweise ich auf die Ausführungen zu Beginn des Artikels: Eine Übertragung von Tokens ist für sich genommen eine rein faktische Transaktion. Sie bedarf zu ihrer Wirksamkeit keiner rechtlichen Dimension oder gar Anerkennung. Sie hat daher ohne hinzutreten weiterer Umstände auch keinen dahingehenden objektiven Erklärungsinhalt des Absenders. Dies ist bei der Aufstellung und Befüllung einer Zapfsäule in der Regel durchaus anders: Die Tankstelle wirbt mit Leuchtreklame für ihre Leistungen, zeigt den aktuellen Preis an und lädt Kunden durch entsprechende Beschilderung ein, das Grundstück zu befahren. Es bestehen Eigentums und Besitzverhältnisse, Hausrecht und allgemeine Geschäftsbedingungen. Die Interaktion mit einem Smart Contract hingegen, beispielsweise durch Übertragung von Token an denselben, bewirkt lediglich, dass die Tokens rein faktisch den Mechanismen des Smart Contracts überlassen werden. Darin erschöpft sich die Handlung und aus ihr lässt sich darüber hinaus kein äußerer Erklärungstatbestand ableiten.

Gegen einen Rechtsbindungswillen bei der bloßen Ausführung einer Funktion des Smart Contracts oder der Übertragung von Token an diesen spricht oftmals auch die Ausgestaltung der Smart Contracts selbst. Die Gestaltung führt gerade nicht dazu, dass sich verschiedene Vertragsparteien über den Smart Contract in einem mittelbaren Leistungsaustausch befinden. Vielmehr besteht die Interaktion, wie oben anhand der Beispiele des Lending und des Exchanges geschildert, meist in der einseitigen Einzahlung von Token und dem automatisierten Erhalt eines neu erzeugten Protokoll-Tokens. Dieser Protokoll-Token kann durch seinen Inhaber wiederum frei übertragen werden. Der Einzahler hat also mit dem Protokoll-Token ein neues Krypto-Asset erhalten. Dessen Wert besteht darin, dass es in dem entsprechenden Smart Contract eine Auszahlung aus der vorhandenen Liquidität auslösen kann. Interaktionen Dritter mit dieser Liquidität sind dadurch jedoch nicht Interaktionen mit dem Inhaber des Protokoll-Tokens. Hier entsteht in jedem Fall für die Annahme eines Vertrages zwischen den Nutzern des Smart Contracts ein logischer Bruch, da der Protokoll-Token keine Rechte verkörpern kann. Er kann nur, rein technisch, eine Übertragung von Tokens aus dem Smart Contract veranlassen. Das Risiko, dass die Liquidität des Smart Contracts aus irgendeinem Grunde verbraucht wird, etwa aufgrund eines Fehlers in der Software, der von einem Dritten ausgenutzt wurde, tragen die Inhaber des Protokoll-Tokens daher rein faktisch und ohne rechtliche Grundlage.

Ginge man gleichwohl von einem Rechtsbindungswillen aus, was aus den genannten Gründen abzulehnen ist, bestünde natürlich die Frage, wann eine derartige Willenserklärung als abgegeben und als zugegangen gelten soll. Und bei wem. Probleme aufgrund der mangelnden Finalität von Transaktionen in zensurresistenten Netzwerken werden zwar erkannt, aber nicht als hinderlich für den Zugang angesehen (Heckelmann, Zulässigkeit und Handhabung von Smart Contracts, NJW 2018, 504 (506)).

Hinzutretende Umstände

Es mag jedoch unter bestimmten Umständen zu einem Vertragsschluss im Zusammenhang mit der Nutzung von Smart Contracts kommen. Dies liegt etwa dann nahe, wenn der Smart Contract über eine Art Eigentümer- oder Administrator-Funktion verfügt. Derartige Funktionen können z.B. über einprogrammierte Public Keys ausgeführt werden, die dann über die eingezahlte Liquidität verfügen oder zumindest Auszahlungen stoppen können. Der Inhaber derartiger Funktionen könnte möglicherweise, in bestimmten Szenarien, schuldrechtlichen Ansprüchen der Nutzer des Smart Contracts ausgesetzt sein. Dabei dürfte es eine Rolle spielen, unter welcher Lizenz die Software bereitgestellt wird und ob die Nutzung des Smart Contracts kostenfrei (neben den Ethereum-Transaktionskosten) geschieht.

In diesen Fällen stellt sich jedoch die Frage nach dem Inhalt der getroffenen Vereinbarung, welche den Rahmen dieses Beitrags sprengen würde. Ein wichtiger Faktor dürfte in diesem Zusammenhang die Bereitstellung einer Benutzeroberfläche sein, die der Auslösung der Transaktion einen zusätzlichen Erklärungsinhalt gibt. Weiterhin dürften sämtliche Dokumente zur Beschreibung des Codes und Darstellungen zur Funktionsweise des Smart Contracts relevant sein. Dieser Erklärungsinhalt wird jedoch objektiv nur für den Betreiber und den Nutzer der Nutzeroberfläche ersichtlich. Somit wird der zusätzliche Erklärungsinhalt in der Regel allenfalls zu einem Vertrag zwischen dem Nutzer und dem Betreiber der Nutzeroberfläche führen und nicht zu einem Vertrag zwischen den Nutzern des Smart Contracts.