23 December 2025

MiCAR White Papers: Your Roadmap to a Smooth Drafting Process

  • Articles
  • Legal
  • Blockchain / Digital Assets
  • Regulatory Compliance

A hands-on guide to streamlining white paper drafting around your project’s reality, helping you avoid last-minute pressure, delays, and legal pitfalls.

  • Romedi Ganzoni

    Legal Partner

  • Anne-Grace Kleczewski

    Legal Associate

An inescapable exercise

Drafting a crypto-asset white paper has become an administrative hurdle that projects - irrespective of their jurisdiction - can no longer ignore. Although a requirement rooted in a European regulation, the now-famous Markets in Crypto-Assets Regulation (MiCAR), its impact extends well beyond the European Union (EU). More and more non-EU projects are feeling its effects, whether during public token offerings or when seeking admission to trading.

Major centralized exchanges such as Coinbase and Kraken have already obtained licenses under MiCAR and are actively targeting the EU market. Unsurprisingly, they now expect projects listed on their platforms to produce MiCAR-compliant white papers. Many teams therefore discover, sooner or later, that avoiding this obligation is not a viable long-term strategy.

A critical timeline constraint

As with any daunting compliance task (tax filings being a relatable example), white-paper drafting often begins far too late. It is usually triggered when an exchange requests it during pre-listing due diligence, or when a legal counsel notes that a marketing campaign is a bit too EU-facing for comfort. By then, the pressure to produce a compliant document can be substantial.

The tension only grows once teams learn about the 20-business-day waiting period between notifying national authorities of a finalised white paper and its effective publication. Until expiry of this period, the project must not engage in any marketing communications, and any planned offering or listing is effectively on hold.

More than a casual publication

Against this backdrop, careful planning is essential. This is all the more true given that MiCAR expressly establishes direct civil liability for the authors of a crypto-asset white paper where the information provided is misleading, inaccurate, or inconsistent with the actual characteristics of the crypto-asset and results in loss to a holder. To make matters stricter still, any contractual exclusion or limitation of such civil liability is expressly deprived of legal effect.

This article distils the most relevant practical takeaways from the MiCAR white paper drafting process, offering projects a hands-on guide to preparing efficiently and with a clear view of potential blockers arising from their specific circumstances. The aim is to ensure that MiCAR compliance does not come with unwelcome surprises.

Key Considerations Before Drafting

Despite the fact that MiCAR introduces additional, sometimes daunting, obligations beyond the white paper itself, there is a notable upside: the white-paper process sheds light on the widespread ambiguity that continues to surround project structuring and disclosures in the web3 space, regardless of the project’s stage and other timing considerations.

1. Offering vs. Admission to Trading

Uncertainty is somewhat more tolerable when it comes to admissions to trading. In that context, the white paper sets the scene for a potential listing, often at a moment when no finalized listing agreement exists. The entity is, by definition, seeking admission to trading, not confirming that admission will occur. Hence less information needs to be provided.

For public offerings, however, the bar is markedly higher. Core elements of the offer must be known, fixed, and disclosed with accuracy. There is far less room for approximation, and MiCAR requires essentials to be settled, not promised on a “to-be-determined” basis. As further explained under the following section.

2. Clarity on the Type of Offering

Do you know the precise nature and structure of the offering? Key elements include:

  • how and where the offering will be conducted, notably whether a launchpad or other intermediary is involved,

  • the start and end dates, and

  • any mechanics that may impact allocation or distribution of purchased tokens.

Minor aspects can sometimes be outlined in broad terms and clarified later through official publications, but this flexibility has its limits. The white paper must still provide comprehensive and reliable information. Leaning too heavily on “future details” increases the risk of disputes, particularly when the final structure diverges from what the market was led to expect.

We all know how this industry operates: launchpad discussions may trigger last-minute adjustments, and shifting market conditions can force changes to timelines or mechanics. Unfortunately, MiCAR does not accommodate this level of fluidity.

