Folio v0.9 — CEX + On-chain Consolidation is liveSee what's new →

MiCA Crypto-Asset Whitepaper: Requirements and Obligations in 2026

Regulation·

MiCA Crypto-Asset Whitepaper: Requirements and Obligations in 2026

Under MiCA Title II, offering a crypto-asset other than an ART or EMT to the EU public, or seeking admission to trading, requires a notified and published crypto-asset whitepaper. What it must contain, who is exempt, and the 'comply or be de-listed' reality.
Author avatar Wag3s TeamEditorial team specializing in Web3 finance, crypto tax, and DAO operations. Based in Zurich, Switzerland.

Reviewed by Wag3s Editorial Team — verified against Regulation (EU) 2023/1114 (MiCA) Title II and ESMA guidance · Last reviewed May 2026

MiCA Crypto-Asset Whitepaper

The MiCA whitepaper is the disclosure document for the "other crypto-assets" category — everything that is not an asset-referenced token or e-money token. It is often misunderstood as optional marketing collateral. Under MiCA Title II it is a market-access gate: no compliant whitepaper, no public offer or admission to trading in the EU. This article covers when it is required, what it must contain, the narrow exemptions, and why the consequence of non-compliance is de-listing.

TL;DR

  • MiCA Title II governs crypto-assets other than ARTs and EMTs.
  • A public offer or admission to trading of such a crypto-asset requires a notified and published whitepaper (Article 6).
  • Content: clear, fair, not misleading, plain language — issuer/project, asset characteristics and holder rights, technology, risks, governance, third parties.
  • Notification-based, not prior-approval (unlike ARTs/EMTs, which have authorization regimes).
  • Utility tokens: in the regime; a narrow exemption exists for access to an already-available good/service — read narrowly.
  • Consequence of non-compliance: comply or be de-listed from EU venues.

Which category, and why it decides the regime

MiCA splits crypto-assets into three regulatory buckets, and the whitepaper question depends entirely on which one applies:

CategoryRegimeDisclosure
E-money token (EMT)Title IVAuthorization + EMT whitepaper
Asset-referenced token (ART)Title IIIAuthorization + ART whitepaper
Other crypto-asset (incl. utility tokens)Title IINotified + published crypto-asset whitepaper

ARTs and EMTs (single-currency vs other-reference stablecoins — see MiCA ART vs EMT) have stricter authorization regimes. Everything else — utility tokens, governance tokens, most fungible project tokens — sits in Title II, where the whitepaper is the central instrument.

Getting the classification wrong means applying the wrong disclosure regime, which is itself a compliance failure.

What the whitepaper must contain

MiCA (Article 6) requires the whitepaper to be clear, fair, and not misleading, in plain language, and sufficient for a prospective holder to make an informed decision. The substantive blocks:

  • Issuer / offeror and project: who is behind it, the project's purpose and roadmap
  • Crypto-asset characteristics: what it is, the rights and obligations attached to holders
  • Underlying technology and security: the DLT, protocols, security standards
  • Risks: a substantive risk section, not boilerplate
  • Governance: how decisions are made, who controls what
  • Third-party service providers: material dependencies

"Clear, fair and not misleading in plain language" is an enforceable standard, not a stylistic suggestion. A whitepaper that buries risk, overstates the project, or uses opaque language is non-compliant even if every required heading is present.

Notification, not prior approval

For Title II crypto-assets, the model is notification-based: the whitepaper is notified to the competent authority and published, not pre-approved the way a securities prospectus is. ARTs and EMTs are different — they carry authorization regimes.

A common misreading: "notification, not approval" means the content is low-stakes. It does not. The notification model shifts the gate from pre-clearance to liability and supervision — a deficient or misleading whitepaper exposes the issuer/offeror to supervisory action and liability, and the CASP listing it to market-access consequences.

The utility-token exemption, read narrowly

A utility token — a crypto-asset intended solely to provide access to a good or service supplied by its issuer — is an "other crypto-asset" and generally within the Title II regime. There is a narrow exemption where the token provides access to a good or service that is already available or in use, rather than a future promise. The conditions are read narrowly: a token for a product that does not yet exist does not qualify; the access must be to something currently in use.

The practical rule: do not treat "we call it a utility token" as an exemption. Establish that the specific conditional exemption applies, document the basis, and confirm with counsel. Mislabelling a financial-style token as an exempt utility token is a recurring enforcement target (see MiCA DeFi grey zones).

"Comply or be de-listed"

The consequence that concentrates the mind: a MiCA-authorized CASP cannot admit to trading or continue offering a Title II crypto-asset to the EU public without the required compliant whitepaper. The real-world outcome of non-compliance is removal from EU trading venues, not merely a regulator's letter. For an issuer, the whitepaper is the gate to EU market access; for a CASP, listing a non-compliant asset is its own exposure.

This reframes the whitepaper from "documentation" to "the thing that determines whether the asset can trade in the EU at all."

What a project should actually do

  1. Classify the crypto-asset (EMT / ART / other) — this selects the regime.
  2. If 'other', build the Title II whitepaper to the Article 6 substantive standard, not a template skeleton.
  3. Test the utility-token exemption only against the narrow conditions; document the basis.
  4. Notify and publish per the competent authority's process.
  5. Keep it current — material changes require the whitepaper to be kept accurate; a stale whitepaper is a compliance and market-access risk.

Where vendors fit

The whitepaper itself is a legal/disclosure work product, not a tooling output. Adjacent compliance tooling:

  • Sumsub — KYC/AML for the offer and the onboarding around it.
  • Cryptio — the financial-records backbone an issuer needs once the asset is live and trading.
  • TaxBit — downstream tax reporting once holders transact (DAC8 — see DAC8 compliance guide).

No tool drafts a compliant whitepaper; counsel does. Tooling supports the lifecycle around it.

How Wag3s helps

Wag3s Ledger is the post-issuance financial backbone: once a Title II crypto-asset is live, the issuer needs audit-ready records of treasury, allocations, and on-chain flows. Wag3s Ledger provides multi-chain reconciliation and audit trails (see multi-chain reconciliation) that support the financial-records expectations around a MiCA offer. See the Ledger product page.


Further reading

Sources

Editorial disclaimer
This article is informational and does not constitute legal advice. Whitepaper obligations depend on the crypto-asset's classification and the offer structure. Confirm requirements with qualified EU counsel before any public offer or admission to trading.