Smart Contracts und Haftung der Parteien

1) Einführung

Ein intelligenter Vertrag automatisiert die Ausführung von Vereinbarungen, beseitigt jedoch nicht die rechtliche Haftung. Im Gegenteil: Code, Changemanagement und Betriebsverfahren schaffen neue Risikozonen - von Schwachstellen und Orakelmanipulationen bis hin zu Konflikten bei Upgrades und Netzwerkgabeln. Dieser Artikel gibt einen Rahmen für die Verteilung der Rollen und Verantwortlichkeiten und eine Reihe von vertraglichen/technischen Maßnahmen, die „Code als Gesetz“ in „Code als Teil der rechtlichen Regelung“ umwandeln.

2) Schlüsselbegriffe und Abgrenzungen

Ein Smart Contract ist ein Programmcode, der in einer Blockchain nach deterministischen Regeln ausgeführt wird.
Der Betreiber ist die juristische Person, die das Protokoll oder Spiel bereitstellt/unterstützt und die Richtlinie festlegt.
Entwickler/Studio - Ersteller von Code und/oder Smart Contracts.
Infrastrukturanbieter - Orakel, Brücken, VRF/Zufall, Indexer, RPC.
Admin-Schlüssel/Rollen - Upgrade-Rechte, Parameter, „Pause/Kill-Switch“.
DAOs/Grant Holders - Inhaber von Token/Stimmen, die an der Verwaltung beteiligt sind.
Benutzer/Spieler - eine Partei, die mit dem Vertrag interagiert und Transaktions-/Volatilitätsrisiken trägt.

3) Modell der Verantwortungsverteilung (wer ist wofür verantwortlich)

Plattformbetreiber

Einhaltung lokaler Gesetze (iGaming/VASP/Zahlungsregime), KYC/AML/Sanktionen;

Veröffentlichung und Aktualisierung von ToS, Risk Disclosures, Responsible Gaming;

Incident-Management, Kommunikation, Kompensationsmechanismen, Speicherung von Protokollen.

Entwickler/Studio

Codequalität, Audit und Testabdeckung;

Begleitung von Upgrades und Migrationen, besop. Aufbewahrung von Geheimnissen;

Bugbounty, Responsible Disclosure, Post-Mortem-Analyse.

Anbieter von Orakeln/Brücken/VRF

SLO/Verfügbarkeit, Korrektheit der Daten und Anti-Manipulationsmaßnahmen;

vertragliche Garantien und Haftungsgrenzen (Cap), Incident Log, SLA.

Validatoren/Miner/Netzwerk

Gewährleistung eines Konsenses. Die Verantwortung ist in der Regel protokollarisch/dezentral, außerhalb des vertraglichen Rahmens des Projekts.

Benutzer

unabhängige Risikobewertung, Schutz privater Schlüssel, Einhaltung lokaler Gesetze;

Überbrückung von Geldern und Interaktion mit Frontends/Wallets Dritter.

DAOs/Token-Inhaber (wenn Governance)

Annahme von Risikoparametern (Limits, Provisionen), Genehmigung von Upgrades, Notfalllösungen.

4) „Code als Gesetz“ vs „Code als Vertragsbestandteil“

In der Praxis ist der Code der exekutive Teil des Vertrags: ToS und die Richtlinien bestimmen die Absicht der Parteien, das Verfahren zur Beilegung von Fehlern, Ausnahmen und die Priorität der Textnorm im Konflikt.

1. Interpretationspriorität (ToS> Spezifikation> Code? oder umgekehrt - mit klaren Ausnahmen);

2. Wie werden offensichtliche Fehler (Mistake) und „unbeabsichtigte Zustände“ interpretiert?

3. wenn ein Rollback/Patch/Pause erlaubt ist und wer die Aktion autorisiert.

5) Upgrades, Admin-Schlüssel und Vertrauen

Rollentransparenz: Listen Sie Adressen mit den Rechten 'owner', 'admin', 'guardian' auf und geben Sie an, welche Methoden für jede Rolle verfügbar sind.
Timelock & Multi-Sig: Verzögerungen vor dem Upgrade (z.B. 24-72 Stunden) und Mehrsignaturrechte reduzieren das Missbrauchsrisiko.
Notfallpause/Kill-Switch: Nutzungsvorschriften, Kriterien (kritische Verwundbarkeit, Kompromittierung des Orakels), Melde- und Erneuerungsverfahren.
Proxy-Verträge und Migrationen: Dokumentieren Sie den Prozess, lassen Sie die Benutzer aussteigen, bevor die Logik umgeschaltet wird (grace period).
Unveränderlichkeitsklausel: Wenn der On-Chain-Vertrag immutable ist, geben Sie die Einschränkungen und Konsequenzen an (Unfähigkeit, den Kreta-Bug ohne Migration von Vermögenswerten zu reparieren).

6) Externe Abhängigkeiten und Kaskadenrisiken

