Open-Source DeFi-Haftung: Warum Washington die Regeln für nicht-verwahrten Code neu schreibt

Non-custodiale Software fühlte sich früher wie neutrale Infrastruktur an. Man schrieb Code, pushte ihn auf GitHub, und wenn ihn die Leute nutzten – gut. In letzter Zeit wird die Grenze zwischen Meinungsäußerung und Dienstleistung in Echtzeit neu gezogen.

Washington nimmt genau unter die Lupe, wer verantwortlich ist, wenn Open-Source-DeFi-Code echtes Geld berührt. Nicht nur Mixer oder Stablecoins, sondern auch Front-Ends, Gebührenschalter, Governance-Befugnisse und ereignisbasierte Märkte. Die entscheidende Frage: Ab wann wird das Veröffentlichen von Code zum Betreiben eines Finanzprodukts?

Die Antwort ist noch nicht geklärt, aber das Tempo hat zugenommen. Behörden fordern öffentliche Stellungnahmen, die Branche lobbyiert zum Schutz von Entwicklern, und die Strafverfolgung will weniger Ausnahmen. Wer in DeFi baut oder betreibt, sollte jetzt aufmerksam sein – nicht erst, wenn die Regeln in Kraft treten.

Punkt Details Der regulatorische Fokus verlagert sich US-Behörden prüfen, wo die Haftung für non-custodiale DeFi-Code ansetzt, insbesondere wenn Kontrolle, Gebühren oder kuratierte Schnittstellen vorliegen. Aktive Regelgebungsfenster bestehen Die U.S. Börsenaufsichtbehörde SEC und die CFTC haben ein gemeinsames Kommentarverfahren zu Definitionen von Derivatenprodukten eröffnet, das neuartige DeFi-Märkte erfassen könnte U.S. Börsenaufsichtbehörde SEC (Pressemitteilung). Entwickler suchen sichere Grenzen Dutzende von Kryptowährung-Unternehmen haben den Kongress aufgefordert, die Schutzmaßnahmen für Open-Source-Entwickler in Section 604 des CLARITY Act zu erhalten Advisers LLP (Rechtsanalyse, 22. Juni 2026). Strafverfolgung schlägt zurück Wichtige Staatsanwaltschaften und Polizeiverbände warnten, dass Section 604 die AML-Maßnahmen und Ermittlungen schwächen könnte, wenn sie zu weit gefasst wird Gemeinsamer Brief der Strafverfolgungsbehörden (PDF) / berichtet von The Block. Debatte über Meinungsäußerung vs. Handlung ist aktuell SEC-Kommissarin Hester Peirce argumentierte, dass die bloße Veröffentlichung von Code keine Wertpapiervorschriften auslösen sollte, und legte die Haftung bei rechtswidrigen Akteuren fest Cointelegraph (Berichterstattung über Peirces Äußerungen).

Warum Regulatoren non-custodiale Code jetzt ins Visier nehmen

Einige Entwicklungen laufen zusammen.

Erstens wollen die Behörden Klarheit dort, wo DeFi sich mit der Marktstruktur überschneidet. Am 18. Juni 2026 eröffneten die U.S. Börsenaufsichtbehörde SEC und die CFTC eine gemeinsame Anfrage für öffentliche Kommentare, um die Klassifizierung von Swaps, wertpapierbasierter Swaps, gemischter Swaps und neuerer ereignisbasierter Produkte zu harmonisieren. Das Fenster läuft 60 Tage nach der Veröffentlichung im Federal Register. Das ist relevant für Preisvorhersage-Märkte, synthetische Vermögenswerte und Protokolldesigns, die wie ein Derivaten-Handelsplatz aussehen, auch wenn sie On-Chain sind. Die Pressemitteilung ist hier: U.S. Börsenaufsichtbehörde SEC (Pressemitteilung).

Zweitens diskutiert der Kongress, wie Entwickler von böswilligen Akteuren zu trennen sind. Mehr als 60 Gründer und Unternehmen, darunter große Börsen und Venture-Firmen, drängten am 9. Juni die Senatoren, die Entwicklerschutzmaßnahmen in Section 604 des CLARITY Act zu erhalten. Die Idee ist einfach: Das Veröffentlichen und Pflegen von Code sollte nicht dem Betreiben einer nicht registrierten Börse oder eines Brokers gleichgestellt werden. Die rechtliche Übersicht hier: Advisers LLP (Rechtsanalyse, 22. Juni 2026).

