MiCA entschlüsselt: Ihr Krypto-Whitepaper kann nicht einfach nur ein Gitbook oder PDF sein – Legal Bitcoin News

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

Unter MiCA ist ein Whitepaper ein obligatorisches rechtliches Offenlegungsinstrument. Die engste Analogie im traditionellen Finanzwesen ist ein Wertpapierprospekt, kein Marketingdokument. Die Verordnung schreibt vor, wer eines erstellen muss, in welchem Format, mit welchen Identifikatoren, unterliegen welcher automatisierten Validierung und mit Haftung, die an eine bestimmte benannte Person gebunden ist.

Wenn eines dieser Elemente falsch ist, bedeutet dies, dass das Dokument in den Augen der europäischen Regulierungsbehörden nicht existiert, unabhängig davon, wie gut es geschrieben ist.

Diese sechste Folge von MiCA Decoded erklärt Stück für Stück, was das tatsächlich 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 Formulare, Formate und Vorlagen für Krypto-Asset-Whitepapers regelt, verlangt, dass das Dokument in einem strukturierten digitalen Format erstellt wird, das so konzipiert ist, dass ESMA und die nationalen zuständigen Behörden in allen EU-Mitgliedstaaten bei jeder Einreichung identische automatisierte Analysen durchführen können, unabhängig davon, wer sie eingereicht hat oder wo.

Der rechtliche Zweck dieser Designentscheidung ist wichtiger als die technischen Details. MiCA ist eine Binnenmarktverordnung, und die Vergleichbarkeit zwischen Einreichungen ist ein zentrales Durchsetzungsinstrument.

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 sagt. ESMA hat die erforderliche Taxonomie (das strukturierte Framework, das definiert, was ein konformes Whitepaper enthalten muss) am 05.08.2025 veröffentlicht. Die Regeln gelten ab dem 23.12.2025.

Die Offenlegungspflichten variieren je nach Art des beteiligten Krypto-Assets. MiCA unterscheidet drei verschiedene Kategorien, jede mit ihrer eigenen Whitepaper-Vorlage und Feldanforderungen:

Die Kategorie bestimmt nicht nur den Inhalt des Whitepapers, sondern den gesamten rechtlichen Weg zur Einreichung eines solchen. Ein Projekt kann nicht basierend auf Präferenzen wählen, welche Kategorie gilt. Die Eigenschaften des Assets bestimmen dies, und die Vorbereitungspflichten folgen daraus.

Wer trägt die rechtliche Verpflichtung – und die Haftung

