DeFi-Frontends unter MiCA

I. Überblick

Die Verordnung (EU) 2023/1114 über Märkte für Kryptowerte (MiCA) gilt grundsätzlich seit dem 30. Dezember 2024. Die unionsrechtlich längstmögliche Übergangsregelung für bereits zuvor rechtmäßig tätige Anbieter endete am 1. Juli 2026; Deutschland hatte diese Frist auf den 31. Dezember 2025 verkürzt. Für neue Marktteilnehmer galt die Bestandsschutzregelung ohnehin nicht.

Damit stellt sich mit praktischer Dringlichkeit die Frage, ob und unter welchen Voraussetzungen Betreiber von DeFi-Frontends eine Zulassung als Anbieter von Kryptowerte-Dienstleistungen benötigen. Eine pauschale Antwort verbietet sich. MiCA kennt zwar den Begriff des „Online-Interfaces“, macht das Bereitstellen einer Website oder App aber nicht zu einer eigenständigen Kryptowerte-Dienstleistung. Entscheidend ist vielmehr, ob über die jeweilige technische und organisatorische Schicht eine der in Art. 3 Abs. 1 Nr. 16 MiCA aufgezählten Dienstleistungen professionell für Kunden erbracht wird.

Die Prüfung muss deshalb produkt- und transaktionspfadbezogen erfolgen. Derselbe Anbieter kann innerhalb derselben Oberfläche reine Analytics, einen klassischen selbstverwahrenden Swap und einen Intent-basierten Orderfluss nebeneinander anbieten. Diese Funktionen können aufsichtsrechtlich unterschiedlich zu beurteilen sein.

II. Der maßgebliche Prüfungsrahmen

1. Erfasstes Asset und EU-Bezug

Vor jeder Frontend-Analyse steht die Frage des sachlichen Anwendungsbereichs. MiCA gilt für Dienstleistungen in Bezug auf Kryptowerte, nicht aber für Kryptowerte, die als Finanzinstrumente im Sinne der MiFID II einzuordnen sind. Gerade bei Derivaten und Perpetual-Kontrakten kann deshalb statt MiCA das Wertpapieraufsichtsrecht einschlägig sein. Daneben muss die Dienstleistung „in der Union“ erbracht werden; bei Drittstaatenanbietern sind insbesondere Marktansprache, Zielkundschaft, Vertragsbeziehungen und die tatsächliche Leistungserbringung gegenüber EU-Kunden gesondert zu prüfen.

2. Wer ist Erlaubnisadressat?

Die eigentliche Zulassungspflicht folgt aus Art. 59 MiCA. Danach darf eine Person Kryptowerte-Dienstleistungen in der Union grundsätzlich nur erbringen, wenn sie als Anbieter von Kryptowerte-Dienstleistungen zugelassen ist oder zu den in Art. 60 MiCA genannten Finanzunternehmen gehört und die dortigen Voraussetzungen erfüllt. Art. 3 Abs. 1 Nr. 15 beschreibt den Anbieter als juristische Person oder sonstiges Unternehmen, dessen berufliche oder gewerbliche Tätigkeit darin besteht, eine oder mehrere Kryptowerte-Dienstleistungen professionell für Kunden zu erbringen.

Ein unmittelbares Entgelt ist kein ausdrückliches Tatbestandsmerkmal. Umgekehrt macht nicht jede mittelbare wirtschaftliche Begünstigung aus einem Open-Source-Projekt bereits eine professionelle Dienstleistung. Zu würdigen sind vielmehr das Gesamtbild der Tätigkeit, ihre Dauerhaftigkeit, Organisation, Marktansprache, Monetarisierung und die Beziehung zu den Nutzern.

3. Welche Dienstleistung wird erbracht?

Für transaktionsbezogene Frontends stehen regelmäßig drei Tatbestände im Mittelpunkt:

