What You Must Disclose to Launch in the EU
By 2026, MiCA is no longer a “coming soon” regulation. It is the operating reality for token issuers in the EU. If you plan to offer a token to the public or get it admitted to trading in Europe, you need a MiCA-compliant crypto-asset whitepaper.
Call it what it is: this is not a pitch deck and not a landing page. Under MiCA, the whitepaper functions as a formal disclosure that regulators and market participants can rely on. If it is misleading, incomplete, or inconsistent with how the token actually works, the issuer owns that problem.
MiCA Whitepaper: Definition and Purpose
A MiCA whitepaper is a standardized document that explains, in plain and verifiable terms:
- who the issuer is and how it is governed,
- what the token is designed to do,
- how issuance and token economics operate,
- what the key risks are (technical, market, operational, legal),
- which rights token holders have and how complaints are handled.
A whitepaper is required for utility tokens, asset-referenced tokens (ARTs) and e-money tokens (EMTs) offered in the EU or admitted to trading in the EU.
Why MiCA insists on this:
- to make token offerings comparable across Member States,
- to reduce hidden risks and “selective transparency,”
- to attach real accountability to issuers,
- to protect retail participants through structured disclosure.
What MiCA Requires: The Core Whitepaper Content
MiCA’s disclosure logic is consistent: describe the token and the issuer in a way that is specific, internally consistent, and not misleading.
1) Issuer Identity, Structure, and Oversight
Your whitepaper should clearly state:
- issuer’s legal name, legal form, and registered office,
- registration and corporate identifiers,
- the EU Member State relevant for supervision/notification,
- governance model (board/management responsibilities),
- internal controls and compliance setup.
The point is traceability: regulators need to know who is accountable and how decisions are controlled.
2) Token Design and Tokenomics (No Hand-Waving)
You must explain:
- what the token is for (utility) and what it is not,
- what rights, if any, are attached to holding it,
- issuance method, total supply logic, emission schedule,
- allocation and distribution approach,
- rules for minting/burning/staking/redemption where relevant,
- where and how the token is technically issued (chains/protocols).
If a user cannot understand how supply and distribution work, the disclosure is not doing its job.
3) Risk Disclosure That Matches the Real Model
MiCA expects risk factors that reflect the actual product, not generic “crypto is risky” filler. Typical categories include:
- price/market risks and volatility exposure,
- smart contract and cybersecurity vulnerabilities,
- operational risks (process failures, key personnel, outsourcing),
- liquidity risks and realistic loss scenarios,
- legal/regulatory uncertainty affecting the token or business model.
If your risk section could be copy-pasted into any random project, it is probably too weak.
4) Use of Proceeds and Roadmap (When Funds Are Raised)
Where the offering involves fundraising, disclose:
- the purpose of the raise,
- allocation of proceeds (in meaningful buckets),
- delivery plan and milestones,
- governance over treasury management and spending controls.
This is where regulators and sophisticated users look for “are you building a product or just selling a story.”
5) Technology Stack and Security Posture
Your whitepaper should include:
- a practical description of the token’s technical architecture,
- security controls and incident response approach,
- audit posture (audits completed, planned, or none),
- critical dependencies and third parties (custody, APIs, infrastructure).
You do not need to expose sensitive security details. You do need to be transparent about the security reality.
6) Token Holder Rights, Complaints, and What Happens If Things End
Define:
- rights and obligations of holders/purchasers,
- complaint handling steps and timelines,
- dispute resolution route,
- redemption/refund conditions if applicable,
- procedures for termination, discontinuation, or major changes.
These are not “nice to have” sections. They are part of the issuer’s legal commitments.
Publishing a MiCA Whitepaper: How Compliance Usually Works
In practice, compliance is a process, not a PDF export:
- Draft the whitepaper in line with MiCA Annex II and applicable ESMA standards.
- Run a legal/compliance consistency check (tokenomics vs tech vs marketing).
- Notify the competent authority (for example, ČNB in the Czech Republic, depending on structure and obligations).
- Publish on the issuer’s website before any public offer or admission to trading.
- Keep it updated when material changes happen (model, risks, governance, dependencies).
Important distinction:
- ARTs and EMTs generally involve prior authorisation/approval before offering and publication.
- Utility tokens typically follow a notification + publication route, without prior approval, but still with full content obligations.
Who Is On the Hook Under MiCA?
MiCA whitepaper obligations hit:
- token issuers offering utility/ART/EMT in the EU,
- projects seeking admission to trading in the EU,
- token sales used for fundraising,
- and, indirectly, CASPs listing tokens (because listings will demand issuer compliance).
In 2026, trying to operate without a compliant whitepaper is not clever. It is just avoidable risk.
Common MiCA Whitepaper Failures (That Regulators Notice)
Projects usually trip over the same things:
- risk sections that are vague or obviously templated,
- missing technical explanation of key mechanics (especially smart contracts),
- claims that sound like marketing but function as promises,
- contradictions between the whitepaper, website copy, and real token behavior,
- outdated versions left online after material changes.
MiCA expects ongoing accuracy. A “publish and forget” approach is an invitation to trouble.
Practical Support for Preparing a MiCA-Compliant Whitepaper
AMS Europe supports crypto projects and token issuers in preparing a whitepaper that fully complies with MiCA requirements, taking into account the specifics of the token model, the selected jurisdiction, and the intended method of token distribution. We support the process from the initial analysis of applicable requirements through to the final compliance review of the document.
Our team ensures legal accuracy of the disclosures, alignment of the whitepaper with regulatory expectations, and its practical applicability — including proper risk disclosure, clear description of the technology, and consistency with the underlying business model. This approach allows issuers to reduce regulatory risk and enter the EU market with confidence. compliance across the EU.
Contact us to assess your compliance readiness and move forward with confidence.
FAQ: MiCA Whitepaper Requirements for Token Issuers
What does MiCA require in a token whitepaper?
A structured disclosure covering issuer identity and governance, token purpose and mechanics, technology overview, risk factors, use of proceeds where relevant, security/audit posture, token holder rights, and complaint/dispute handling. It must be clear, accurate, and not misleading.
Who must publish a MiCA whitepaper?
Issuers offering utility tokens, ARTs, or EMTs to the public in the EU, or seeking admission to trading in the EU. Listings will typically require issuer-side compliance to be demonstrable.
Do utility token whitepapers need prior regulatory approval?
Usually no. Utility token whitepapers are generally published after notification, but still must meet MiCA content and disclosure standards.
Do ARTs and EMTs require regulatory approval?
Yes, ARTs and EMTs generally require authorisation/approval by the competent authority before offering to the public and before the whitepaper route is completed.
What are the most common weak points in practice?
Generic risk sections, unclear tokenomics (supply/distribution), missing security posture, contradictions between documents, and failure to update after material changes.