Drittens ist die Strafverfolgung skeptisch. Vom 23. bis 24. Juni schickten vier große Organisationen, die Staatsanwälte und Polizei vertreten, einen gemeinsamen Brief an das Justizministerium und das Weiße Haus mit der Warnung, dass Section 604 AML-Lücken schaffen und Kryptowährung-Ermittlungen behindern könnte. Der Brief ist öffentlich: Gemeinsamer Brief der Strafverfolgungsbehörden (PDF) / berichtet von The Block.

Hinzu kommen die Juni-Kommentare von SEC-Kommissarin Hester Peirce, dass die Veröffentlichung von Open-Source-Code geschützte Meinungsäußerung sei und einen Programmierer ohne weiteres Verhalten nicht zum Verstoß gegen Wertpapiergesetze machen sollte. Diese Rahmung zieht eine Grenze zwischen Meinungsäußerung und Dienstleistung. Berichterstattung hier: Cointelegraph (Berichterstattung über Peirces Äußerungen).

Insgesamt ergibt sich ein politisches Tauziehen. Behörden wollen klare Grenzen. Entwickler wollen Raum zum Veröffentlichen. Strafverfolgungsbehörden wollen starke Rechenschaftspflicht. Das Ergebnis wird definieren, was non-custodial in den Vereinigten Staaten tatsächlich bedeutet.

Was Open-Source-Entwickler kontrollieren und was nicht

Kontrolle ist der Kern

Die meisten Haftungsargumente drehen sich um Kontrolle. Man kann Code liefern, den jeder ausführen kann, aber wenn man auch die Schnittstelle kuratiert, einen Gebührenschalter umlegt, die Liquidität lenkt oder Upgrade-Rechte hält, ist man dem Betreiben eines Produkts näher als dem bloßen Sprechen.

Bereiche, die in der Regel wie Meinungsäußerung aussehen

• Veröffentlichung von Repositories und Dokumentation mit einer permissiven Lizenz.
• Akademische Forschung oder Referenzimplementierungen, die nicht vom Autor eingesetzt werden.
• Nicht-kommerzielle Forks für Tests oder Demos.

Bereiche, die oft wie Handlung aussehen

• Betreiben des kanonischen Front-Ends, das Benutzer in echte Liquidität einführt.
• Kontrolle von Admin-Keys, Upgradeverantwortlichen oder Standardparametern, die das Risiko für Benutzer verändern.
• Betreiben von Preis- oder Datenorakeln, die die Ausführung wesentlich beeinflussen.
• Erheben von Protokoll- oder Schnittstellengebühren, die an ein Unternehmen oder Insider fließen.
• Gezieltes Marketing für finanzielle Erträge an US-Benutzer.

Profi-Tipp: Wenn man das Protokoll pausieren oder Gebühren ohne eine breite On-Chain-Abstimmung ändern kann, sollte man davon ausgehen, dass Regulatoren einen als Betreiber und nicht als passiven Programmierer betrachten.

Die Haftungsauslöser, auf die Washington immer wieder hinweist

Hier ist eine praktische Übersicht, was in politischen Debatten und Durchsetzungsmustern immer wieder auftaucht. Keines davon ist automatisch ein Verstoß. Es sind Auslöser, die Überprüfung einladen.

Szenario Warum es Aufmerksamkeit erregt Front-End dominiert die Szenerie Kuratierte Schnittstellen mit eingebetteten Gebühren oder Benutzerfiltern sehen wie ein Unternehmen aus. Das kommt einem regulierten Intermediär näher als neutralem Code. Admin-Keys und Notfallkontrollen Kill-Switches, Pausierbarkeit und Parameteränderungen implizieren Kontrolle über Benutzermittel oder Marktstruktur. Gebührenschalter und Provisionsaufteilung (Aufteilung der Provision) Wenn Entwicklerteams oder DAOs Einnahmen erzielen, verschwimmt die Grenze zwischen Software und Dienstleistung. Offenlegung und Governance-Qualität sind hier wichtig. Token-Anreize und Marketing Werbliche Aussagen oder Tokenomics, die Gewinne betonen, können eine Wertpapieranalyse einladen. Orakel und ereignisbasierte Produkte Wenn Orakel Ergebnisse für binäre oder Vorhersagemärkte bestimmen, kann das wie eine Derivaten-Plattform unter gemeinsamer SEC-CFTC-Prüfung aussehen. Compliance by Design fehlt Null Benutzerschutzmaßnahmen, keine Offenlegungen oder das Ignorieren klarer Sanktionsrisiken erhöhen den Druck schnell.