• Annahme und Übermittlung von Aufträgen: Entgegennahme eines Kauf-, Verkaufs- oder Zeichnungsauftrags von einer Person und Weiterleitung dieses Auftrags an einen Dritten zur Ausführung, Art. 3 Abs. 1 Nr. 23 MiCA.
• Betrieb einer Handelsplattform: Management eines oder mehrerer multilateraler Systeme, die mehrere Kauf- und Verkaufsinteressen Dritter nach den Regeln des Systems so zusammenführen oder deren Zusammenführung erleichtern, dass ein Vertrag zustande kommt, Art. 3 Abs. 1 Nr. 18 MiCA.
• Ausführung von Aufträgen für Kunden: Abschluss von Vereinbarungen über den Kauf oder Verkauf von Kryptowerten im Namen von Kunden, Art. 3 Abs. 1 Nr. 21 MiCA.

Je nach Produktgestaltung können zusätzlich etwa Anlageberatung, Transferdienstleistungen, Verwahrung oder der Tausch unter Einsatz eigenen Kapitals relevant werden. Die drei vorgenannten Tatbestände sind für DeFi-Frontends daher zentral, aber nicht abschließend.

Bei der Annahme und Übermittlung ist eine wichtige Unsicherheit zu beachten: Die Definition in Art. 3 Abs. 1 Nr. 23 spricht allgemein von der Übermittlung an einen „Dritten“. Art. 80 Abs. 1 beschreibt die Pflichten eines solchen Dienstleisters dagegen anhand der Übermittlung an eine Kryptowerte-Handelsplattform oder einen anderen Anbieter von Kryptowerte-Dienstleistungen. Das schließt eine weitere Auslegung des Begriffs „Dritter“ nicht zwingend aus, spricht aber dagegen, jeden bloßen Aufruf eines autonomen Smart Contracts ohne Weiteres als Auftragsübermittlung einzuordnen.

Auch für die Handelsplattform gilt: Ein Order-Book, eine Datenbank oder eine Auktion genügt für sich genommen nicht. Entscheidend ist, ob mehrere Drittinteressen im System nach dessen Regeln interagieren und diese Interaktion zu einem Vertrag führt. Die aus dem MiFID-Kontext bekannten Grundsätze zum multilateralen System können bei der Auslegung helfen; sie dürfen aber nicht schematisch auf jede DeFi-Architektur übertragen werden.

4. Erwägungsgrund 22: kein pauschaler Safe Harbour

Erwägungsgrund 22 stellt klar, dass Kryptowerte-Dienstleistungen, die vollständig dezentral und ohne Intermediär erbracht werden, nicht in den Anwendungsbereich der MiCA fallen. Dabei handelt es sich nicht um eine eigenständige Erlaubnis- oder Freistellungsnorm, sondern um eine Auslegungsvorgabe zur Reichweite der Verordnung. Die ESMA betont, dass die vollständige Dezentralisierung von den zuständigen Behörden im Einzelfall zu beurteilen ist. EBA und ESMA weisen zudem darauf hin, dass MiCA auf Tätigkeiten anwendbar sein kann, die unmittelbar oder mittelbar von Personen erbracht oder kontrolliert werden, auch wenn andere Teile des Arrangements dezentral ausgestaltet sind.

Daraus folgen zwei gegenläufige Korrekturen: Ein zentral betriebenes Frontend zieht nicht automatisch das gesamte zugrunde liegende Protokoll in den Anwendungsbereich. Umgekehrt schützt die Dezentralität autonomer Smart Contracts nicht eine separat kontrollierte API-, Orderbuch-, Routing- oder Zugangsschicht. Jede Funktion und jede Schicht ist gesondert zuzurechnen.

III. Drei Frontend-Archetypen

1. Rein informatorische Oberfläche

Der erste Archetyp ruft öffentliche On-Chain-Daten ab und zeigt etwa Pool-Statistiken, Kurse oder Handelsvolumina an, ohne Transaktionen vorzubereiten, personalisierte Empfehlungen zu geben oder Aufträge entgegenzunehmen beziehungsweise weiterzuleiten. Eine solche reine Analytics-Funktion erfüllt regelmäßig keinen Tatbestand des Art. 3 Abs. 1 Nr. 16 MiCA.

