MiCA Ontcijferd: Uw Crypto Whitepaper Kan Niet Zomaar een Gitbook of PDF Zijn – Legal Bitcoin News

MiCA Decoded is een wekelijkse serie van 12 artikelen voor Bitcoin.com News, mede geschreven door de medeoprichters en directeuren van LegalBison: Aaron Glauberman, Viktor Juskin en Sabir Alijev. LegalBison adviseert crypto- en FinTech-bedrijven over MiCA-licenties, CASP- en VASP-aanvragen en regelgevende structurering in Europa en daarbuiten.

Onder MiCA is een whitepaper een verplicht juridisch openbaarmakingsinstrument. De dichtstbijzijnde analogie in traditionele financiën is een effectenprospectus, geen marketingdocument. De verordening schrijft voor wie er een moet opstellen, in welk formaat, met welke identificatiecodes, onderhevig aan welke geautomatiseerde validatie, en met aansprakelijkheid gekoppeld aan een specifiek genoemde persoon.

Als een van deze elementen onjuist is, bestaat het document niet in de ogen van Europese toezichthouders, ongeacht hoe goed geschreven het is.

Deze zesde aflevering van MiCA Decoded legt stuk voor stuk uit wat dat daadwerkelijk betekent.

De mythe: een MiCA-whitepaper is slechts een GitBook of een PDF

Een MiCA-whitepaper heeft het gewicht van een formele regelgevende indiening.

Uitvoeringsverordening (EU) 2024/2984 van de Commissie, die formulieren, formaten en sjablonen voor crypto-assetwhitepapers regelt, vereist dat het document wordt opgesteld in een gestructureerd digitaal formaat dat is ontworpen zodat ESMA en nationale bevoegde autoriteiten in alle EU-lidstaten identieke geautomatiseerde analyses kunnen uitvoeren op elke indiening, ongeacht wie het heeft ingediend of waar.

Het juridische doel van die ontwerpkeuze is belangrijker dan de technische details. MiCA is een eengemaakte marktverordening en vergelijkbaarheid tussen indieningen is een kernhandhavingsinstrument.

Een whitepaper die niet door dezelfde machine kan worden gelezen als elk ander whitepaper dat in Europa is ingediend, is niet compliant, wat de inhoud ook zegt. ESMA heeft de vereiste taxonomie (het gestructureerde raamwerk dat definieert wat een compliant whitepaper moet bevatten) gepubliceerd op 5 augustus 2025. De regels zijn van toepassing vanaf 23 december 2025.

De openbaarmakingsverplichtingen variëren afhankelijk van het type betrokken crypto-asset. MiCA onderscheidt drie categorieën, elk met een eigen whitepaper-sjabloon en veldvereisten:

De categorie bepaalt niet alleen de inhoud van het whitepaper, maar ook het volledige juridische traject om er een in te dienen. Een project kan niet kiezen welke categorie van toepassing is op basis van voorkeur. De kenmerken van het asset bepalen dit, en de voorbereidingsverplichtingen vloeien daaruit voort.

Wie draagt de juridische verplichting – en de aansprakelijkheid

Voor de overgrote meerderheid van tokens op de markt (gecategoriseerd als "Other" crypto-assets, of OTHR), rust de verplichting niet automatisch op de entiteit die de token heeft gecreëerd. Voor deze assets plaatst MiCA de verplichting bij de aanbieder of de persoon die toelating tot handel zoekt, wat gedefinieerde rollen zijn die al dan niet samenvallen met de oorspronkelijke uitgever.

Dit onderscheid heeft reële gevolgen. Een project dat in de OTHR-categorie valt, gelanceerd vanuit de Britse Maagdeneilanden, de Kaaimaneilanden of een ander offshore-rechtsgebied, kan de aanbieder zijn onder MiCA en de whitepaperverplichting rechtstreeks dragen, zonder enige vereiste om de juridische zetel naar Europa te verplaatsen.

(Opmerking: deze structurele flexibiliteit geldt strikt voor OTHR-tokens. Voor Asset-Referenced Tokens en E-Money Tokens berust de juridische verplichting en strikte civiele aansprakelijkheid voor het whitepaper volledig bij de geautoriseerde EU-uitgever en kan niet worden gedelegeerd).

Zoals we onderzochten in de tweede aflevering van deze serie, bevestigen de ESMA-registers dat dit al standaardpraktijk is: de meerderheid van onafhankelijke tokenindieningen komt van entiteiten met hoofdkantoor buiten de EU.

Een CASP die een handelsplatform exploiteert, kan ook de whitepaperverplichting op zich nemen, hetzij op eigen initiatief, hetzij via schriftelijke overeenkomst met het projectteam. Dat is geen maas in de wet of een administratief gemak.

