The complete guide to MiCA crypto-asset whitepapers in 2026

If you are launching a utility, governance or platform token in the EU, one question decides most of your compliance workload: does your offer trigger a MiCA whitepaper, and if it does, what has to be in it? This guide answers both, with every legal claim tied to a specific Article of Regulation (EU) 2023/1114 (MiCA). It is educational software, not legal advice, and it does not create a client relationship. Under Article 15 MiCA the issuer, not any tool, is liable for the content of a whitepaper.

What MiCA is, and what an "other" crypto-asset is

MiCA is the EU's single rulebook for crypto-assets that are not already financial instruments. A crypto-asset is "a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology" (Art. 3(1)(5)). Every in-scope crypto-asset falls into exactly one of three buckets, and the bucket picks the regime:

Bucket	What it is	Regime	Basis
ART (asset-referenced token)	Keeps a stable value by referencing another value or right, or a basket	Title III: issuer authorisation, approved whitepaper, reserves	Art. 3(1)(6)
EMT (e-money token)	Keeps a stable value by referencing one official currency	Title IV: issuer must be a credit institution or EMI	Art. 3(1)(7)
"Other" crypto-asset	Neither an ART nor an EMT — utility, governance, platform and most fungible project tokens	Title II: whitepaper, draft-notify-publish, no pre-approval	Title II (Art. 4-15)

This guide is about the third bucket. It is the lightest regime and the one most token projects deal with.

Some things are outside MiCA entirely. Financial instruments and security tokens go to MiFID II and the prospectus regime, not to a MiCA whitepaper; the ESMA Guidelines on the qualification of crypto-assets as financial instruments (December 2024) draw that line (Art. 2(4)). Genuinely unique, non-fungible crypto-assets are excluded (Art. 2(3)) — but a large fungible series or a fractionalised NFT can fall back in scope. Fully decentralised arrangements with no identifiable issuer sit outside the current perimeter (Recital 22) and are under active 2026 review. Mis-classifying a security token as an "other" crypto-asset is the most dangerous mistake here: it can miss a prospectus obligation entirely.

Who has to file the whitepaper

For an "other" crypto-asset, the whitepaper duty attaches to one of three actors, in order (Art. 4):

• The offeror making the offer to the public (Art. 4(1)).
• The person seeking admission to trading where a listing is requested (Art. 4(1)).
• The operator of the trading platform, where a token is admitted to trading and neither of the above drew up a whitepaper — unless a written agreement shifts that duty (Art. 4 with Art. 5).

Whoever drafts, the content rules of Article 6 and Annex I are the same.

Do you even need one? The Article 4 exemptions

An offer to the public, or seeking admission to trading, triggers the whitepaper obligation (Art. 4(1)) unless an Article 4 exemption applies. There are two sets.

Article 4(2) — offer size and audience. Any one limb is enough:

• Fewer than 150 persons per Member State, acting on their own account (Art. 4(2)(a)). The count is per Member State and looks at whom the offer is addressed to, not who accepts.
• Total EU consideration not exceeding €1,000,000 over a rolling 12-month period from the start of the offer (Art. 4(2)(b)). Aggregate across the window and the whole EU: a "small" launch that stacks past €1,000,000 mid-window loses the exemption.
• Addressed solely to qualified investors, where the token can only be held by them (Art. 4(2)(c)). "Qualified investors" takes the MiFID II Annex II Section I(1)-(4) definition, and the holding restriction must be real.

Article 4(3) — nature of the asset. Where any applies, the whole of Title II does not apply:

• Offered for free (Art. 4(3)(a)) — but it is not "free" if purchasers must provide personal data, or if the offeror takes fees, commissions or other benefits from prospective holders. Data-for-token airdrops fail this test.
• Mining or validation rewards (Art. 4(3)(b)) — issuance rewards, not a secondary sale.
• A utility token for a good or service already in operation (Art. 4(3)(c)) — a token for a merely planned product does not qualify.
• Usable only within a limited network of contracted merchants (Art. 4(3)(d)) — with a notification duty to the competent authority above €1,000,000 over 12 months.