Die Einschränkung ist wichtig: Sobald die Oberfläche nutzerbezogene Empfehlungen abgibt, konkrete Transaktionen vorbereitet oder einen ausführbaren Orderfluss eröffnet, ist nicht mehr das gesamte Produkt als „reine Anzeige“ zu behandeln. Maßgeblich ist das einzelne Modul.

2. Selbstverwahrende Transaktionsvorbereitung

Beim zweiten Archetyp berechnet das Frontend eine Route, erzeugt Calldata und übergibt eine noch nicht signierte Transaktion an die Wallet. Der Nutzer prüft und signiert sie und sendet sie – je nach Aufbau über einen eigenen oder vorgegebenen RPC-Endpunkt – an einen Router- oder Pool-Contract.

Die Nutzersignatur ist ein gewichtiges Indiz gegen eine Ausführung durch den Frontend-Betreiber, aber kein automatischer Ausschlussgrund. Entscheidend ist, ob der Betreiber selbst eine Vereinbarung im Namen des Kunden abschließt oder die Ausführung tatsächlich beherrscht. Gegen eine Ausführung spricht insbesondere, wenn der Nutzer die Transaktion frei ablehnen, verändern und über eine von ihm gewählte Infrastruktur selbst versenden kann und der Betreiber nach Übergabe der Calldata nicht mehr in den Ablauf eingreift.

Bei der Annahme und Übermittlung bleibt die Lage offen. Für eine Dienstleistung sprechen können etwa die Entgegennahme einer bereits verbindlichen Weisung, ein betreibereigener Relayer oder RPC, Gas-Sponsoring, eine automatische Weiterleitung, nachträgliche Parametrisierung oder die Möglichkeit, Transaktionen zurückzuweisen. Dagegen spricht ein rein lokaler, nicht verwahrender Vorgang, bei dem der Nutzer lediglich unverbindliche Berechnungen erhält und selbst an einen autonomen Contract übermittelt. Dieser Archetyp ist deshalb kein einheitlicher „sicherer Hafen“, sondern ein echter Grenzbereich.

3. Intent- und Order-Relay-Architektur

Beim dritten Archetyp signiert der Nutzer off-chain einen Auftrag oder Intent. Eine gesonderte Infrastruktur nimmt die signierte Nachricht entgegen, prüft sie, speichert sie gegebenenfalls und stellt sie Fillern, Resolvern oder Solvern zur Ausführung zur Verfügung. Der Dritte führt die Transaktion anschließend on-chain aus und trägt häufig die Netzwerkkosten.

Eine solche Architektur nähert sich der Definition der Annahme und Übermittlung deutlich stärker an als die bloße Calldata-Erzeugung. Gleichwohl ist auch hier eine Subsumtion erforderlich: Wer empfängt den Auftrag? Für wen wird gehandelt? An welchen Dritten wird er übermittelt? Welche Rolle spielt der Betreiber bei Validierung, Auktion, Auswahl, Parametrisierung und Settlement? Der Wortlaut des Art. 3 Abs. 1 Nr. 23 und die offene Reichweite des Art. 80 MiCA rechtfertigen eine hohe Risikoeinschätzung, aber noch keine pauschale Gleichsetzung jedes Intent-Protokolls mit einem erlaubnispflichtigen Vermittler.

Eine Handelsplattform kommt zusätzlich in Betracht, wenn mehrere Drittinteressen innerhalb eines vom Betreiber gemanagten Systems nach vorgegebenen Regeln interagieren und daraus Verträge entstehen. Ruhende Orders erhöhen die Nähe zu einem Handelssystem, sind aber nicht allein entscheidend. Besonders relevant sind Cross-Order-Matching, Batch-Auktionen, verbindliche RFQs, Zugangsregeln für Ausführende und die Frage, ob das System selbst bestimmt, welche Interessen miteinander kontrahieren.

IV. Anwendung auf marktgängige Architekturen

Die folgenden Einordnungen beziehen sich auf die im August 2026 dokumentierten Transaktionspfade. Produktnamen dürfen nicht mit einer einheitlichen aufsichtsrechtlichen Funktion gleichgesetzt werden; Routing-Logik und Backend-Komponenten können sich ändern.

