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 PDFA MiCA white paper carries the weight of a formal regulatory filing.
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.
Asset Type Who Prepares the White Paper Key Characteristic OTHER (Other crypto-assets, e.g., utility tokens) Offeror, person seeking admission to trading, or CASP operating a trading platform Broadest category; covers the majority of tokens currently in the market ART (Asset-Referenced Tokens) Authorised issuer or credit institution References a basket of assets; authorization required before issuance EMT (Electronic Money Tokens) Credit institution or electronic money institution Single-currency peg; requires EMI or banking authorizationThe 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 LiabilityFor 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).
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 BeginsTwo 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.
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 LegallyThe 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 PracticeKey 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.
