Bereitgestellt von
Legal

MiCA entschlüsselt: Ihr Krypto-Whitepaper darf nicht nur ein Gitbook oder PDF sein

Wenn die meisten Menschen den Begriff „Krypto-Whitepaper“ hören, denken sie an Satoshi Nakamotos neunseitiges Dokument oder an eine mit Fachjargon gespickte Präsentation aus der ICO-Ära. MiCA hat eine andere Definition, und genau in dieser Kluft zwischen allgemeiner Vorstellung und rechtlicher Realität liegen die Ursachen für viele Compliance-Verstöße.

GESCHRIEBEN VON
TEILEN
MiCA entschlüsselt: Ihr Krypto-Whitepaper darf nicht nur ein Gitbook oder PDF sein

„MiCA Decoded“ ist eine wöchentliche Serie mit 12 Artikeln für Bitcoin.com News, die gemeinsam von den Mitbegründern und Geschäftsführern von LegalBison verfasst wird: Aaron Glauberman, Viktor Juskin und Sabir Alijev. LegalBison berät Krypto- und FinTech-Unternehmen zu MiCA-Lizenzen, CASP- und VASP-Anträgen sowie zur regulatorischen Strukturierung in ganz Europa und darüber hinaus.

Nach MiCA ist ein Whitepaper ein obligatorisches Instrument zur Offenlegung. Seine engste Entsprechung im traditionellen Finanzwesen ist ein Wertpapierprospekt, kein Marketingdokument. Die Verordnung schreibt vor, wer eines erstellen muss, in welchem Format, welche Identifikatoren es enthalten muss, welcher automatisierten Validierung es unterliegt und welche Haftung einer bestimmten namentlich genannten Person zukommt.

Ist auch nur eines dieser Elemente fehlerhaft, gilt das Dokument in den Augen der europäischen Regulierungsbehörden als nicht existent, unabhängig davon, wie gut es verfasst ist. In dieser sechsten Folge von „MiCA Decoded“ wird Stück für Stück erläutert, was das konkret bedeutet.

Der Mythos: Ein MiCA-Whitepaper ist nur ein GitBook oder ein PDF

Ein MiCA-Whitepaper hat das Gewicht einer formellen behördlichen Einreichung. Die Durchführungsverordnung (EU) 2024/2984 der Kommission, die Formen, Formate und Vorlagen für Whitepaper zu Krypto-Assets regelt, verlangt, dass das Dokument in einem strukturierten digitalen Format erstellt wird, das so gestaltet ist, dass die ESMA und die zuständigen nationalen Behörden in allen EU-Mitgliedstaaten bei jeder Einreichung identische automatisierte Analysen durchführen können, unabhängig davon, wer oder wo sie eingereicht wurde.

Der rechtliche Zweck dieser Gestaltungsentscheidung ist wichtiger als die technischen Einzelheiten. MiCA ist eine Binnenmarktverordnung, und die Vergleichbarkeit der eingereichten Unterlagen ist ein zentrales Instrument zur Durchsetzung. Ein Whitepaper, das nicht von derselben Maschine gelesen werden kann wie jedes andere in Europa eingereichte Whitepaper, ist nicht konform, unabhängig davon, was sein Inhalt besagt. Die ESMA hat die erforderliche Taxonomie (das strukturierte Rahmenwerk, das definiert, was ein konformes Whitepaper enthalten muss) am 5. August 2025 veröffentlicht. Die Vorschriften gelten ab dem 23. Dezember 2025. Die Offenlegungspflichten variieren je nach Art der betroffenen Krypto-Asset. MiCA unterscheidet drei verschiedene Kategorien, für die jeweils eigene Whitepaper-Vorlagen und Feldanforderungen gelten:

Die Kategorie bestimmt nicht nur den Inhalt des Whitepapers, sondern den gesamten rechtlichen Weg bis zur Einreichung. Ein Projekt kann nicht nach Belieben entscheiden, welche Kategorie gilt. Die Eigenschaften des Vermögenswerts bestimmen dies, und die Vorbereitungsauflagen ergeben sich daraus.

Wer trägt die rechtliche Verpflichtung – und die Haftung