1. Analytics- und Explore-Ansichten

Reine Analytics-Module bei Uniswap sowie reine Dashboard-Funktionen von DeFiLlama oder DeBank entsprechen dem ersten Archetyp, soweit sie ausschließlich öffentliche Daten darstellen. Daraus folgt keine Aussage über andere Funktionen derselben Angebote, etwa Swap-, Bridge-, Wallet- oder Empfehlungsmodule.

2. Klassische Pool- und Aggregator-Routen

Ein klassischer Uniswap-Pool-Swap oder ein 1inch-Classic-Swap kann dem zweiten Archetyp entsprechen, wenn das Frontend lediglich Route und Transaktionsdaten erzeugt, der Nutzer die On-Chain-Transaktion selbst signiert und bezahlt und die Weiterleitung nicht vom Frontend-Betreiber übernommen wird. Bei 1inch unterscheidet die aktuelle Produktdokumentation ausdrücklich zwischen dem nutzerfinanzierten Classic-Modus und dem durch Resolver ausgeführten Fusion-Modus.

Für die rechtliche Bewertung reicht die Bezeichnung „Classic“ allerdings nicht aus. Zu prüfen sind insbesondere der eingesetzte RPC, ein möglicher Transaktions-Relay, Smart-Wallet-Delegationen, Gas-Abstraktion und die Frage, ob das Backend nach der Nutzersignatur noch Parameter ergänzt oder die Ausführung steuert.

3. UniswapX und Uniswap-Limit-Orders

Bei UniswapX signiert der Nutzer einen Permit2-basierten Auftrag, der an eine Filler-Infrastruktur übermittelt und durch Dritte on-chain ausgeführt wird. Auch die derzeitige Limit-Order-Funktion des Uniswap-Interfaces nutzt nach der Produktdokumentation das UniswapX-Netzwerk und veröffentlicht Aufträge an ein offenes Netzwerk dritter Filler. Die aktuelle Uniswap-Dokumentation unterscheidet eine zugangsbeschränkte Quoter-Rolle von einer technisch offenen Filler-Rolle. Im RFQ-Ablauf holt ein Uniswap-Backend zunächst Quotes ein, der Nutzer signiert den Auftrag, anschließend kann eine weitere „harte“ RFQ-Phase stattfinden; der finalisierte Auftrag wird danach an das Filler-Netzwerk gegeben. Das öffentlich dokumentierte UniswapX-Order-Service validiert, speichert und verteilt signierte Orders.

Diese Merkmale begründen ein erhebliches Risiko einer Annahme und Übermittlung von Aufträgen auf Ebene der jeweils kontrollierten Backend-Dienste. Die technisch offene Filler-Rolle beseitigt dieses Risiko nicht. Sie zeigt jedoch, dass die Einordnung nicht auf der unzutreffenden Annahme eines generell geschlossenen Filler-Kreises beruhen darf; vielmehr ist die rechtliche und tatsächliche Betreiberzuordnung jeder Backend-Komponente gesondert festzustellen. Auch der Handelsplattformtatbestand ist nicht bereits deshalb erfüllt, weil Orders gespeichert oder mehrere Filler um die Ausführung konkurrieren. Erforderlich bleibt die multilaterale Zusammenführung von Kauf- und Verkaufsinteressen Dritter nach Systemregeln mit Vertragsfolge.

4. CoW Protocol

Bei CoW Protocol ist die Nähe zum dritten Archetyp besonders ausgeprägt. Nach der technischen Dokumentation ist das Orderbook die zentrale API für Nutzer und Integrationen. Es erstellt Quotes, validiert signierte Orders, kann ungültige Orders zurückweisen und speichert akzeptierte Orders in einer Datenbank. Ein Autopilot bildet daraus Auktionen; unabhängige Solver konkurrieren um Settlement-Lösungen. Gegenläufige Nutzerinteressen können als „Coincidence of Wants“ innerhalb einer Batch-Lösung unmittelbar berücksichtigt werden.