Wanneer een CASP indient, neemt het de juridische verantwoordelijkheid voor de juistheid en volledigheid van de openbaarmaking op zich. Als het whitepaper misleidende informatie bevat of niet voldoet aan regelgevende normen, behoort de aansprakelijkheid toe aan degene die het heeft ingediend.

De persoon die het whitepaper aftekent, kan die verantwoordelijkheid niet delegeren aan een softwareleverancier, een technische integrator of een advocatenkantoor. Juridische beoordeling van inhoud en technische validiteit zijn twee afzonderlijke nalevingsverplichtingen, en beide rusten bij de aanbieder. Dit is het punt dat de meeste projecten onderschatten.

Twee codes die moeten bestaan voordat de indiening begint

Twee verplichte identificatiecodes zijn vereisten voor elk compliant whitepaper. Beide zijn afkomstig van internationale normen die MiCA voorafgaan. De verordening heeft ze niet gecreëerd, maar verplicht gesteld.

De eerste is de Legal Entity Identifier (LEI), een ISO 17442-code toegewezen aan juridische entiteiten en bijgehouden in de Global LEI-database beheerd door GLEIF. Het mandaat voor het gebruik ervan omvat meerdere regelgevende normen: terwijl artikel 14 van de registratie-RTS (Gedelegeerde Verordening (EU) 2025/1140 van de Commissie) LEI-vereisten aan CASP's oplegt voor hun klanten, schrijft artikel 3 van de whitepaper-classificatie-RTS (Gedelegeerde Verordening (EU) 2025/421 van de Commissie) strikt voor dat alle whitepaper-opstellers hun eigen juridische entiteit moeten identificeren met een geldige LEI-code. Voor elke entiteit die er nog geen heeft, moet het LEI-aanvraagproces worden voltooid voordat de voorbereiding van het whitepaper begint.

De tweede is de Digital Token Identifier (DTI), een ISO 24165-code die de crypto-asset zelf identificeert, bijgehouden in het DTIF-register. Artikel 15 van de registratie-RTS en artikel 3 van de whitepaper-classificatie-RTS (Gedelegeerde Verordening (EU) 2025/421 van de Commissie) vereisen het gebruik ervan. Het operationele punt voor elk project dat een nieuwe token lanceert: als de DTI nog niet in het register bestaat, moet iemand de aanmaak ervan aanvragen voordat het whitepaper kan worden ingediend. Wanneer een CASP indient voor een asset zonder gecentraliseerde uitgever en geen bestaand whitepaper, is het platform verantwoordelijk voor het ophalen of aanvragen van de DTI rechtstreeks bij het DTIF.

Bron: het DTIF-register voor crypto-assets

Een whitepaper dat geen geldige LEI en DTI bevat, faalt de geautomatiseerde validatie voordat een menselijke beoordelaar het ziet. Projecten die de indieningsfase bereiken zonder beide codes bij de hand, krijgen te maken met een volledige herstart.

De geautomatiseerde poort en wat het juridisch betekent

Geen mens bij een nationale bevoegde autoriteit beoordeelt een whitepaper dat zijn geautomatiseerde controles niet doorstaat. De ESMA-taxonomie definieert 257 aanwezigheidscontroles (verificatie dat vereiste velden aanwezig zijn) en 223 waardecontroles (verificatie dat veldinhoud geldig is). Een indiening die een controle met de ernst "Error" niet doorstaat, is technisch ongeldig. Het document gaat niet verder.

De juridische implicatie van die architectuur is direct: technische validiteit en inhoudsnauwkeurigheid zijn beide de verantwoordelijkheid van de aanbieder. Een perfect opgestelde juridische openbaarmaking in de verkeerde structuur faalt. Een structureel geldig bestand met misleidende inhoud faalt ook; het faalt simpelweg in een andere fase en met andere gevolgen.

Projecten die tokens aanbieden in meerdere EU-lidstaten krijgen te maken met een extra laag. Elke taalversie van het whitepaper vereist een eigen afzonderlijk gestructureerd bestand. Alle taalversies moeten intern consistent zijn en niet alleen vertaald, maar identiek georganiseerd op veldniveau. Een vertaling die de structuur van het origineel niet weerspiegelt, is technisch niet-compliant, ongeacht de taalkundige nauwkeurigheid.

Duurzaamheidsopenbaarmakingen voegen een verdere beperking toe. De taxonomie schrijft specifieke meeteenheden voor energieverbruik en CO2-emissies voor: respectievelijk kWh en tCO2. Dit zijn wettelijke openbaarmakingsvereisten, geen optionele milieuraapportage. Indienen met andere eenheden of het weglaten van de velden leidt tot een validatiefout.