Für die überwiegende Mehrheit der Token auf dem Markt (kategorisiert als „Sonstige“ Krypto-Vermögenswerte oder OTHR) liegt die Verpflichtung nicht automatisch bei dem Unternehmen, das den Token geschaffen hat. Für diese Vermögenswerte legt MiCA die Verpflichtung dem Anbieter oder der Person auf, die die Zulassung zum Handel beantragt – dies sind definierte Rollen, die mit dem ursprünglichen Emittenten übereinstimmen können oder auch nicht.

Diese Unterscheidung hat konkrete Konsequenzen. Ein Projekt, das in die OTHR-Kategorie fällt und von den Britischen Jungferninseln, den Kaimaninseln oder einer anderen Offshore-Gerichtsbarkeit aus gestartet wird, kann gemäß MiCA als Anbieter gelten und die Whitepaper-Verpflichtung direkt tragen, ohne dass eine Verlegung seines Rechtssitzes nach Europa erforderlich ist.

(Anmerkung: Diese strukturelle Flexibilität gilt ausschließlich für OTHR-Token. Bei Asset-Referenced Tokens und E-Money-Token liegen die rechtliche Verpflichtung und die strenge zivilrechtliche Haftung für das Whitepaper vollständig beim zugelassenen EU-Emittenten und können nicht delegiert werden). Wie wir im zweiten Teil dieser Serie untersucht haben, bestätigen die ESMA-Register, dass dies bereits gängige Praxis ist: Die Mehrheit der unabhängigen Token-Anmeldungen stammt von Unternehmen mit Sitz außerhalb der EU.

Ein CASP, der eine Handelsplattform betreibt, kann die Verpflichtung zur Erstellung des Whitepapers ebenfalls übernehmen, entweder auf eigene Initiative oder durch eine schriftliche Vereinbarung mit dem Projektteam. Dies ist weder eine Gesetzeslücke noch eine administrative Erleichterung. Wenn ein CASP eine Einreichung vornimmt, übernimmt er die rechtliche Verantwortung für die Richtigkeit und Vollständigkeit der Offenlegung. Enthält das Whitepaper irreführende Informationen oder entspricht es nicht den regulatorischen Standards, liegt die Haftung bei demjenigen, der es eingereicht hat.

Die Person, die das Whitepaper abzeichnet, kann dieses Risiko nicht an einen Softwareanbieter, einen technischen Integrator oder eine Anwaltskanzlei delegieren. Die rechtliche Prüfung des Inhalts und die technische Validität sind zwei getrennte Compliance-Verpflichtungen, und beide liegen beim Anbieter. Dies ist der Punkt, den die meisten Projekte unterschätzen.

Zwei Codes, die vor Beginn der Einreichung vorhanden sein müssen

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Zwei obligatorische Identifikatoren sind Voraussetzungen für jedes konforme Whitepaper. Beide stammen aus internationalen Standards, die bereits vor MiCA galten. Die Verordnung hat sie nicht geschaffen, sondern für verbindlich erklärt.

Der erste ist der Legal Entity Identifier (LEI), ein ISO-17442-Code, der juristischen Personen zugewiesen und in der von der GLEIF verwalteten globalen LEI-Datenbank gepflegt wird. Die Verpflichtung zu seiner Verwendung erstreckt sich über mehrere regulatorische Standards: Während Artikel 14 der RTS zur Aufbewahrung von Aufzeichnungen (Delegierte Verordnung (EU) 2025/1140 der Kommission) LEI-Anforderungen an CASPs für deren Kunden vorschreibt, schreibt Artikel 3 der RTS zur Klassifizierung von Whitepapers (Delegierte Verordnung (EU) 2025/421 der Kommission) strikt vor, dass alle Ersteller von Whitepapers ihre eigene juristische Person mit einem gültigen LEI-Code identifizieren müssen. Für jede juristische Person, die noch keinen LEI-Code besitzt, muss das LEI-Antragsverfahren abgeschlossen sein, bevor mit der Erstellung des Whitepapers begonnen wird.