Es ist nicht so, dass ein einzelner Punkt fatal ist. Das Gesamtbild zählt. Je mehr das Design wie ein intermediiertes Finanzprodukt mit einem Team an der Spitze aussieht, desto weniger überzeugend wird die Meinungsäußerungs-Verteidigung.

Entwickler-Spielbuch: Code veröffentlichen, ohne ein Ziel zu malen

Man kann ein Projekt nicht gegen alle Haftungstheorien absichern. Man kann offensichtliche Angriffsflächen reduzieren. Hier ist eine Checkliste, die Teams gut gedient hat.

• Meinungsäußerung von Dienstleistung trennen. Repositories, Forschung und Spezifikationen offen halten. Wenn man eine gehostete Schnittstelle anbietet, offenlegen, dass es ein separater Dienst mit eigenen Bedingungen ist.
• Unilaterale Kontrollen minimieren. Zeitgesperrte Upgrades, breit verteilte Multisigs oder On-Chain-Governance mit echter Beteiligung verwenden. Dokumentieren, wer was ändern kann.
• Risiken wie ein Erwachsener offenlegen. Erklären, wie Orakel funktionieren, was schiefgehen kann, wer Gebühren verdient und unter welchen Bedingungen Mittel pausiert oder migriert werden können.
• Gebührenflüsse sorgfältig gestalten. Wenn Gebühren anfallen, sie an eine Community-Treasury mit klarer Governance leiten. Direktes Team-Skimming vermeiden, das wie ein kommerzieller Betreiberanteil aussieht.
• In öffentlichen Aussagen präzise sein. Versprechen von Gewinn oder garantierten Renditen vermeiden. Bei Funktionalität bleiben, nicht finanziellem Vorteil.
• Geofencing wo nötig. Wenn man ein gehostetes Front-End betreibt, angemessene Maßnahmen zur Zugangsbeschränkung dort anwenden, wo man Benutzer nicht legal bedienen kann.
• Einen Schwachstellenprozess haben. Bug-Bounties und einen offengelegten Kanal für Sicherheitsberichte anbieten. Es signalisiert verantwortungsvolles Handeln.
• Forks und Unabhängigkeit dokumentieren. Wenn Dritte eigene Deployments betreiben, klarstellen, dass man diese nicht kontrolliert.

Profi-Tipp: Eine einfache „Wer kontrolliert was"-Matrix in den Docs veröffentlichen. Wenn ein Regulator fragt, hat man eine ehrliche Übersicht statt einer vagen Antwort.

Börsen- und Front-End-Betreiber: der neue Engpass

Auch wenn Smart-Contracts ( Intelligente Verträge) unveränderlich sind, ist die Oberfläche, die Benutzer berührt, es nicht. Wallet-UIs, gehostete Schnittstellen, RPC-Gateways und Namensdienste sind allesamt von Menschen betriebene Dienste. Dort setzen Verpflichtungen in der Regel zuerst an.

Erwarten Sie zunehmenden Druck auf Schnittstellenbetreiber, das Onboarding zu verschärfen, Offenlegungen zu verbessern und einige Assets zu filtern. Wenn man ein Front-End betreibt, sollte man es wie ein Finanzprodukt mit Kundenauswirkungen behandeln, nicht wie ein Nebenprojekt. Klare Bedingungen, prominente Risikowarnungen und transparente Gebührenanzeigen helfen sehr.

Teams, die diese Rolle nicht wollen, können Code veröffentlichen und sich zurückziehen. Aber man sollte ehrlich über Kompromisse sein. Wenn man weiterhin Liquidität lenkt, Schlüsselinfrastruktur betreibt oder Gebühren einzieht, wird ein öffentlicher Rückzug bei gleichzeitigem privatem Halten der Hebel niemanden täuschen.

Derivaten sind die scharfe Kante

Die Kennzeichnung von Derivaten ist der Bereich, in dem viele DeFi-Experimente in die Enge getrieben werden könnten. Das gemeinsame SEC-CFTC-Kommentarverfahren nennt ausdrücklich gemischte Swaps und neuartige Produkte. Das erfasst Dinge wie Ereignismärkte und tokenisierte Engagements, die in DeFi üblich sind.