And the kill-switch: under Article 4(4), signalling an intention to seek admission to trading — in any communication, by anyone acting for the offeror — disapplies every Article 4(2) and 4(3) exemption. Being exempt from the whitepaper is not being unregulated: the Article 7 marketing rules survive every exemption, and several 4(2) limbs still require notification.

Our MiCA exemptions page walks each limb and its trap, and the free MiCA whitepaper check turns them into a two-minute decision.

What goes in the whitepaper: Article 6 and Annex I

If a whitepaper is required, Article 6 fixes the content, structured across the Annex I Parts A to I:

• Part A — the offeror (identity, LEI, management body, a fair review of the financial condition over three years).
• Part B — the issuer, if different (a lighter identity block).
• Part C — the operator, where it drafts (identity plus why it drew up the whitepaper).
• Part D — the project (name, ticker, milestones, use of funds).
• Part E — the offer or admission (price, amount, phases, the Article 13 right of withdrawal, safeguarding under Article 10, applicable law).
• Part F — the crypto-asset (type, characteristics, functionality, and the data needed to classify it in the ESMA register).
• Part G — the rights and obligations attached (transferability, supply-adjustment protocols, protection schemes).
• Part H — the underlying technology (DLT, the consensus mechanism, audit outcome).
• Part I — the risks.

Plus the environmental disclosure under Article 6(1)(j): the principal adverse climate and environmental impacts of the consensus mechanism. Total annual electricity consumption is always mandatory; a supplementary set of indicators is triggered above 500,000 kWh per year under Delegated Regulation (EU) 2025/422.

Article 6 also prescribes five mandatory statements in a set order: a first-page no-approval / sole-responsibility statement (Art. 6(3)); a bar on future-value assertions (Art. 6(4)); a six-limb risk statement that the token may lose value, may not be transferable or liquid, and is covered by neither investor-compensation nor deposit-guarantee schemes (Art. 6(5)); a management-body responsibility statement (Art. 6(6)); and a four-limb summary warning (Art. 6(7)). Their wording is fixed by the regulation. The whitepaper requirements page breaks each Part down.

Notify, don't seek approval

MiCA built a light-touch regime for "other" crypto-assets. You notify the home Member State's competent authority at least 20 working days before publication (Art. 8), then publish on your website before the offer or admission starts and keep it accessible while the tokens are held by the public (Art. 9). The authority does not approve the whitepaper.

But "not approved" is not "not regulated". The authority can require amendments, suspend or prohibit an offer, and — the point that matters most — the issuer is strictly liable. Article 15 makes the offeror, admission-seeker or operator civilly liable for information that is not complete, fair or clear, or that is misleading, and that liability cannot be excluded by contract.

A whitepaper is now an Inline XBRL filing

Since 23 December 2025, a MiCA whitepaper is not a PDF. ITS (EU) 2024/2984 requires it to be a single Inline XBRL (iXBRL) XHTML document: a normal narrative to a human, carrying machine-readable XBRL tags on each reportable data point, tagged against the ESMA MiCA taxonomy (version 1.0 published 5 August 2025). The "other" crypto-asset uses the OTHR template. Competent authorities and ESMA ingest the structured data automatically, and PDF-only submissions no longer meet the requirement.

The taxonomy defines existence and value assertions the instance must satisfy before it can be filed, and a valid Legal Entity Identifier (LEI) for the offeror or issuer is a mandatory tagged field — no LEI, no valid instance. The iXBRL filing page covers the format, the common validation-failure classes and the LEI requirement.

Where this leaves you

Work it in order: classify the token, check the Article 4 exemptions, and if a whitepaper is required, assemble the Article 6 / Annex I content, add the mandatory statements, notify 20 working days ahead, and file the whitepaper as validated iXBRL.

Witness builds two MiCA surfaces for this. The free MiCA whitepaper check tells you whether you need a whitepaper. Tokenpaper is the paid engine that turns a qualifying offer into a filing-ready whitepaper: guided Annex I intake and validated Inline XBRL against the ESMA taxonomy, with every field citing its article. It is software, not legal advice, and under Article 15 MiCA the issuer stays liable for the content. For the full reference, start with the MiCA whitepaper guide.