Für die überwiegende Mehrheit der Token auf dem Markt (kategorisiert als „Other" Krypto-Assets oder OTHR) fällt die Verpflichtung nicht automatisch auf die Einheit, die den Token erstellt hat. Für diese Assets legt MiCA die Verpflichtung auf den Anbieter oder die Person, die die Zulassung zum Handel anstrebt, was definierte Rollen sind, die mit dem ursprünglichen Emittenten übereinstimmen können oder auch nicht.

Diese Unterscheidung hat reale Konsequenzen. Ein Projekt, das in die OTHR-Kategorie fällt und von den Britischen Jungferninseln, den Caymans oder einer anderen Offshore-Jurisdiktion aus gestartet wurde, kann gemäß MiCA der Anbieter sein und die Whitepaper-Verpflichtung direkt tragen, ohne dass eine Verlegung des Rechtssitzes nach Europa erforderlich ist.

(Hinweis: Diese strukturelle Flexibilität gilt ausschließlich für OTHR-Token. Für Asset-Referenced Tokens und E-Money Tokens liegt die rechtliche Verpflichtung und die strikte zivilrechtliche Haftung für das Whitepaper vollständig beim autorisierten EU-Emittenten und kann nicht delegiert werden).

Wie wir in der zweiten Folge dieser Serie untersucht haben, bestätigen die ESMA-Register, dass dies bereits Standardpraxis ist: Die Mehrheit der unabhängigen Token-Einreichungen stammt von Einheiten mit Hauptsitz außerhalb der EU.

Ein CASP, der eine Handelsplattform betreibt, kann auch die Whitepaper-Verpflichtung übernehmen, entweder auf eigene Initiative oder durch schriftliche Vereinbarung mit dem Projektteam. Das ist keine Lücke oder eine administrative Bequemlichkeit.

Wenn ein CASP einreicht, übernimmt er die rechtliche Verantwortung für die Genauigkeit und Vollständigkeit der Offenlegung. Wenn das Whitepaper irreführende Informationen enthält oder regulatorische Standards nicht erfüllt, gehört die Haftung demjenigen, der es eingereicht hat.

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

Zwei Codes, die vor Beginn der Einreichung existieren müssen

Zwei obligatorische Identifikatoren sind Voraussetzungen für jedes konforme Whitepaper. Beide stammen aus internationalen Standards, die MiCA vorausgehen. Die Verordnung hat sie nicht geschaffen, sie hat sie verbindlich gemacht.

Der erste ist der Legal Entity Identifier (LEI), ein ISO 17442-Code, der juristischen Personen zugewiesen wird und in der globalen LEI-Datenbank, die von GLEIF verwaltet wird, gepflegt wird. Das Mandat für seine Verwendung erstreckt sich über mehrere regulatorische Standards: Während Artikel 14 der Aufzeichnungs-RTS (Delegierte Verordnung (EU) 2025/1140 der Kommission) LEI-Anforderungen für CASPs für ihre Kunden durchsetzt, schreibt Artikel 3 der Whitepaper-Klassifizierungs-RTS (Delegierte Verordnung (EU) 2025/421 der Kommission) strikt vor, dass alle Whitepaper-Ersteller ihre eigene juristische Person mit einem gültigen LEI-Code identifizieren müssen. Für jede Einheit, die noch keinen besitzt, muss der LEI-Antragsprozess abgeschlossen sein, bevor die Whitepaper-Vorbereitung beginnt.

Der zweite ist der Digital Token Identifier (DTI), ein ISO 24165-Code, der das Krypto-Asset selbst identifiziert und im DTIF-Register gepflegt wird. Artikel 15 der Aufzeichnungs-RTS und Artikel 3 der Whitepaper-Klassifizierungs-RTS (Delegierte Verordnung (EU) 2025/421 der Kommission) erfordern seine Verwendung. Der operative Punkt für jedes Projekt, das einen neuen Token startet: Wenn der DTI noch nicht im Register existiert, muss jemand seine Erstellung anfordern, bevor das Whitepaper eingereicht werden kann. Wenn ein CASP für ein Asset ohne zentralisierten Emittenten und ohne bestehendes Whitepaper einreicht, ist die Plattform dafür verantwortlich, den DTI direkt vom DTIF abzurufen oder anzufordern.

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 ein menschlicher Prüfer es sieht. Projekte, die die Einreichungsphase ohne beide Codes erreichen, stehen vor einem vollständigen Neustart.

Das automatisierte Tor und was es rechtlich bedeutet

Kein Mensch bei einer nationalen zuständigen Behörde prüft ein Whitepaper, das seine automatisierten Prüfungen nicht besteht. Die ESMA-Taxonomie definiert 257 Existenzprüfungen (Überprüfung, ob erforderliche Felder 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 geht nicht weiter.

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

Projekte, die Token in mehreren EU-Mitgliedstaaten anbieten, stehen vor einer zusätzlichen Ebene. Jede Sprachversion des Whitepapers erfordert ihre eigene separat strukturierte Datei. Alle Sprachversionen müssen intern konsistent sein und nicht nur übersetzt, sondern 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 fügen eine weitere Einschränkung hinzu. Die Taxonomie schreibt spezifische Maßeinheiten für Energieverbrauch und CO2-Emissionen vor: kWh bzw. tCO2. Dies sind rechtliche Offenlegungsanforderungen, keine optionale Umweltberichterstattung. Die Einreichung mit anderen Einheiten oder das Weglassen der Felder löst einen Validierungsfehler aus.

Das Muster über alle diese Anforderungen hinweg ist dasselbe: Das Whitepaper ist eine rechtliche Einreichung mit maschinell durchgesetzten Standards. Projekte, die es als Dokumentenschreibübung betrachten, anstatt als Compliance-Prozess mit strukturierten Voraussetzungen und automatisiertem Gatekeeping, werden auf diese Durchsetzung stoßen, bevor sie einen menschlichen Regulierer erreichen.

Was das in der Praxis bedeutet

Das populäre Verständnis eines Krypto-Whitepapers als narrativer Pitch (etwas, das geschrieben wurde, um zu überzeugen, anstatt offenzulegen) beschreibt einen Dokumententyp, den MiCA durch etwas kategorial Anderes ersetzt hat.

Das MiCA-Whitepaper ist ein rechtliches Instrument mit vorgeschriebenem Inhalt, obligatorischen Identifikatoren, einem strukturierten Format, das für automatisierte grenzüberschreitende Vergleichbarkeit konzipiert ist, und einer namentlich genannten persönlichen Haftung, die an denjenigen gebunden ist, der es abzeichnet. Das Eintrittstor zum europäischen Kryptomarkt führt darüber. Projekte, die die Einreichung für das verstehen, was sie rechtlich ist, anstatt für das, was der Begriff historisch suggeriert hat, sind diejenigen, die bei der automatisierten Prüfung nicht zurückgewiesen werden.

Wichtigste Erkenntnisse:

• Das Whitepaper ist kein Marketingdokument. MiCA hat den Begriff neu definiert. Das nächstgelegene Äquivalent im traditionellen Finanzwesen ist ein Wertpapierprospekt, und es sollte mit dem gleichen rechtlichen Gewicht behandelt werden.
• Drei Asset-Kategorien, drei verschiedene Wege. OTHR, ART und EMT haben jeweils unterschiedliche Whitepaper-Anforderungen und unterschiedliche Autorisierungsvoraussetzungen. Die Eigenschaften des Assets bestimmen, welche Kategorie gilt, das Projekt wählt nicht.
• Die Haftung folgt dem Einreicher, aber die Regeln hängen vom Asset ab. Für die überwiegende Mehrheit der Token (OTHRs) liegt die rechtliche Verpflichtung beim Anbieter oder der Person, die die Zulassung zum Handel anstrebt, nicht unbedingt beim ursprünglichen Ersteller des Token. Wenn ein CASP (wie ein Handelsplattformbetreiber) zustimmt, ein Whitepaper im Namen eines OTHR-Projekts zu erstellen und zu veröffentlichen, übernimmt er erhebliche regulatorische Pflichten, aber er übernimmt die Haftung nicht vollständig. Gemäß MiCA Artikel 14(3) bleibt die ursprüngliche Person, die die Zulassung zum Handel anstrebt, rechtlich verantwortlich, wenn sie unvollständige, unfaire, unklare oder irreführende Informationen an den CASP liefert. Sie können den Papierkram auslagern, aber Sie können die Haftung nicht vollständig auslagern.
• Für Asset-Referenced Tokens (ARTs) und E-Money Tokens (EMTs) liegt die strikte zivilrechtliche Haftung für das Whitepaper nicht nur beim autorisierten Emittenten als Unternehmenseinheit; sie erstreckt sich ausdrücklich auf die Mitglieder seiner Verwaltungs-, Geschäftsführungs- oder Aufsichtsorgane. Jeder vertragliche Versuch, diese Haftung zu begrenzen oder auszuschließen, ist rechtlich nichtig.
• LEI und DTI sind Voraussetzungen. Beide Identifikatoren müssen vorhanden sein, bevor die Whitepaper-Vorbereitung beginnt. Wenn ein DTI für das Asset nicht existiert, muss er vom DTIF-Register angefordert werden, bevor etwas anderes voranschreitet.
• Die automatisierte Validierung ist der erste Gatekeeper. 257 Existenzprüfungen und 223 Wertprüfungen laufen, bevor ein Mensch die Datei prüft. Ein Dokument, das eine Assertion auf Fehlerebene nicht besteht, erreicht keinen Regulierer.
• Mehrsprachige Einreichungen haben eine verborgene technische Verpflichtung. Jede Sprachversion erfordert ihre eigene separat strukturierte Datei, die identisch zum Original organisiert ist. Eine Übersetzung, die nicht mit der Quellstruktur auf Feldebene übereinstimmt, ist nicht konform.
• Inhaltliche Genauigkeit und technische Gültigkeit sind zwei separate Verpflichtungen. Die rechtliche Prüfung deckt das Erste ab. Die technische Strukturierung deckt das Zweite ab. Beide liegen beim Anbieter, und keine ersetzt die andere.

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