Für Entwickler ist die praktische Einschätzung einfach. Wenn das Protokoll Ergebnisse basierend auf externen Ereignissen auflöst oder Benutzern gehebeltes Engagement in Assets ermöglicht, sollte man mit Fragen rechnen, ob ein Derivatenprodukt angeboten wird. Das Kommentarverfahren ist 60 Tage nach der Veröffentlichung im Federal Register offen, was ein kurzes Fenster ist, um mit konkreten Beispielen Stellung zu nehmen. Siehe die Anfrage: U.S. Börsenaufsichtbehörde SEC (Pressemitteilung).

Commissioner Peirces Rede über Code als geschützte Meinungsäußerung wird Teil der Diskussion sein, insbesondere für Teams, die nur Referenzimplementierungen veröffentlichen. Aber wenn eine DAO oder ein Unternehmen eine Schnittstelle betreibt, die US-Benutzer einlädt, Ereigniskontrakte gegen eine Gebühr zu handeln, ist das eine ganz andere Haltung als ein GitHub-Repository. Berichterstattung über ihre Äußerungen: Cointelegraph (Berichterstattung über Peirces Äußerungen).

Marktauswirkungsszenarien für die nächsten 12 Monate

Mehr Geofencing und Haftungsausschlüsse

Gehostete UIs, die erheblichen US-Traffic bedienen, werden wahrscheinlich Jurisdiktionssperren ausweiten und am Rand mehr Reibung hinzufügen. Erwarten Sie mehr modale Warnungen, klarere Gebührenoffenlegungen und Opt-in-Risikobestätigungen.

DAO-Governance-Bereinigungen

Projekte mit lässigen Multisigs und unklaren Notfallbefugnissen werden die Governance straffen. Schriftliche Verfahren und öffentliche Timelocks sind im Vergleich zum rechtlichen Risiko günstig.

Konservatismus beim Asset-Listing

Front-Ends und Aggregatoren können bestimmte Ereignismärkte und Hochhebel-Features stillschweigend vom Börsenrückzug nehmen oder verbergen, während die Derivaten-Definitionen diskutiert werden. Die Liquidität könnte dem Weg des geringsten Risikos folgen und sich zu Protokollen verlagern, die klare Grenzen kommunizieren.

Entwicklermigration und Forks

Einige Teams könnten nicht-US-Deployments oder community-gepflegte Forks für erweiterte Funktionen aufsetzen, während die US-seitige Hauptschnittstelle einfacher gehalten wird. Dies fragmentiert Liquidität und UX, ist aber ein übliches Sicherheitsventil.

Risikohinweis: Auch wenn ein Protokoll erlaubnisfrei ist, ist die eigene Exposition als Mitwirkender, Unterzeichner oder Schnittstellenbetreiber persönlich. Unternehmensstruktur und Versicherung können irreführende Aussagen oder offensichtliche Kontrolle nicht beheben.

Wie man sich engagiert, bevor die Regeln sich festigen

Das Politikfenster ist gerade offen. Hier ist, wie Teams und Communities teilnehmen können, ohne Ressourcen zu verschwenden.

1. Einen kurzen Kommentar einreichen. Auf die gemeinsame SEC-CFTC-Anfrage mit einem praktischen Beispiel antworten, wie das Protokoll sich von einem zentralisierten Derivaten-Handelsplatz unterscheidet. Sachlich und spezifisch halten. Link: U.S. Börsenaufsichtbehörde SEC (Pressemitteilung).
2. Zivilisiert zu Section 604 Stellung nehmen. Wenn man die Veröffentlichung von Code außerhalb des Haftungsradius halten möchte, erklären, wie man in dem eigenen Projekt Meinungsäußerung von Handeln trennt. Der Branchenbrief ist hier zusammengefasst: Advisers LLP (Rechtsanalyse, 22. Juni 2026).
3. Strafverfolgungsbedenken direkt ansprechen. Dokumentieren, wie das Design offensichtliche AML-Lücken vermeidet, ohne standardmäßig zur Überwachung zu werden. Die Kritik kennen: Gemeinsamer Brief der Strafverfolgungsbehörden (PDF) / berichtet von The Block.
4. Eine Seite mit Betreiberverantwortlichkeiten veröffentlichen. Wenn man ein Front-End betreibt, klar darlegen, was man kontrolliert und was nicht, wie Gebühren funktionieren und wie Benutzer direkt mit Verträgen interagieren können, wenn sie möchten.
5. Mit anderen Projekten koordinieren. Gemeinsame Standards für Offenlegungen, On-Chain-Governance und Oracle-Transparenz haben mehr Gewicht als Einzelaussagen.