Damit bestehen gewichtige Argumente für die Annahme und Übermittlung von Aufträgen. Auch die Handelsplattformfrage stellt sich hier schärfer als bei einem bloßen Single-Order-Relay, weil mehrere Nutzerorders gemeinsam verarbeitet und potenziell miteinander gematcht werden. Gleichwohl bleibt zu klären, wer Orderbook, Autopilot, Solver-Zugang und Regelwerk tatsächlich und rechtlich managt. Der Hinweis auf eine DAO oder auf Open-Source-Code ersetzt diese Betreiberanalyse nicht; ebenso wenig darf ohne sie ein bestimmter Rechtsträger als Dienstleister unterstellt werden.

5. 1inch Fusion

Bei 1inch Fusion signiert der Nutzer einen Auftrag; protokollseitig registrierte beziehungsweise zugelassene Resolver konkurrieren in einer Dutch Auction um dessen Ausführung und tragen im Regelfall die On-Chain-Gaskosten. Die aktuelle 1inch-Dokumentation beschreibt Resolver als protokollseitig zugelassene und registrierte Adressen mit Stake-Anforderungen und unterscheidet Fusion ausdrücklich vom Classic-Swap, bei dem der Nutzer selbst die Transaktion ausführt und Gas zahlt.

Auch hier liegt das Erlaubnisrisiko vor allem in der Infrastruktur, die Orders entgegennimmt, verteilt und den Resolver-Zugang organisiert. Ob 1inch selbst, ein API-Anbieter, eine andere Konzerngesellschaft oder eine weitere Stelle die jeweilige Funktion erbringt, muss anhand der tatsächlichen Betriebs- und Vertragsstruktur ermittelt werden. Die Bezeichnung „Resolver-Modell“ beantwortet die Zurechnungsfrage nicht.

V. Zurechnung, Terms of Service und Dezentralität

Vertragliche Selbstbeschreibungen sind weder bedeutungslos noch entscheidend. Ein Satz wie „Wir stellen nur ein Interface bereit“ kann die tatsächliche Funktion nicht beseitigen. Umgekehrt beweist eine weit formulierte Produktbeschreibung allein noch nicht, dass der betreffende Rechtsträger jeden technischen Dienst selbst erbringt. Terms of Service, API-Bedingungen, Gebührenmodelle, Teilnehmerregeln, technische Dokumentation und der reale Betrieb sind gemeinsam auszuwerten. Aktuelle Uniswap-Labs-Bedingungen bezeichnen die gehostete Oberfläche und weitere Dienste als eigene „Products“; die API-Bedingungen sehen unter anderem widerruflichen Zugang sowie Änderungs-, Beschränkungs- und Sperrbefugnisse vor. Solche Regelungen sind relevante Kontrollindizien, aber keine abschließende aufsichtsrechtliche Subsumtion.

Für die Zurechnung sind insbesondere fünf Fragen hilfreich:

1. Wer empfängt, validiert und speichert die signierte Order oder Transaktion?
2. Wer bestimmt Routing, Auktionsmechanismus, Orderparameter und Settlement-Pfad?
3. Wer legt den Zugang von Quotern, Fillern, Resolvern oder Solvern fest und kann ihn entziehen?
4. Wer kann Orders ablehnen, zurückhalten, sperren, priorisieren oder aus dem System entfernen?
5. Wer betreibt und monetarisiert API, Relayer, Orderbook, Autopilot, Indexer oder den für den Ablauf wesentlichen RPC?

Je mehr dieser Funktionen bei einer identifizierbaren Stelle zusammenlaufen, desto schwerer wiegt das Argument, die Leistung werde vollständig dezentral und ohne Intermediär erbracht.

Auch die Zuschreibung an eine DAO ist differenziert zu behandeln. Eine DAO ist nicht allein aufgrund ihrer Bezeichnung ein „sonstiges Unternehmen“ im Sinne der MiCA; sie ist aber auch nicht automatisch außerhalb jeder Zurechnung. Maßgeblich sind Organisationsgrad, wirtschaftliche Tätigkeit, Dauerhaftigkeit, Governance-Rechte, operative Kontrolle und die Möglichkeit, konkrete Dienstleistungsfunktionen einem Rechtsträger oder einer hinreichend organisierten Einheit zuzuordnen. Die bloße Verlagerung einer Zuständigkeit in Governance-Dokumente dezentralisiert die tatsächliche Funktion nicht.

