When most people hear the term “crypto whitepaper,” they think of Satoshi Nakamoto’s nine-page document or ICO-era pitch decks wrapped in technical jargon. But the EU’s Markets in Crypto-Assets Regulation (MiCA) has a different definition, and the gap between common perception and legal reality is the source of many regulatory violations.
No Longer a Marketing Document
Under MiCA, a whitepaper is a mandatory legal disclosure instrument. Its closest analogy in traditional finance is a securities prospectus, not a marketing document. The Commission’s Implementing Regulation (EU) 2024/2984, which governs the forms, formats and templates for crypto-asset whitepapers, requires that the document be prepared in a structured digital format designed so that ESMA and national competent authorities in all EU member states can run identical automated analyses on every submission, regardless of who submitted it or where.
The legal purpose of this design choice is more important than the technical details. MiCA is an internal market regulation, and comparability across submissions is a core enforcement tool. A whitepaper that cannot be read by the same machine as every other whitepaper filed in Europe is non-compliant, regardless of what the content says. ESMA published the required taxonomy on August 5, 2025. The rules take effect on December 23, 2025.
Three Asset Categories, Three Different Paths
MiCA sets three different whitepaper templates based on the type of crypto-asset: OTHR (other crypto-assets, e.g., utility tokens), ART (asset-referenced tokens), and EMT (electronic money tokens). Each category has its own template and field requirements. The asset’s characteristics determine the category; the project cannot choose based on preference.
Who Bears the Obligation — and Liability
For the vast majority of tokens on the market (OTHR), the obligation does not automatically fall on the entity that created the token. Instead, MiCA places the obligation on the offeror or the person seeking admission to trading, which are defined roles that may or may not coincide with the original issuer. This distinction has real-world consequences. A project falling into the OTHR category, launched from the British Virgin Islands, Cayman Islands or any other offshore jurisdiction, can be the offeror under MiCA and bear the whitepaper obligation directly, without any requirement to move its legal seat to Europe.
However, this structural flexibility applies exclusively to OTHR tokens. For asset-referenced tokens and e-money tokens, the legal obligation and strict civil liability for the whitepaper fall solely on the authorized EU issuer and cannot be delegated. A CASP (crypto-asset service provider) operating a trading platform may assume the whitepaper obligation, but under MiCA Article 14(3), the original person seeking admission to trading remains legally liable if they provide incomplete, unfair, unclear or misleading information to the CASP. You can outsource the paperwork, but you cannot fully outsource the responsibility.
Two Codes Required Before Submission
Two mandatory identifiers are prerequisites for any compliant whitepaper. The first is a Legal Entity Identifier (LEI), an ISO 17442 code assigned to legal entities and maintained in the global LEI database administered by GLEIF. The second is a Digital Token Identifier (DTI), an ISO 24165 code that identifies the crypto-asset itself and is maintained in the DTIF registry. If the DTI does not yet exist in the registry, someone must request its creation before the whitepaper can be submitted. A whitepaper lacking a valid LEI and DTI fails automated validation before a human reviewer ever sees it.
Automated Validation: The First Gatekeeper
The ESMA taxonomy defines 257 existence checks (verifying that mandatory fields are present) and 223 value checks (verifying that field content is valid). A submission that fails a check with severity level “Error” is technically invalid. The document does not proceed further. This architecture means that technical validity and content accuracy are equally the offeror’s responsibility. A perfectly drafted legal disclosure in the wrong structure fails. A structurally sound file with misleading content also fails — it just fails at a different step with different consequences.
Projects offering tokens in multiple EU member states face an additional layer. Each language version of the whitepaper requires its own separately structured file. All language versions must be internally consistent and not merely translated, but identically organized at the field level. A translation that does not mirror the structure of the original is technically non-compliant, regardless of its linguistic accuracy. Sustainability disclosures add a further constraint: the taxonomy prescribes specific units of measurement for energy consumption and CO2 emissions — kWh and tCO2 respectively. These are statutory disclosure requirements, not optional environmental reporting.
What This Means in Practice
The common perception of a crypto whitepaper as a narrative presentation (something written to persuade rather than inform) describes a document type that MiCA has replaced with something categorically different. The MiCA whitepaper is a legal instrument with prescribed content, mandatory identifiers, a structured format designed for automated cross-border comparability, and named personal liability attached to the person who signs it. The gate to the European crypto market passes through it. Projects that understand the submission for what it is legally, rather than what the term historically suggested, are the ones that will not be rejected at the automated check.