The European Union’s MiCA regime is reshaping what a crypto whitepaper actually is. In the market’s traditional understanding, a whitepaper is often a narrative document, a GitBook page, or a downloadable PDF designed to explain a token and persuade users or investors. Under MiCA, however, that concept has been replaced by something much closer to a formal legal filing.
The source article explains that MiCA treats the whitepaper as a mandatory disclosure instrument comparable to a securities prospectus rather than a marketing document. That distinction is not cosmetic. It changes who must prepare the document, what format it must follow, which identifiers it must include, and how regulators evaluate whether the submission even exists in a legally valid form.
A structured filing, not a flexible document
According to the article, Commission Implementing Regulation (EU) 2024/2984 requires crypto-asset whitepapers to be submitted in a structured digital format. The purpose is to allow the European Securities and Markets Authority (ESMA) and national competent authorities across the EU to run consistent automated checks on every filing. In practice, that means a well-written PDF or polished GitBook is not enough if it does not match the required machine-readable structure.
The article stresses that this design serves a legal purpose within the EU internal market. Regulators need comparability across jurisdictions, and a filing that cannot be read and validated using the same framework as every other submission is not considered compliant. ESMA published the required taxonomy on August 5, 2025, and the relevant rules take effect on December 23, 2025.
That structure is not optional. If one of the mandatory technical or formal elements is missing, the document may be treated as though it does not exist from a regulatory standpoint, no matter how clear or detailed its contents may be.
Three token categories, three legal pathways
The article also highlights that MiCA does not impose a one-size-fits-all whitepaper regime. Instead, disclosure obligations differ depending on the type of crypto-asset involved. MiCA separates tokens into three broad categories: OTHR (other crypto-assets, such as many utility tokens), ART (asset-referenced tokens), and EMT (electronic money tokens).
Each category comes with its own whitepaper template, field-level requirements, and legal path to submission. OTHR covers the broadest range of tokens currently on the market. ART applies to tokens referencing a basket of assets and requires authorization before issuance. EMT applies to tokens pegged to a single currency and requires licensing as an electronic money institution or bank.
A central point in the source material is that projects do not get to choose their preferred category. The asset’s actual features determine the classification, and the compliance obligations follow from that classification. In other words, a project cannot simply label its token in the most convenient way to simplify the filing process.
Who is responsible for the whitepaper
One of the most practical compliance questions is who bears the legal obligation to prepare and submit the whitepaper. For most tokens that fall under the OTHR category, the obligation does not automatically rest with the entity that originally created the token. Instead, MiCA places the requirement on the offeror or the person seeking admission to trading. In some cases, a crypto-asset service provider (CASP) operating a trading platform may also assume the whitepaper role.
The article notes that this distinction has real structural consequences. A project based in jurisdictions outside the EU, including offshore locations, may still act as the offeror under MiCA and bear the whitepaper obligation without relocating its legal home to Europe. But that flexibility applies only to OTHR tokens. For ARTs and EMTs, the legal duty and strict civil liability for the whitepaper remain with the authorized EU issuer and cannot simply be delegated away.
Even where a CASP steps in, the compliance burden is substantial. Filing the whitepaper means accepting responsibility for the completeness and accuracy of the disclosed information. The article further emphasizes that legal responsibility cannot be shifted to a software provider, technical integrator, or external law firm. Drafting support can be outsourced, but liability cannot be fully outsourced.
LEI and DTI must exist before filing
Another major takeaway is that two identifiers are mandatory prerequisites for a compliant whitepaper submission: the Legal Entity Identifier (LEI) and the Digital Token Identifier (DTI).
The LEI, based on ISO 17442, identifies the legal entity responsible for the filing. The DTI, based on ISO 24165, identifies the crypto-asset itself and is maintained in the DTIF registry. Under the rules cited in the article, both identifiers are required in the relevant whitepaper and recordkeeping frameworks.
The practical message is simple but important: if a project does not yet have an LEI, it must obtain one before beginning the whitepaper process. If a token does not yet have a DTI in the registry, someone must request its creation before the whitepaper can move forward. In cases where a CASP files for an asset without a central issuer and without an existing whitepaper, the platform may need to obtain or request the DTI directly.
The article warns that a whitepaper missing a valid LEI or DTI will fail automated validation before any human reviewer sees it. For projects that only discover the gap at the submission stage, that can mean restarting the process entirely.
Automated validation is the first gatekeeper
MiCA compliance is not just about legal drafting. The article describes an automated screening architecture that functions as the first gate in the filing process. ESMA’s taxonomy includes 257 existence checks, verifying that mandatory fields are present, and 223 value checks, verifying that the field contents are valid.
If a submission fails a check classified at the “error” level, it is treated as technically invalid and does not proceed. No staff member at a national competent authority will manually review a whitepaper that fails these automated checks. This has a direct legal consequence: technical validity and substantive accuracy are separate obligations, and both belong to the submitting party.
The article offers a useful contrast. A legally strong disclosure in the wrong structure fails immediately. A structurally valid filing with misleading content also fails, but at a different stage and with different consequences. Projects must therefore satisfy both dimensions at once.
Multilingual filings and sustainability fields add complexity
For projects targeting multiple EU member states, the technical burden increases further. Each language version of the whitepaper requires its own separately structured file. Those files must remain internally consistent and mirror the original at the field level, not just in general meaning. A translation may be linguistically accurate, but if its structure does not align with the source filing, it may still be treated as non-compliant.
The article also points to sustainability disclosures as another formal compliance layer. The taxonomy requires energy consumption and carbon emissions to be reported using specified units, namely kWh and tCO2. These are not optional ESG enhancements; they are mandatory disclosure fields. Using alternative units or omitting the required entries can trigger a validation failure.
Why this matters for market access
The broader conclusion is that MiCA has replaced the market’s informal understanding of a crypto whitepaper with a legal instrument that sits directly on the path to EU market access. It has prescribed content, mandatory identifiers, machine-enforced structure, and named responsibility attached to the submitting party.
That shift matters because many crypto teams still approach whitepapers as branding or communications exercises. The article argues that this mindset now creates compliance risk. Under MiCA, a whitepaper is not merely something written to persuade. It is a regulated disclosure process with technical preconditions, filing logic, and automated enforcement before a human regulator ever becomes involved.
For token issuers, offerors, trading applicants, and CASPs, the implication is straightforward: entering the European crypto market requires understanding the whitepaper for what it legally is, not what the industry historically called it. Projects that fail to adapt to that new definition may find themselves rejected before their filing reaches a person at all.