Het patroon in al deze vereisten is hetzelfde: het whitepaper is een juridische indiening met machine-afgedwongen normen. Projecten die het benaderen als een documentschrijfoefening, in plaats van als een nalevingsproces met gestructureerde vereisten en geautomatiseerde toegangscontrole, zullen die handhaving tegenkomen voordat ze een menselijke toezichthouder bereiken.

Wat dit in de praktijk betekent

Het populaire begrip van een crypto-whitepaper als een narratieve pitch (iets geschreven om te overtuigen in plaats van om openbaar te maken) beschrijft een documenttype dat MiCA heeft vervangen door iets categorisch anders.

Het MiCA-whitepaper is een juridisch instrument met voorgeschreven inhoud, verplichte identificatiecodes, een gestructureerd formaat ontworpen voor geautomatiseerde grensoverschrijdende vergelijkbaarheid, en persoonlijke aansprakelijkheid gekoppeld aan degene die het aftekent. De toegangspoort tot de Europese cryptomarkt loopt erdoorheen. Projecten die de indiening begrijpen voor wat het juridisch is, in plaats van wat de term historisch suggereerde, zijn degenen die niet worden teruggestuurd bij de geautomatiseerde controle.

Belangrijkste conclusies:

• Het whitepaper is geen marketingdocument. MiCA heeft de term opnieuw gedefinieerd. Het dichtstbijzijnde equivalent in traditionele financiën is een effectenprospectus, en het moet met hetzelfde juridische gewicht worden behandeld.
• Drie assetcategorieën, drie verschillende trajecten. OTHR, ART en EMT hebben elk verschillende whitepapervereisten en verschillende autorisatievereisten. De kenmerken van het asset bepalen welke categorie van toepassing is, het project kiest niet.
• Aansprakelijkheid volgt de indiener, maar de regels zijn afhankelijk van het asset. Voor de overgrote meerderheid van tokens (OTHR's) behoort de juridische verplichting toe aan de aanbieder of de persoon die toelating tot handel zoekt, niet noodzakelijkerwijs de oorspronkelijke maker van de token. Wanneer een CASP (zoals een handelsplatformoperator) instemt met het opstellen en publiceren van een whitepaper namens een OTHR-project, neemt het aanzienlijke regelgevende taken op zich, maar het neemt de aansprakelijkheid niet volledig over. Onder MiCA artikel 14(3) blijft de oorspronkelijke persoon die toelating tot handel zoekt juridisch verantwoordelijk als zij onvolledige, oneerlijke, onduidelijke of misleidende informatie aan de CASP verstrekken. Je kunt het papierwerk uitbesteden, maar je kunt de aansprakelijkheid niet volledig uitbesteden.
• Voor Asset-Referenced Tokens (ART's) en E-Money Tokens (EMT's) berust de strikte civiele aansprakelijkheid voor het whitepaper niet alleen bij de geautoriseerde uitgever als bedrijfsentiteit; het strekt zich expliciet uit tot de leden van het bestuurs-, management- of toezichthoudend orgaan. Elke contractuele poging om deze aansprakelijkheid te beperken of uit te sluiten is juridisch nietig.
• LEI en DTI zijn vereisten. Beide identificatiecodes moeten aanwezig zijn voordat de voorbereiding van het whitepaper begint. Als een DTI niet bestaat voor het asset, moet het worden aangevraagd bij het DTIF-register voordat iets anders verder gaat.
• Geautomatiseerde validatie is de eerste poortwachter. 257 aanwezigheidscontroles en 223 waardecontroles worden uitgevoerd voordat een mens het bestand beoordeelt. Een document dat een bewering op fout-niveau niet doorstaat, bereikt geen toezichthouder.
• Meertalige indieningen brengen een verborgen technische verplichting met zich mee. Elke taalversie vereist een eigen afzonderlijk gestructureerd bestand, identiek georganiseerd aan het origineel. Een vertaling die de bronstructuur op veldniveau niet weerspiegelt, is niet-compliant.
• Inhoudsnauwkeurigheid en technische validiteit zijn twee afzonderlijke verplichtingen. Juridische beoordeling dekt de eerste. Technische structurering dekt de tweede. Beide rusten bij de aanbieder, en geen van beide vervangt de ander.

Dit artikel is gebaseerd op een onderzoek uitgevoerd door LegalBison in april 2026. De inhoud is alleen voor informatieve doeleinden en vormt geen juridisch advies.