In practice, you have two options:

  • prepare a draft, leave blank anything still in flux, and publish at the very last minute; or

  • publish earlier and accept that if material elements change, you will need to update the white paper, triggering a new notification and a mandatory seven-business-day waiting period before publication of the updated version.

3. Do You Fully Understand your Token?

The web3 ecosystem evolves quickly. Beyond sales and listings, the token itself (its tokenomics, utilities, and technical features) often shifts in response to market conditions, investor pressure, partnerships, or broader ecosystem developments. Even once issued, tokens migrate, get rebranded or upgraded, and continue to evolve throughout the lifecycle of the project.

Against this background, MiCAR imposes firm boundaries. Promotional buzzwords or aspirational utilities may create real regulatory exposure if they are not fully aligned with what is disclosed in the white paper.

At a minimum, MiCAR expects the following:

  • The token’s functionalities must be defined.
    Promising future features that remain uncertain increases the likelihood of having to update (and justify such update) to the white paper. If something is still an idea without a defined launch date, avoid overpromising, even if it sounds compelling in marketing materials.

  • The timing of availability of such functionalities must be disclosed.
    Broad timelines are acceptable, but if you anticipate the schedule might drift significantly, as it does, it is wiser not to commit to such functionality at all.

  • Marketing communications may not contradict or go beyond the white paper.
    Early blog posts announcing flashy utilities that later disappear from the roadmap are risky. If it is marketed, it must be real, and it must be in the white paper. If not, delete.

One recurring token functionality is particularly tricky to address in a white paper: governance. The drafting exercise often exposes how governance has been added through bootstrapping, without a clear definition of what can actually be voted on or how that vote is supposed to operate. Yet this is not a mere organisational detail. It is crucial for determining whether the token qualifies as a non-financial-instrument “crypto-asset” under MiCA in the first place, or whether its features could instead push it into the category of a financial instrument under MiFID II.

4. Corporate Structure and Financial Information Must Be Settled

Surprisingly, many projects struggle with basic questions around corporate structure and financials.

Early-stage teams often bootstrap operations, lack continuous legal or accounting support, and scramble to finalise financial statements only when statutory deadlines loom. On the other end of the spectrum, mature projects sometimes develop elaborate webs of intertwined entities that create their own confusion.

The result is that even foundational questions, such as identifying the correct issuing entity or determining which entity is actually seeking admission to trading, become unexpectedly complex during white-paper preparation. And it doesn’t stop there: tracing and explaining the source of funding for each relevant entity can feel less like standard compliance and more like sitting a university exam the team did not study for.

The Source of Most Uncertainty

Before opening the MiCAR template and starting to fill in sections, it is worth taking a step back and asking a simple but essential question: at what stage does this white paper come into play?

Much of the complexity encountered during white-paper drafting stems from the project’s stage of development:

  • Is the project early-stage, moving quickly under VC pressure, while much is still undefined?

  • Is it a mature protocol finally preparing for a long-anticipated token generation event?

  • Is the white paper being drafted to prepare ahead, or once the offering mechanics and timelines have already been agreed?

These factors determine how much flexibility a project retains, and how much information is readily available and final, before attempting to comply with MiCAR’s disclosure requirements.

Conclusion

MiCAR’s white-paper requirements have reshaped token launches and exchange listings both within and far beyond the EU. And while compliance may feel burdensome, the discipline it introduces often exposes governance, structural, and communication gaps that would otherwise stay hidden. For teams with vague roadmaps or overly enthusiastic marketing habits, MiCAR quickly becomes a demanding road to cross, and a reminder that vagueness can expose to liability.

Therefore, early preparation is essential. Once you accept that a white paper will be required sooner or later, taking a proactive approach becomes invaluable: it reduces regulatory risk, builds investor confidence, and brings much-needed clarity to the project’s operational backbone.

Our MiCA Desk delivers comprehensive assistance with MiCAR-compliant white papers and all related compliance questions, supporting you across the full notification, timing, and update lifecycle, where the white paper is often only the tip of the iceberg.

 

Click here to learn more about our expertise:
Back