Preisorakel und VRF: Schutz vor Manipulation (TWAP, Repliken, Quorum of Sources), vertragliche SLAs und Haftungsgrenzen.
Brücken/Bridges: Die größten historischen Verluste sind mit Brücken verbunden - verwenden Sie TVL-Limits, Versicherungen, gestaffelte Auszahlungslimits.
RPCs/Indexer: Duplicate Provider, Health-Checks und Folbacks.
Frontend/Domain: Schutz vor Spoofing (DNSSEC, subresource integrity), öffentliche Vertragsadressen, Offline-Interaktionsweg mit dem Vertrag.

7) Risiken und deren Qualifikation

Technisch: Schwachstellen, Logikfehler, Re-Entrancy, Überläufe, falsche Rundung, MEV/Frontrunning.
Ökonomisch: Markt-/Orakelmanipulation, „Bank Run“, unhaltbare Tokenomik.
Operational: Verlust von Admin-Schlüsseln, CI/CD-Kompromittierung, menschlicher Faktor.
Legal: unlautere Werbung, keine Lizenz, Verstöße gegen Sanktionen/AML, Verbraucherschutz.
Höhere Gewalt web3: Angriffe auf L1/L2, lange Netzwerk-Outage, „sichere“ Hard Fork, katastrophale Abhängigkeitsfehler.

8) Haftungsbeschränkung und -verteilung (Vertragsklauseln)

• Disclaimer von Risiken (Volatilität, Smart Contracts, Abhängigkeiten von Drittanbietern, Risiko eines Totalverlustes von Geldern).
• Begrenzung der Haftung (Cap): Begrenzung der Gesamthaftung auf die Höhe der Provisionen/Einnahmen für X Monate oder eine feste Cap.
• No consequential damages: Ausschluss von Folgeschäden (entgangener Gewinn usw.).
• Risikoabwägung: Bestätigung der bewussten Risikobereitschaft des Nutzers.
• Indemnification: Befreiung des Betreibers von den Anforderungen, die durch die Verletzung des Gesetzes/ToS durch den Benutzer verursacht werden.
• Force-majeure (web3-Version): Netzwerkausfälle, Angriffe auf den Konsens, kritische Abhängigkeitsschwachstellen, behördliche Maßnahmen.
• Right to suspend/pause: Das Recht, Operationen vorübergehend zu stoppen, wenn die Sicherheit gefährdet ist.

9) Incident Management und Entschädigung

Policy & Playbook: Kontaktkanäle, Erstmeldezeiten (z.B. T + 24h), Status, Upgrades.
Segmentierung von Vorfällen: 'P0/P1/P2' nach Auswirkung auf Fonds/Verfügbarkeit.
Ausgleichsmechanismen: Reservepool, Versicherung, Zuschussentschädigung durch DAO, Priorität der Restitution an die Betroffenen.
Post-Mortem: Öffentlicher Bericht mit Timeline, Wurzelgrund, Korrekturmaßnahmen.
Bug Bounty & Responsible Disclosure: Gutgläubige Offenlegungsklausel, Kanäle, Belohnungsstufen.

10) Governance и DAO

Wem gehört die Verantwortung? Wenn die Entscheidungen von der DAO getroffen werden, fixieren Sie die rechtliche „Vertretung“ (Stiftung/LLC/Verein) und ihre Rolle.
Quorum und Emergency-Streams: separate Schwellenwerte für kritische Maßnahmen; Wächterdelegierte (Wächter) für eine schnelle Reaktion.
Interessenkonflikt: Offenlegung der Zugehörigkeit von Entwicklern/Validatoren/Orakeln.
DAO-Streitschlichtung ↔ Benutzer: vorläufiges Mediationsfenster, dann - Schiedsverfahren/Gericht.

11) Gerichtsstand, anwendbares Recht und Streitbeilegung

Rechtswahl (governing law) + Forum (Schiedsverfahren/Gericht, Ort, Sprache, Verfahren).
Dispositive Normen des Verbraucherrechts: Im B2C kann ein Teil der Bedingungen durch das Recht des Landes des Nutzers außer Kraft gesetzt werden.
Online Arbitrage/ODR: als schneller Mechanismus bei kleinen Streitigkeiten zulässig.
Kombinierte Modelle: technische Restitution von On-Chain + Offchain-Arbitrage zur Schadensbeurteilung.

12) Vertraulichkeit und persönliche Daten

Wenn Sie Konten/KUS haben: Datenschutzerklärung, DSGVO-Gründe, DPIA, Datenminimierung, Aufbewahrungsfristen.
Die On-Chain-Daten sind öffentlich: Beschreiben Sie die Risiken der Deanonymisierung, verteilen Sie die PII der Offchain.
Sammlung von Frontend-Telemetrie - nur mit legitimer Basis und Opt-out/Consent, wo erforderlich.

13) Compliance-Minimum für Kryptospiele/Protokolle mit echtem Wert