Wenn Sie eine wöchentliche, nüchterne Einschätzung dieser Entwicklung wünschen, berichten wir bei Crypto Daily über die politischen Entwicklungen und den dahinter stehenden Code. Die neueste Berichterstattung finden Sie bei Crypto Daily.

Häufig gestellte Fragen

Macht mich das Veröffentlichen von Open-Source-DeFi-Code zu einer regulierten Einheit?

Das Veröffentlichen von Code wird im Allgemeinen als Meinungsäußerung behandelt, und SEC-Kommissarin Hester Peirce hat argumentiert, dass es keine Wertpapiervorschriften auslösen sollte. Haftungsfragen werden schärfer, wenn man auch ein Front-End betreibt, Upgrades kontrolliert oder Gebühren von Benutzern einzieht. Berichterstattung über ihre Äußerungen: Cointelegraph (Berichterstattung über Peirces Äußerungen).

Worum geht es in Section 604 des CLARITY Act?

Es ist ein Vorschlag, der laut Branchenvertretern Open-Source-Entwickler, die Code veröffentlichen, davor schützen würde, wie Finanzintermediäre behandelt zu werden. Unterstützer möchten diese Schutzmaßnahmen erhalten, während Strafverfolgungsgruppen warnen, dass zu viel Immunität AML- und Ermittlungsinstrumente schwächen könnte. Referenzen: Advisers LLP (Rechtsanalyse, 22. Juni 2026) und Gemeinsamer Brief der Strafverfolgungsbehörden (PDF) / berichtet von The Block.

Wie beeinflusst das SEC-CFTC-Kommentarverfahren DeFi?

Die Behörden fragen, wie Swaps, wertpapierbasierte Swaps und ereignisbasierte Produkte harmonisiert definiert werden sollen. Wenn das Protokoll einem Derivatenmarkt ähnelt, könnten die Ergebnisse beeinflussen, was US-Benutzern angeboten werden kann oder wie es beschrieben wird. Die Anfrage ist hier: U.S. Börsenaufsichtbehörde SEC (Pressemitteilung).

Reicht das Betreiben einer DAO aus, um Haftung zu vermeiden?

Nicht automatisch. Wenn eine kleine Gruppe Upgrades, Gebühren oder Orakel kontrolliert, beseitigt die Bezeichnung als DAO keine operative Kontrolle. Regulatoren schauen auf das, was tatsächlich passiert, nicht auf das Label.

Welche Schritte können Front-End-Betreiber jetzt unternehmen?

Offenlegungen verbessern, klarstellen, was man kontrolliert, Gebühren transparent zeigen, Risikowarnungen hinzufügen und Geofencing in Betracht ziehen, wo Rechtsberater es empfehlen. Eine einfache Governance- und Upgrade-Richtlinie veröffentlichen, damit Benutzer wissen, wer Einstellungen ändern kann und wie schnell.

Sollten Entwickler die Smart-Contracts ( Intelligenten Verträge) selbst geofencen?

Smart-Contracts ( Intelligente Verträge) sind global und schwer auf sinnvolle Weise zu geofencen. Wenn gehostete Dienste wie eine Website oder API angeboten werden, sind das geeignetere Orte, um Zugriffskontrollen nach Rechtsberatung zu implementieren.

Was ist der Hauptfehler, den Teams in diesem Bereich machen?

Öffentlich wie reine Verleger aufzutreten, während man still die wichtigen Hebel bedient. Wenn man Benutzererfahrung, Gebühren oder Ergebnisse kontrolliert, sollte man diese Rolle annehmen und compliance-gerechte Abläufe einrichten oder sich wirklich zurückziehen.

Haftungsausschluss: Dieser Artikel dient nur zu Informationszwecken. Er wird nicht angeboten und soll nicht als Rechts-, Steuer-, Investitions-, Finanz- oder sonstige Beratung verwendet werden.