What a MiCA White Paper Actually Is (And Why Your Old One Won't Work)

A MiCA white paper is not a pitch deck, not a marketing document, and not the 40-page manifesto you wrote during your hackathon. It's a liability document. Treat it like one.

The Crypto Brief is where I write about MiCA, crypto regulation, and the legal side of building in Europe. If you want to get new articles, subscribe.

If you're planning to offer a crypto-asset to the public in the EU or get it listed on a trading platform, you almost certainly need a white paper. Not the kind you're used to. A MiCA white paper.

The name is the same. Everything else is different.

Forget What You Know About Crypto White Papers

The traditional crypto white paper was a marketing tool. A vision document. Part technical explainer, part pitch deck, part manifesto. Bitcoin had one. Ethereum had one. Most ICOs had one that promised the moon and delivered somewhere between nothing and a lawsuit.

MiCA white papers are a different animal entirely. Think of them less as white papers and more as prospectuses. They are regulated documents with mandatory content, a prescribed format, legal liability attached to every claim, and a regulator reviewing them before (or after) publication.

The shift is fundamental, because a traditional white paper was written to attract investors, whereas a MiCA white paper is written to inform them and to protect them. The audience is the same. The purpose is opposite.

Who neds one

Three categories of issuers, three different regimes:

Ordinary crypto-assets (Title II)

If you're offering a crypto-asset that isn't an ART or EMT to the public in the EU, or seeking to have it admitted to trading, you need a white paper. You notify it to your national competent authority and publish it. The NCA does not approve it, but it can object.

Asset-Referenced Tokens (Title III)

If you're issuing an ART, the white paper is part of your authorization application. The NCA must approve it before you can publish it or offer the token. Stricter content requirements apply.

E-Money Tokens (Title IV)

EMT issuers who are already authorized as credit or e-money institutions notify and publish the white paper. No pre-approval, but the same content standards apply.

Who doesn't need one?

If your offering is limited to fewer than 150 persons per member state, or the total consideration is under EUR 1 million over 12 months, or the offer is exclusively to qualified investors, you may be exempt. But these exemptions are narrow and don't apply to admission to trading.

What must be in it?

Article 6 of MiCA prescribes the mandatory content. This isn't a suggested outline. It's a legal requirement. Miss a section and your white paper is non-compliant.

Here are the required sections:

Information about the issuer. Legal name, registered address, date of registration, LEI (Legal Entity Identifier), the natural persons responsible for the white paper, parent company if applicable, and financial position of the issuer. If you're a startup with no revenue, you still need to disclose that.

Information about the crypto-asset. What it is, how it works, what rights (if any) are attached to it, what technology it runs on, what consensus mechanism it uses, how transactions are processed, and whether it's interoperable with other systems.

Information about the offer or admission to trading. How many tokens are being offered, at what price, the timeline, how funds will be used, and the conditions of the offer. If it's a free distribution (airdrop), that needs to be explained too.

Rights and obligations. This is where many projects struggle. You must clearly state what rights the holder has. If the answer is "none", you must say that explicitly. No vague language. No implications.

Risks. Market risks, technology risks, legal risks, counterparty risks, liquidity risks, and any crypto-asset specific risks. This section must be honest and comprehensive. Downplaying risks is not just bad practice under MiCA; it creates liability.

Environmental impact. Every white paper must disclose the principal adverse impacts of the consensus mechanism on climate and environment. At minimum, the total annual energy consumption of the consensus mechanism in kWh. Proof-of-work tokens will have more to disclose here than proof-of-stake ones.

A summary. A short, plain-language summary at the beginning that warns the reader: this summary is an introduction, not the whole picture. Your decision to purchase should be based on the full document.

A compliance statement. A mandatory statement under Article 6(6) clarifying that the white paper is not approved by any competent authority, the issuer is solely responsible for its content, and the crypto-asset is not a financial instrument under MiFID II.

A date and table of contents. Yes, MiCA specifies this. The white paper must show when it was notified and include a table of contents.

What you cannot say

MiCA explicitly prohibits certain content like claims about future value, material omissions or misleading information.

In practice, this kills the typical crypto marketing language. "Revolutionary," "guaranteed yields," "next Bitcoin" are all problematic if they appear anywhere in the white paper or in marketing communications related to it.

The new format: XBRL

Since December 2025, white papers must be submitted in Inline XBRL (iXBRL) format, not just as PDFs. This is a machine-readable format that allows regulators to automatically extract, validate, and compare data across white papers.

What this means practically: you need specialized software or a service provider to convert your white paper into the correct format. The content must be tagged according to a specific taxonomy. Each data field must map to the right category. A technically invalid submission can be rejected even if the content is substantively correct.

You also need a valid LEI (Legal Entity Identifier) linked to your submission. If your entity doesn't have one, get it before you start the white paper process.

Liability (the part that matters most)

Article 15 of MiCA introduces civil liability for the information in white papers. If the white paper contains misleading information, material omissions, or is not compliant with the regulation, holders who suffered a loss can bring claims against the issuer.

This is not theoretical. It means every statement in your white paper can be used against you in court.

The persons identified as responsible for the white paper bear personal liability. This is typically the management of the issuing entity. Think carefully about who signs off.

The obligation to update

A white paper is not a one-time document. Under Article 12, you must modify your published white paper whenever there is a significant new factor, a material mistake, or a material inaccuracy that could affect the assessment of the crypto-asset.

The modified white paper must be notified to the competent authority and published in the same way as the original. You must also clearly identify what changed and when.

In practice, this means you need an internal process for monitoring whether your white paper is still accurate. If your project roadmap changes, if a key team member leaves, if the technology shifts, if a legal risk materializes, your white paper may need updating.

The bottom line

A MiCA white paper is a regulatory document with legal consequences. It requires specific content, a specific format, ongoing maintenance, and carries personal liability for its authors.

If you're issuing a crypto-asset in the EU, the white paper is likely your first formal interaction with the regulatory framework. Getting it right sets the tone for everything that follows. Getting it wrong creates problems that compound over time.

The old days of publishing a PDF on your website and calling it a white paper are over. What replaced them is more demanding but also more professional. And that's the point.

This article is for informational purposes only and does not constitute legal advice. White paper requirements vary by token type and jurisdiction. Consult a qualified lawyer before preparing or notifying a MiCA white paper. If you found this useful, I'd appreciate a share. You can find me on LinkedIn and X.