Der zweite ist der Digital Token Identifier (DTI), ein ISO-24165-Code, der das Krypto-Asset selbst identifiziert und im DTIF-Register geführt wird. Artikel 15 der RTS zur Aufbewahrung von Aufzeichnungen und Artikel 3 der RTS zur Klassifizierung von Whitepapers (Delegierte Verordnung (EU) 2025/421 der Kommission) schreiben dessen Verwendung vor. Der entscheidende Punkt für jedes Projekt, das einen neuen Token auf den Markt bringt: Wenn der DTI noch nicht im Register vorhanden ist, muss jemand dessen Erstellung beantragen, bevor das Whitepaper eingereicht werden kann. Wenn ein CASP einen Vermögenswert ohne zentralen Emittenten und ohne vorhandenes Whitepaper anmeldet, ist die Plattform dafür verantwortlich, den DTI direkt vom DTIF abzurufen oder anzufordern.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Quelle: das DTIF-Register für Krypto-Assets Ein Whitepaper, das keinen gültigen LEI und DTI enthält, scheitert an der automatisierten Validierung, bevor es überhaupt von einem menschlichen Prüfer gesehen wird. Projekte, die die Einreichungsphase erreichen, ohne beide Codes vorliegen zu haben, müssen von vorne beginnen.

Das automatisierte Tor und seine rechtlichen Auswirkungen

Kein Mitarbeiter einer nationalen zuständigen Behörde prüft ein Whitepaper, das die automatisierten Prüfungen nicht besteht. Die ESMA-Taxonomie definiert 257 Existenzprüfungen (Überprüfung, ob Pflichtfelder vorhanden sind) und 223 Wertprüfungen (Überprüfung, ob der Feldinhalt gültig ist). Eine Einreichung, die eine Prüfung mit dem Schweregrad „Fehler“ nicht besteht, ist technisch ungültig. Das Dokument wird nicht weiterbearbeitet.

Die rechtliche Konsequenz dieser Architektur ist eindeutig: Technische Gültigkeit und inhaltliche Richtigkeit liegen gleichermaßen in der Verantwortung des Anbieters. Eine perfekt formulierte rechtliche Offenlegung in der falschen Struktur scheitert. Eine strukturell gültige Datei mit irreführendem Inhalt scheitert ebenfalls; sie scheitert lediglich in einer anderen Phase und mit anderen Konsequenzen.

Projekte, die Token in mehreren EU-Mitgliedstaaten anbieten, sehen sich einer zusätzlichen Hürde gegenüber. Jede Sprachversion des Whitepapers erfordert eine eigene, separat strukturierte Datei. Alle Sprachversionen müssen intern konsistent sein und dürfen nicht nur übersetzt, sondern müssen auf Feldebene identisch organisiert sein. Eine Übersetzung, die die Struktur des Originals nicht widerspiegelt, ist technisch nicht konform, unabhängig von ihrer sprachlichen Genauigkeit.

Nachhaltigkeitsangaben stellen eine weitere Einschränkung dar. Die Taxonomie schreibt bestimmte Maßeinheiten für den Energieverbrauch und die CO2-Emissionen vor: kWh bzw. tCO2. Dabei handelt es sich um gesetzliche Offenlegungspflichten, nicht um optionale Umweltberichterstattung. Die Einreichung mit anderen Einheiten oder das Weglassen der Felder führt zu einem Validierungsfehler.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Das Muster bei all diesen Anforderungen ist dasselbe: Das Whitepaper ist eine gesetzliche Einreichung mit maschinell durchgesetzten Standards. Projekte, die dies als reine Dokumentenerstellung betrachten, anstatt als Compliance-Prozess mit strukturierten Voraussetzungen und automatisierter Kontrolle, werden mit dieser Durchsetzung konfrontiert, bevor sie eine menschliche Regulierungsbehörde erreichen.

Was dies in der Praxis bedeutet

Das gängige Verständnis eines Krypto-Whitepapers als narrativer Pitch (etwas, das geschrieben wird, um zu überzeugen, statt um offenzulegen) beschreibt eine Dokumentart, die MiCA durch etwas kategorisch anderes ersetzt hat.

Das MiCA-Whitepaper ist ein Rechtsinstrument mit vorgeschriebenem Inhalt, obligatorischen Identifikatoren, einem strukturierten Format, das für automatisierte grenzüberschreitende Vergleichbarkeit ausgelegt ist, und einer namentlich genannten persönlichen Haftung für denjenigen, der es unterzeichnet. Der Zugang zum europäischen Kryptomarkt läuft darüber. Projekte, die die Einreichung als das verstehen, was sie rechtlich ist, anstatt als das, was der Begriff historisch suggerierte, sind diejenigen, die bei der automatisierten Prüfung nicht zurückgewiesen werden.