Als technisches Gegenbeispiel kann dYdX Chain dienen: Dort halten Validatoren beziehungsweise Full Nodes lokale In-Memory-Orderbücher; der jeweilige Block-Proposer erzeugt Matches für den nächsten Block. Das zeigt, dass ein Orderbuch und Matching ohne einen einzigen zentralen Orderbook-Server organisiert werden können. Daraus folgt aber nicht automatisch die vollständige Dezentralisierung des gesamten Dienstes. Validatoren, Indexer, Frontend- und API-Betreiber können weiterhin identifizierbare Funktionen ausüben. Zudem handelt dYdX primär Perpetual-Produkte; vor einer MiCA-Einordnung ist daher zunächst zu prüfen, ob die gehandelten Instrumente als Finanzinstrumente einzuordnen und nach Art. 2 Abs. 4 lit. a MiCA ausgenommen sind.

VI. Konsequenzen für die Praxis

Betreiber sollten nicht die Marke oder das Protokoll als Ganzes klassifizieren, sondern jeden konkreten Transaktionspfad dokumentieren. Eine belastbare Prüfung umfasst mindestens: die rechtliche Einordnung der gehandelten Assets; den EU-Bezug; die beteiligten Rechtsträger und technischen Betreiber; den Weg von Nutzereingabe, Signatur und Order bis zum Settlement; sämtliche Ablehnungs-, Zugangs- und Steuerungsrechte; die Zuordnung zu den Dienstleistungstatbeständen; sowie die professionelle und wirtschaftliche Einbettung der Tätigkeit.

Ergibt diese Analyse eine erlaubnispflichtige Dienstleistung, reichen bloße Disclaimer oder eine Umbenennung der Funktion nicht aus. In Betracht kommen – abhängig vom Geschäftsmodell – eine eigene Zulassung, die vollständige Übertragung der erlaubnispflichtigen Funktion auf einen zugelassenen Anbieter, eine tatsächliche organisatorische und technische Dezentralisierung oder die wirksame Einstellung der Dienstleistung im EU-Markt. Auch eine Dezentralisierung muss funktional wirksam sein: Open Source, Forkbarkeit und DAO-Governance genügen nicht, solange eine identifizierbare Stelle den produktiven Orderfluss kontrolliert.

VII. Fazit

Die Architektur eines DeFi-Frontends ist für die MiCA-Einordnung zentral, aber nicht allein entscheidend. MiCA knüpft an Personen, professionelle Tätigkeiten, Kundenbezug und konkret definierte Dienstleistungen an. Ein rein informatorisches Interface bleibt regelmäßig außerhalb des Erlaubnisregimes. Ein selbstverwahrender Swap mit lokaler Transaktionsvorbereitung ist ein Grenzfall, dessen Bewertung von Relay-, RPC-, Gas- und Steuerungsfunktionen abhängt. Bei Intent- und Order-Relay-Modellen mit kontrollierter Annahme, Validierung, Speicherung und Verteilung signierter Orders ist das Risiko einer erlaubnispflichtigen Annahme und Übermittlung deutlich höher.

Auch dort gilt jedoch: Ein Orderbuch ist nicht automatisch eine Handelsplattform, eine Nutzersignatur schließt eine Ausführung nicht automatisch aus, und ein DAO- oder DeFi-Label ersetzt keine Zurechnungsanalyse. Entscheidend ist, wer welche Funktion tatsächlich erbringt und kontrolliert. Genau diese Funktions- und Betreiberanalyse sollte vor Produktstart, bei jeder wesentlichen Architekturänderung und vor einer EU-Marktansprache dokumentiert werden.

Der Beitrag stellt eine allgemeine aufsichtsrechtliche Analyse dar und ersetzt keine Prüfung des konkreten Produkts und seiner tatsächlichen Betriebsstruktur.

‍