When most people hear crypto white paper, they think of Satoshi Nakamoto’s nine-page document, or an ICO-era pitch deck dressed up in technical language. MiCA has a different definition, and the gap between the popular understanding and the legal reality is where many compliance failures begin.
MiCA Decoded is a 12-article weekly series for Bitcoin.com News, co-authored by LegalBison’s Co-Founding and Managing Directors: Aaron Glauberman, Viktor Juskin and Sabir Alijev. LegalBison advises crypto and FinTech companies on MiCA licensing, CASP and VASP applications, and regulatory structuring across Europe and beyond.
Under MiCA, a white paper is a mandatory legal disclosure instrument. Its closest analogy in traditional finance is a securities prospectus, not a marketing document. The regulation prescribes who must prepare one, in what format, containing what identifiers, subject to what automated validation, and with liability attached to a specific named person.
Getting any of those elements wrong means the document does not exist in the eyes of European regulators, regardless of how well-written it is.
This sixth installment of MiCA Decoded unpacks what that actually means, piece by piece.
The Myth: A MiCA White Paper is Just a GitBook or a PDF
A MiCA white paper carries the weight of a formal regulatory filing.
Commission Implementing Regulation (EU) 2024/2984, which governs forms, formats, and templates for crypto-asset white papers, requires that the document be prepared in a structured digital format designed so that ESMA and national competent authorities across all EU member states can run identical automated analysis on every submission, regardless of who filed it or where.
The legal purpose of that design choice matters more than the technical specifics. MiCA is a single-market regulation, and comparability across filings is a core enforcement tool.
A white paper that cannot be read by the same machine as every other white paper filed in Europe is not compliant, whatever its content says. ESMA published the required taxonomy (the structured framework that defines what a compliant white paper must contain) on 5 August 2025. The rules apply as of 23 December 2025.
The disclosure obligations vary depending on the type of crypto-asset involved. MiCA draws three distinct categories, each with its own white paper template and field requirements:
The category determines not just the content of the white paper, but the entire legal path to filing one. A project cannot choose which category applies based on preference. The asset’s characteristics determine it, and the preparation obligations follow from there.
Who Carries the Legal Obligation – and the Liability
For the vast majority of tokens in the market (categorized as “Other” crypto-assets, or OTHR), the obligation does not automatically fall on the entity that created the token. For these assets, 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 consequences. A project falling into the OTHR category, launched from the British Virgin Islands, the Caymans, or any other offshore jurisdiction, can be the offeror under MiCA and carry the white paper obligation directly, without any requirement to relocate its legal seat to Europe.
(Note: This structural flexibility strictly applies to OTHR tokens. For Asset-Referenced Tokens and E-Money Tokens, the legal obligation and strict civil liability for the white paper rest entirely with the authorized EU issuer and cannot be delegated).
As we examined in the second installment of this series, the ESMA registers confirm this is already standard practice: the majority of independent token filings come from entities headquartered outside the EU.
A CASP operating a trading platform can also take on the white paper obligation, either on its own initiative or by written agreement with the project team. That is not a loophole or an administrative convenience.
When a CASP files, it assumes legal responsibility for the accuracy and completeness of the disclosure. If the white paper contains misleading information or fails regulatory standards, the liability belongs to whoever submitted it.
The person signing off on the white paper cannot delegate that exposure to a software vendor, a technical integrator, or a law firm. Legal review of content and technical validity are two separate compliance obligations, and both rest with the offeror. This is the point most projects underestimate.
Two Codes That Must Exist Before Filing Begins
Two mandatory identifiers are prerequisites for any compliant white paper. Both are drawn from international standards that predate MiCA. The regulation did not create them, it made them compulsory.
The first is the Legal Entity Identifier (LEI), an ISO 17442 code assigned to legal entities and maintained in the Global LEI database administered by GLEIF. The mandate for its use spans multiple regulatory standards: while Article 14 of the record-keeping RTS (Commission Delegated Regulation EU 2025/1140) enforces LEI requirements on CASPs for their clients, Article 3 of the white paper classification RTS (Commission Delegated Regulation EU 2025/421) strictly mandates that all white paper preparers must identify their own legal entity with a valid LEI code. For any entity that does not already hold one, the LEI application process must be completed before white paper preparation begins.
The second is the Digital Token Identifier (DTI), an ISO 24165 code that identifies the crypto-asset itself, maintained in the DTIF registry. Article 15 of the record-keeping RTS and Article 3 of the white paper classification RTS (Commission Delegated Regulation EU 2025/421) require its use. The operative point for any project launching a new token: if the DTI does not yet exist in the registry, someone must request its creation before the white paper can be submitted. Where a CASP is filing for an asset with no centralized issuer and no existing white paper, the platform is responsible for retrieving or requesting the DTI directly from the DTIF.
Source: the DTIF Registry for crypto-assets
A white paper that does not contain a valid LEI and DTI fails automated validation before any human reviewer sees it. Projects that reach the submission stage without both codes in hand face a full restart.
The Automated Gate and What It Means Legally
No human at a national competent authority reviews a white paper that fails its automated checks. The ESMA taxonomy defines 257 existence checks (verifying that required fields are present) and 223 value checks (verifying that field content is valid). A filing that fails a check rated “Error” severity is technically invalid. The document does not proceed.
The legal implication of that architecture is direct: technical validity and content accuracy are equally the offeror’s responsibility. A perfectly drafted legal disclosure in the wrong structure fails. A structurally valid file with misleading content also fails; it simply fails at a different stage and with different consequences.
Projects offering tokens in multiple EU member states face an additional layer. Each language version of the white paper requires its own separately structured file. All language versions must be internally consistent and not just 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 mandates specific units of measure for energy consumption and CO2 emissions: kWh and tCO2, respectively. These are legal disclosure requirements, not optional environmental reporting. Filing with different units or omitting the fields triggers a validation failure.
The pattern across all of these requirements is the same: the white paper is a legal filing with machine-enforced standards. Projects that approach it as a document-writing exercise, rather than a compliance process with structured prerequisites and automated gatekeeping, will encounter that enforcement before they reach a human regulator.
What This Means in Practice
The popular understanding of a crypto white paper as a narrative pitch (something written to persuade rather than to disclose) describes a document type that MiCA has replaced with something categorically different.
The MiCA white paper is a legal instrument with prescribed content, mandatory identifiers, a structured format designed for automated cross-border comparability, and named personal liability attached to whoever signs off on it. The entry gate to the European crypto market runs through it. Projects that understand the filing for what it legally is, rather than what the term historically suggested, are the ones that do not get turned back at the automated check.
Key Takeaways:
- The white paper is not a marketing document. MiCA redefined the term. The closest equivalent in traditional finance is a securities prospectus, and it should be treated with the same legal weight.
- Three asset categories, three different paths. OTHR, ART and EMT each carry distinct white paper requirements and different authorization prerequisites. The asset’s characteristics determine which category applies, the project does not choose.
- Liability follows the filer, but the rules depend on the asset. For the vast majority of tokens (OTHRs), the legal obligation belongs to the offeror or the person seeking admission to trading, not necessarily the token’s original creator. When a CASP (such as a trading platform operator) agrees to prepare and publish a white paper on behalf of an OTHR project, it takes on significant regulatory duties, but it does not assume the liability fully. Under MiCA Article 14(3), the original person seeking admission to trading remains legally responsible if they provide incomplete, unfair, unclear, or misleading information to the CASP. You can outsource the paperwork, but you cannot entirely outsource the liability.
- For Asset-Referenced Tokens (ARTs) and E-Money Tokens (EMTs), strict civil liability for the white paper does not rest solely with the authorized issuer as a corporate entity; it explicitly extends to the members of its administrative, management, or supervisory body. Any contractual attempt to limit or exclude this liability is legally void.
- LEI and DTI are prerequisites. Both identifiers must be in place before white paper preparation begins. If a DTI does not exist for the asset, it must be requested from the DTIF registry before anything else moves forward.
- Automated validation is the first gatekeeper. 257 existence checks and 223 value checks run before any human reviews the file. A document that fails an Error-level assertion does not reach a regulator.
- Multilingual filings carry a hidden technical obligation. Each language version requires its own separately structured file, organized identically to the original. A translation that does not match the source structure at the field level is non-compliant.
- Content accuracy and technical validity are two separate obligations. Legal review covers the first. Technical structuring covers the second. Both rest with the offeror, and neither substitutes for the other.
This article is based on a study conducted by LegalBison in April 2026. The content is for informational purposes only and does not constitute legal advice.