MiCA entschlüsselt: Der 1. Juli ist nicht die Frist. Für die meisten Dienstleister ist sie bereits abgelaufen

MiCA entschlüsselt: Der 1. Juli ist nicht die Frist. Für die meisten Dienstleister ist sie bereits abgelaufen

„MiCA Decoded“ ist eine wöchentliche Serie mit 12 Artikeln für Bitcoin.com News, die von den Mitbegründern und Geschäftsführern von LegalBison gemeinsam verfasst wird. read more.

Jetzt lesen

Wichtige Erkenntnisse:

  • Das Whitepaper ist kein Marketingdokument. MiCA hat den Begriff neu definiert. Das am ehesten vergleichbare Dokument in der traditionellen Finanzwelt ist ein Wertpapierprospekt, und es sollte mit dem gleichen rechtlichen Gewicht behandelt werden.
  • Drei Anlagekategorien, drei unterschiedliche Wege. OTHR, ART und EMT unterliegen jeweils unterschiedlichen Anforderungen an das Whitepaper und unterschiedlichen Zulassungsvoraussetzungen. Die Eigenschaften des Vermögenswerts bestimmen, welche Kategorie gilt; das Projekt hat keine Wahl.
  • Die Haftung liegt beim Einreicher, doch die Regeln hängen vom Vermögenswert ab. Für die überwiegende Mehrheit der Token (OTHRs) liegt die rechtliche Verpflichtung beim Anbieter oder der Person, die die Zulassung zum Handel beantragt, nicht unbedingt beim ursprünglichen Schöpfer des Tokens. Wenn ein CASP (z. B. ein Betreiber einer Handelsplattform) sich bereit erklärt, im Namen eines OTHR-Projekts ein Whitepaper zu erstellen und zu veröffentlichen, übernimmt er zwar erhebliche regulatorische Pflichten, trägt jedoch nicht die volle Haftung. Gemäß MiCA-Artikel 14(3) bleibt die ursprüngliche Person, die die Zulassung zum Handel beantragt, rechtlich verantwortlich, wenn sie dem CASP unvollständige, unlautere, unklare oder irreführende Informationen zur Verfügung stellt. Man kann die Formalitäten auslagern, aber man kann die Haftung nicht vollständig auslagern.
  • Bei Asset-Referenced Tokens (ARTs) und E-Money Tokens (EMTs) liegt die strenge zivilrechtliche Haftung für das Whitepaper nicht allein beim zugelassenen Emittenten als juristischer Person; sie erstreckt sich ausdrücklich auch auf die Mitglieder seines Verwaltungs-, Leitungs- oder Aufsichtsorgans. Jeder vertragliche Versuch, diese Haftung zu beschränken oder auszuschließen, ist rechtlich unwirksam.
  • LEI und DTI sind Voraussetzungen. Beide Identifikatoren müssen vorliegen, bevor mit der Erstellung des Whitepapers begonnen wird. Wenn für den Vermögenswert kein DTI existiert, muss dieser beim DTIF-Register angefordert werden, bevor weitere Schritte unternommen werden können.
  • Die automatisierte Validierung ist die erste Kontrollinstanz. 257 Existenzprüfungen und 223 Wertprüfungen werden durchgeführt, bevor ein Mensch die Datei überprüft. Ein Dokument, das eine Prüfung auf Fehlerebene nicht besteht, gelangt nicht zur Aufsichtsbehörde.
  • Mehrsprachige Einreichungen bergen eine versteckte technische Verpflichtung. Jede Sprachversion erfordert eine eigene, separat strukturierte Datei, die identisch mit dem Original aufgebaut ist. Eine Übersetzung, die auf Feldebene nicht mit der Quellstruktur übereinstimmt, ist nicht konform.
  • Die inhaltliche Richtigkeit und die technische Gültigkeit sind zwei getrennte Verpflichtungen. Die rechtliche Prüfung deckt die erste ab. Die technische Strukturierung deckt die zweite ab. Beide liegen in der Verantwortung des Anbieters, und keine ersetzt die andere.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Dieser Artikel basiert auf einer Studie, die von LegalBison im April 2026 durchgeführt wurde. Der Inhalt dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar.

Tags in diesem Artikel