Lizenzen/Registrierungen: iGaming/VASP/MSB/Zahlungsmodi nach Geo.
KYC/AML/Sanktionen: Ebenen, Mittelquellen, Travel Rule (falls zutreffend).
Anzeige: Altersfilter, Disclaimer, Verbot irreführender Versprechen.
Steuern: Bilanzierung von GGR/Provisionen, Wechselkursdifferenzen, Token-Treasury.

14) Dokumentation und Artefakte (aktuell halten)

Bedingungen für Service + Risiko Disclosure + Responsible Gaming (falls zutreffend).
Smart-Contract-Specs (Invarianten, Parametergrenzen, Upgrade-Prozeduren).
Admin/Keys Policy (Multi-Sig, Timelock, Storage, Rotation).
Sicherheitspolitik (Audits, Tests, Bug Bounty, SCA/SSA).
Incident Response Policy + Benutzerbenachrichtigungsvorlage.
Oracle/Bridge SLA + vertragliche Haftungsgrenzen.
Change Log & Post-mortems (öffentliches Änderungsarchiv).

15) Haftungsmatrix (Beispiel RACI)

16) Start-Checkliste (kurz)

1. Definieren Sie Rollen/Adressen mit Rechten, aktivieren Sie timelock + multi-sig.
2. Beschreiben Sie das Upgrade-Verfahren und den „Pause/Kill-Switch“ im ToS und im README des Repositorys.
3. Führen Sie ein unabhängiges Audit durch, aktivieren Sie Bugbounty, veröffentlichen Sie den Bericht.
4. Orakel/Brücken mit SLA und TVL/Output Limits beauftragen.
5. Konfigurieren Sie die Überwachung von Invarianten (TVL, Pool-Ungleichgewichte, Orakelverzögerungen).
6. Risk Disclosures, Haftungsgrenzen (Cap), Force-Majeure vorschreiben.
7. Genehmigen Sie die Incident Policy und die Meldungsvorlage, die Ausgleichsrücklage.
8. Überprüfung der Compliance (Lizenzen, KYC/AML, Sanktionen, Steuern, Werbung).
9. Bereiten Sie einen Migrationsplan (grace period) für den Fall eines Kreta-Upgrades vor.
10. Führen Sie regelmäßig Game-Day/Chaos-Tests und Post-Mortems durch.

17) Vorlagenklauseln für ToS/Politik (Formulierungsskizzen)

• „Der Betreiber und/oder die benannten Verwahrer (Wächter) haben das Recht, die Ausführung von Smart Contracts vorübergehend auszusetzen, wenn kritische Schwachstellen identifiziert werden, gefolgt von einem öffentlichen Bericht und einem Wiederherstellungsplan“.

• "Änderungen der Vertragslogik werden über Timelock von mindestens N Stunden durchgeführt; die Adressen der Administratoren und der Änderungsverlauf werden im Repository/auf der Website veröffentlicht".

• „Die Gesamthaftung des Betreibers im Rahmen dieser Vereinbarung ist auf die Höhe der vom Nutzer in den letzten N Monaten tatsächlich gezahlten Gebühren/Zahlungen beschränkt und umfasst keine Folgeschäden“.

• „Die Parteien haften nicht für Verzögerungen/Nichterfüllung, die durch Störungen des Kernnetzes, Angriffe auf den Konsens, kritische Mängel externer Orakel/Brücken, Handlungen staatlicher Behörden verursacht werden“.

• „Die Interaktion mit Smart Contracts birgt das Risiko eines vollständigen und unwiederbringlichen Verlusts von Vermögenswerten aufgrund von Code-Schwachstellen, Konfigurationsfehlern und Marktmanipulationen“.

(Stimmen Sie den Wortlaut mit Ihrem lokalen Anwalt ab; für B2C sind verbindliche Klauseln über Verbraucherrechte möglich.)

18) Glossar

Timelock - Verzögerung vor dem Inkrafttreten von Änderungen.
Multi-sig - Multi-Signatur-Steuerung von Admin-Operationen.
Kill-Switch/Pause - Notstopp bei der Vertragserfüllung.
Invariant Monitoring - automatische Überprüfung der wichtigsten Eigenschaften des Protokolls.
RACI ist eine Haftungsverteilungs-Matrix.

Ausgabe

Die rechtliche Nachhaltigkeit von Smart Contracts basiert auf drei Säulen: (1) den klaren Rollen und Haftungsgrenzen, die sich in der öffentlichen Politik und den ToS widerspiegeln; (2) technische Disziplin - Upgrades durch Timelock/Multi-Sig, Audit, Überwachung von Invarianten, Incident Management; (3) verlässliche Vereinbarungen mit Anbietern externer Abhängigkeiten und korrekte Haftungsklauseln und höhere Gewalt. Die Kombination dieser Elemente verringert die Wahrscheinlichkeit kontroverser Situationen und legt ein vorhersehbares Verhaltensmuster der Parteien fest, selbst unter Bedingungen der Unsicherheit von web3.