Preparing a MiCA-compliant whitepaper (a disclosure document required under the Markets in Crypto-Assets Regulation for most crypto-asset offerings in the EU/EEA) is less a drafting exercise and more a classification exercise. The regime routes every token through a legal analysis first, then dictates what the whitepaper must contain, how it must be filed and what liability flows from it. Getting the sequence wrong – classification last, drafting first – is the most common and most expensive mistake we see. This guide walks through each step in order, identifies the cross-border complications that reshape the analysis and flags the specific mistakes that turn a compliant filing into a regulatory problem.
Step 1: Understand Why Token Classification Comes First
The MiCA whitepaper requirement is triggered by classification, and the classification determines which part of the regime applies. MiCA establishes three primary categories: asset-referenced tokens (ARTs, tokens that reference a basket of assets, currencies or commodities), e-money tokens (EMTs, tokens referencing a single fiat currency) and a residual category covering all other crypto-assets that do not qualify as financial instruments under existing EU securities law. Each category carries different whitepaper content obligations, different issuer authorisation thresholds and different supervisory expectations under ESMA and the relevant national competent authorities.
The classification analysis is not optional and it is not a label you apply yourself. Under MiCA the substance of the rights conferred by the token governs – not the name in the marketing deck, not the technical architecture and not the choice of jurisdiction for the issuing entity. A token that grants holders a proportional claim on a pool of assets will be treated as an ART regardless of whether it is labelled a "utility token." A token pegged to euros redeemable at par is an EMT regardless of whether it is marketed as a payment instrument.
The first step therefore is a structured legal opinion on the token's rights architecture. That opinion should address: whether the token is a transferable security or other financial instrument under the EU's existing securities regime (which would take it outside MiCA entirely and into the prospectus and MiFID II regime); whether it is an ART, EMT or other crypto-asset within MiCA; and whether it is expressly excluded (utility tokens with no investment function fall outside the whitepaper obligation under specific conditions).
The cross-border complication here is material. An issuer sitting in Singapore or the BVI may believe the MiCA analysis is irrelevant. It is not. MiCA applies to any offer of crypto-assets to the public in the EU/EEA, or any admission to trading on an EU/EEA platform, regardless of where the issuer is domiciled. Structuring the offering through a non-EU entity does not extinguish the obligation – it may create a gap between where the issuer is regulated and where the regulatory risk actually sits.
Common mistake at Step 1: Relying on a legal opinion that addresses only the domicile of the issuing entity and ignores the location of the offer or the token holder base. Classification is driven by the rights in the token and the geography of the offering – not the corporate seat.
Step 2: Determine Whether Issuer Authorisation is Required
For ARTs and EMTs, issuer authorisation from the relevant national competent authority is a prerequisite to publication of the whitepaper. The whitepaper cannot be filed – and the offer cannot proceed – until that authorisation is in place. For "other crypto-assets," the position is different: issuers typically notify the competent authority rather than seeking advance approval, and the whitepaper may be published after a defined notification period subject to the authority's right to object.
The practical consequence is that the authorisation timeline governs the project timeline for any ART or EMT. ART issuers must be authorised as credit institutions or seek dedicated MiCA authorisation. EMT issuers must be authorised either as credit institutions or as electronic money institutions under the applicable EU EMI regime. Neither authorisation is fast. Both require the applicant to demonstrate governance structures, capital adequacy (in a range that varies by licence category and own-funds rules that the relevant competent authority will specify), and reserve or redemption mechanisms that satisfy ESMA's expectations.
In our cross-border practice, we regularly advise issuers who have already chosen a corporate domicile – Malta, Lithuania or another EU member state – without first verifying whether that jurisdiction has the regulatory capacity and authorisation infrastructure to process an ART or EMT application on a commercially viable timeline. The choice of competent authority matters as much as the legal analysis.
Common mistake at Step 2: Selecting the issuing jurisdiction for tax efficiency before confirming that the chosen national competent authority has the capacity, the regulatory framework and the political will to process the relevant MiCA authorisation category promptly.
For a scoped assessment of your token classification and the issuer authorisation path it triggers, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the rights architecture, the holder base – change the analysis significantly. Map your options.
Step 3: Assemble the Mandatory Whitepaper Content
A MiCA whitepaper is a prescribed disclosure instrument, not a marketing document, and the prescribed content differs by token category. All whitepapers share a core content framework: a description of the issuer and any offeror; a description of the crypto-asset project and the technology; a description of the rights and obligations attached to the token; information on the underlying protocol; disclosure of the principal risks; and a summary section designed to be intelligible to a non-expert reader.
For ARTs, additional content is mandatory. The whitepaper must describe the stabilisation mechanism, the reserve asset composition and management, the redemption rights of token holders and the governance arrangements around the reserve. The obligation to maintain adequate reserves at all times, and to segregate those reserves, is a continuing compliance obligation that the whitepaper must accurately reflect – any mismatch between the whitepaper description and the actual reserve management creates both regulatory and civil liability exposure.
For EMTs the whitepaper must address the redeemability at par, the regime for holding reserve funds and the issuer's status as an authorised EMI or credit institution. The whitepaper is not a one-time document: it must be kept current, and material changes require either a revised whitepaper or a supplementary notice filed with the competent authority.
For "other crypto-assets," the content requirements are materially lighter, but the structure and the mandatory summary remain. The regime is explicit that the whitepaper is a liability-bearing document: the issuer, the offeror and any person seeking admission to trading are jointly and severally responsible for the accuracy of its contents. This changes how the document is drafted. Every representation in the whitepaper is potentially the basis for a civil claim by a token purchaser who suffers loss.
Common mistake at Step 3: Treating the whitepaper as a narrative pitch document and including forward-looking statements, yield projections or performance claims that cannot be verified. The liability standard under MiCA makes those inclusions an active legal risk, not merely a disclosure style choice.
Step 4: Address the Cross-Border Dimension of the Whitepaper
No token offering in 2025 exists in a single jurisdiction. A whitepaper compliant with MiCA may not satisfy the parallel regulatory expectations in Singapore under the Payment Services Act and MAS guidance, in Hong Kong under the SFC's VASP licensing regime, or in the United Arab Emirates under VARA's activity-based rulebooks. Each of those regimes has its own classification logic, its own disclosure expectations and its own enforcement posture.
The cross-border analysis at this step addresses two distinct problems. First, does the token offering trigger regulatory obligations in jurisdictions outside the EU – and if so, what additional disclosure, registration or exemption steps are required before or alongside the MiCA whitepaper? Second, does the issuer's group structure create regulatory exposure in jurisdictions where the issuer does not intend to operate actively?
We have seen the second problem most acutely in offerings structured through a BVI or Cayman holding entity where the token is offered globally via a public website accessible from multiple regulatory jurisdictions. The whitepaper may satisfy MiCA. It may say nothing meaningful about the offering's legal status in the United States under SEC and CFTC oversight, or about compliance with the applicable VASP provisions in the Gulf. That silence is itself a disclosure problem.
The practical solution is a jurisdiction map completed before the whitepaper is drafted. The map identifies: the jurisdictions from which the offering will be actively marketed; the jurisdictions where the issuer expects material token holder concentration; the jurisdictions where the token is likely to be listed; and the jurisdictions where the issuer's banking relationships sit. Each of those axes produces a separate regulatory question, and the whitepaper must not make representations that are inconsistent with the answer in any of them.
Common mistake at Step 4: Treating the MiCA whitepaper as a global compliance document when it is a specifically EU disclosure instrument, and failing to conduct parallel analysis for each jurisdiction where the offering will have legal effect.
Step 5: Draft the Risk Factors Section with Precision
The risk factors section of a MiCA whitepaper carries the highest legal weight of any section because it is the primary defence against a civil claim for misrepresentation. A token purchaser who suffers loss after the token fails to perform as described will look first at what the whitepaper said about risks. If the whitepaper described those risks in generic terms – "blockchain technology involves risk; regulatory environments may change" – the defence is weak. If the whitepaper described the specific risks with precision and context, the issuer's position is materially stronger.
Specific risks that a MiCA whitepaper should address include: the regulatory risk of reclassification by a competent authority in any jurisdiction where the token is offered; the liquidity risk associated with secondary market trading (including the risk that no regulated trading platform admits the token); the operational risk of the token's technical infrastructure; the reserve and redemption risk for ARTs and EMTs; the governance risk where the issuer's token protocol can be modified unilaterally; and the counterparty risk in any underlying yield or reward mechanism.
In our practice, we regularly advise that token issuers who structure a staking reward or yield mechanism into the token architecture face a compounded classification risk: the yield mechanism may constitute an investment return that recharacterises the token as a security or a financial instrument outside MiCA's "other crypto-asset" category. That risk must appear in the whitepaper – and its appearance in the whitepaper is not a cure for the underlying classification problem. The classification analysis under Step 1 must address it first.
Common mistake at Step 5: Writing risk factors at the level of the industry rather than the specific token and its specific rights architecture. Generic risk language is not a legal shield.
If a prior whitepaper filing stalled or a competent authority raised classification concerns, a second read of the structure can surface the reason and the route forward. Write to info@oboluslaw.com or message us via t.me/oboluslaw. Map your options.
Step 6: Handle the Filing and Notification Process Correctly
Filing a MiCA whitepaper is not the same as publishing it, and the procedural sequence differs by token category. For "other crypto-assets," the issuer must notify the whitepaper to the competent authority of the member state where the issuer is established before publishing it or making any offer to the public. The competent authority does not approve the whitepaper – it receives and registers it – but it retains the power to require modifications if the whitepaper does not meet the prescribed content requirements.
For ARTs and EMTs, the whitepaper is reviewed as part of the authorisation process. The competent authority examines both the issuer's authorisation application and the whitepaper together. A deficient whitepaper is a ground for refusing or conditioning the authorisation. The practical consequence is that the whitepaper draft and the authorisation application must be developed simultaneously, not sequentially.
The passporting benefit applies on the EU/EEA dimension: a CASP authorised in one member state may use its authorisation across the EU under the MiCA passporting mechanism, and a whitepaper notified or approved in one member state is valid across the EU without re-filing in each member state. However, passporting applies to the authorisation – not to the underlying business readiness. Operators who passport before their compliance infrastructure (AML/KYC, Travel Rule data flows, governance) is operational create a second wave of regulatory exposure shortly after launch.
The Travel Rule (the obligation to pass originator and beneficiary data with a virtual asset transfer) applies to CASPs from the point of authorisation. The whitepaper does not directly address Travel Rule compliance, but the issuer's description of the token transfer mechanics must be consistent with how the CASP intends to implement it. A whitepaper that describes an anonymous transfer feature is inconsistent with Travel Rule compliance and will attract regulatory attention at the notification or authorisation stage.
In a recent matter, a token issuer had prepared a technically detailed whitepaper for a mid-market infrastructure token, notified it to the national competent authority and received a request for substantial revisions to the rights description and the redemption mechanism. We assisted in restructuring the rights architecture and redrafting the relevant sections; the revised notification was accepted and the issuer proceeded to the public offering phase. The episode illustrated that the notification process is not a rubber stamp, and that a whitepaper drafted without legal input at the rights-architecture stage generates the most revision risk.
Common mistake at Step 6: Publishing the whitepaper publicly – including on a website accessible from the EU – before the notification period has elapsed or the authorisation has been granted. Publication before clearance is itself a breach of MiCA, separate from any deficiency in the document's content.
Step 7: Maintain the Whitepaper After Launch
A MiCA whitepaper is a living compliance document. The regulation requires that material changes to the information in the whitepaper – changes to the token's rights architecture, the reserve management arrangements, the issuer's governance, the fee structure or the redemption mechanism – be reflected in a revised whitepaper or a formal supplement, with re-notification or re-approval as applicable.
The ongoing maintenance obligation is the element most frequently underestimated in project planning. Development teams iterate on token mechanics, governance structures and reward models after the initial whitepaper is filed. Each iteration should be assessed against the whitepaper's current representations, and any material divergence must trigger a disclosure review. Failure to update the whitepaper after a material change creates both regulatory exposure (the competent authority may treat the issuer as operating outside the scope of its notification or authorisation) and civil liability exposure (token purchasers who relied on the original whitepaper may have a misrepresentation claim if the actual mechanics diverged from what was described).
The cross-border dimension reasserts itself at the maintenance stage. An issuer that has modified its token's reward structure to address a concern raised by the FCA in the UK context must also assess whether that modification affects the MiCA classification and the accuracy of the EU whitepaper. Modifications made to satisfy one regulator can inadvertently create a problem under another regime.
Common mistake at Step 7: Treating whitepaper maintenance as a documentation exercise managed by the communications team rather than a legal compliance obligation managed by counsel with authority to assess materiality and trigger re-notification.
Related at OBOLUS
- Token Offerings & Securities practice – classification, structuring and regulatory compliance for token issuers across jurisdictions.
- Stablecoin issuance authorisation in the Seychelles – jurisdiction-specific guidance for stablecoin issuers evaluating an offshore domicile.
- On-chain asset tracing for institutional clients – forensic and legal process for tracing and recovering misappropriated digital assets.
FAQ
Is my token a security?
Token classification turns on the rights the token confers, not the label applied to it. A token that grants holders an expectation of profit derived from the efforts of others is likely to satisfy the economic substance of a security in most major jurisdictions, including under US federal law and under EU securities frameworks that sit alongside MiCA. Classification requires a legal opinion on the specific rights architecture – no generic checklist substitutes for that analysis. We assess classification against substance, not marketing label.
Do I need a MiCA whitepaper?
MiCA requires a whitepaper for most public offers of crypto-assets and for admissions to trading on regulated platforms in the EU/EEA, regardless of where the issuer is domiciled. There are exemptions: offers to fewer than 150 persons per member state, offers with a total consideration below a threshold set by the regulation, offers to qualified investors only, and free distributions that meet the conditions for exclusion. Whether a specific offering qualifies for an exemption requires advice on the structure of the offer and the token's classification – the exemptions are narrower in practice than they appear on paper.
How should an airdrop be structured legally?
An airdrop can qualify for a MiCA exemption if it meets the conditions for a free distribution of crypto-assets – principally that no consideration is received for the tokens and that no personal data is collected as a form of payment. However, the rights conferred by the airdropped tokens still determine their classification. If the tokens qualify as ARTs, EMTs or financial instruments, the airdrop exemption does not override the authorisation requirement. The token's rights architecture, the technical collection mechanism and the targeting of the distribution all require legal review before the airdrop launches.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We assess token classification against the substance of rights – not the marketing label – and we structure licensing, banking and tax as one mandate rather than three disconnected workstreams. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialises in token architecture, smart-contract legal analysis and MiCA classification for issuers operating across multiple regulatory regimes.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.