For a crypto founder entering the European market, the practical question is rarely just “What is MiCA?” The harder questions are whether a token falls within the framework, whether a white paper or authorisation is required, and which EU jurisdiction should lead the process.
The Markets in Crypto-Assets Regulation created a harmonised framework for crypto-assets and related services not already covered by EU financial-services legislation. It is now fully applicable, and the EU-wide transitional period for existing crypto-asset service providers ended on 1 July 2026.
This guide explains who MiCA affects, how it classifies crypto-assets, which activities may require authorisation and what should be decided before launching a token, seeking an exchange listing or serving EU clients.
What MiCA means in practice
MiCA is Regulation (EU) 2023/1114. Unlike a directive, it applies directly across EU Member States, although national competent authorities remain responsible for much of the authorisation and supervision process.
The framework regulates two broad areas:
1. The issuance, public offering and admission to trading of crypto-assets. 2. The professional provision of crypto-asset services in the EU.
It establishes disclosure, authorisation, operational, client-protection and market-abuse rules. These cover transparency, governance, supervision, protection of token holders and CASP clients, insider dealing and market manipulation.
A properly authorised crypto-asset service provider can use the cross-border notification process to provide authorised services in other Member States without obtaining a separate licence in each country.
That benefit follows only after the home-state authority accepts the relevant entity, activities, governance arrangements and supporting documentation. Authorisation in one Member State does not automatically cover services that were not included in the application.
The full legal text is available in the Markets in Crypto-Assets Regulation on EUR-Lex.
Which crypto-assets does MiCA cover?
MiCA defines a crypto-asset as a digital representation of value or a right that can be transferred and stored electronically using distributed ledger technology or similar technology.
It then separates covered assets into three main categories.
Asset-referenced tokens
An asset-referenced token, or ART, seeks to maintain a stable value by referencing another value, right or combination of values, including one or more official currencies.
ART issuers generally face an authorisation and white-paper approval regime, together with governance, reserve, disclosure and redemption obligations.
The legal and operational requirements can become more demanding where an ART is classified as significant based on factors such as its user base, transaction volume or interconnectedness with the financial system.
E-money tokens
An e-money token, or EMT, seeks to maintain a stable value by referencing one official currency.
The issuer must generally be authorised as a credit institution or electronic money institution. It must also notify and publish a compliant crypto-asset white paper.
An EMT is not simply treated as another token with a stable price. Its connection to an official currency places it within a more specific regulatory framework that includes redemption and issuer-status requirements.
Other crypto-assets
The third category covers crypto-assets that are neither ARTs nor EMTs.
Utility tokens can fall within this category where they are intended only to provide access to a good or service supplied by the issuer. Public offers and admissions to trading commonly trigger white-paper, notification, publication and marketing requirements, subject to specific exemptions.
A token’s name does not decide its legal status. Labels such as “utility,” “governance,” “community” or “NFT” do not replace an analysis of its rights, economic function, transferability, marketing and actual use.
What falls outside MiCA?
MiCA does not cover every blockchain-based asset or activity.
Crypto-assets that qualify as financial instruments are excluded because other EU financial-services rules apply. Deposits, most funds, securitisation positions and certain insurance or pension products are also outside its scope.
The boundary between a crypto-asset and a financial instrument is therefore a critical classification question. A token that falls outside MiCA may still be heavily regulated under another framework.
Genuinely unique and non-fungible crypto-assets are also excluded. However, issuing tokens in a large series or collection can indicate fungibility. A unique identifier alone does not make an asset legally non-fungible. Authorities are expected to consider the economic substance of the asset rather than its technical label.
Services provided in a fully decentralised manner without an intermediary may also fall outside the framework. That exclusion is narrow.
Activities that are performed, provided or controlled directly or indirectly by identifiable persons can still be in scope, even where part of the technology or governance process is described as decentralised.
How MiCA works for issuers and service providers
The applicable obligations depend first on what the project actually does.
An issuer or offeror may need to:
- classify the token; - structure the issuing entity; - prepare a crypto-asset white paper; - align marketing communications with the white paper; - notify the competent authority; - publish the required documentation; - maintain and update relevant disclosures after launch.
The white paper must be fair, clear and not misleading. It must contain prescribed disclosures and risk warnings and should not include unsupported claims about future value.
A crypto-asset service provider, commonly called a CASP, may require authorisation when it professionally provides services such as:
- custody and administration of crypto-assets; - operating a crypto-asset trading platform; - exchanging crypto-assets for funds; - exchanging crypto-assets for other crypto-assets; - executing orders on behalf of clients; - placing crypto-assets; - receiving and transmitting orders; - providing advice on crypto-assets; - providing crypto-asset portfolio management; - transferring crypto-assets on behalf of clients.
CASP authorisation is not simply a registration form.
An application can require a programme of operations, governance arrangements, fit-and-proper management, prudential safeguards, internal controls, complaints procedures, outsourcing documentation, custody arrangements, ICT security policies and detailed descriptions of the services to be provided.
The formal assessment period normally begins only after an application is considered complete. Missing, inconsistent or generic documentation can therefore extend the real authorisation timeline considerably.
Do you need MiCA authorisation or a white paper?
There is no reliable answer based only on the words “crypto company,” “blockchain platform” or “utility token.” The analysis should follow the business model.
First, classify the asset.
Determine whether it is an ART, EMT, another crypto-asset, a financial instrument, a genuinely non-fungible asset or something governed primarily by another legal regime.
Second, map the activities.
A project that only develops software presents a different regulatory question from a company that controls custody, executes client orders, operates a platform, arranges token placement or provides investment-style advice.
Third, analyse the offer and target market.
A token offered to EU investors or admitted to trading in the EU may trigger disclosure obligations even where the issuer is established outside the Union. Specific exemptions exist, but their conditions must be tested carefully.
An intention to seek admission to trading can also remove the benefit of certain public-offer exemptions.
Fourth, identify the correct home Member State and competent authority.
Jurisdiction affects the application process, supervisory interaction, local implementation and any connected national rules.
Finally, assess the wider compliance framework.
MiCA does not replace AML/CFT requirements, the Transfer of Funds Regulation, operational-resilience rules, data protection, consumer law, payments regulation or sanctions obligations. The correct outcome depends on how these layers apply to the same product, legal entity and service model.
Legal expert insight
Peter Merc’s practical approach starts with the token holder’s actual rights, not with the label used by the project.
The first questions are what the token enables its holder to do, what the issuer promises, whether there is any expectation of redemption or financial return, and who controls the issuance, distribution and ongoing operation of the token. These facts usually indicate whether the project primarily requires a MiCA white paper, a formal legal opinion supporting the token classification, regulatory authorisation, or a combination of all three.
Classification must come first. A white paper cannot correct an incorrectly classified token, and a legal opinion cannot replace authorisation where the issuer or another entity is actually providing regulated crypto-asset services. The documents and regulatory route should follow the economic substance of the project, not the terminology chosen in its marketing materials.
General guidance can identify the relevant decision tree. A formal [crypto legal opinion](https://lemur.legal/crypto-legal-opinion) is appropriate where the classification will be relied on by a regulator, exchange, investor, banking partner or another third party.
What changed after 1 July 2026?
The EU-wide transitional period available under MiCA has ended.
Existing providers that previously relied on national registration or transitional regimes could continue operating only until the applicable national deadline, and no later than 1 July 2026, or until their MiCA authorisation was granted or refused.
After that date, an entity providing covered crypto-asset services to EU clients without the required authorisation can be in breach of EU law.
Unauthorised providers may be expected to stop onboarding clients and marketing covered services, restrict their activity to an orderly wind-down and protect clients during migration or exit.
A plan to “apply later” is therefore no longer a credible transitional strategy.
Businesses should verify that the specific legal entity serving EU clients is authorised. A group brand, pending application, national registration or authorisation held by an affiliated company does not necessarily permit another entity within the group to provide regulated services.
Authorisation status can be checked through the relevant national authority and the applicable EU registers.
Common MiCA misconceptions
“A utility token is automatically exempt”
It is not.
Utility token is a defined category, but the offer structure, availability of the underlying product, token functionality, admission to trading and other facts can still trigger obligations.
A project should not design its legal analysis backwards from the label it wants to use.
“A white paper means the regulator approved the project”
For many crypto-assets, the white paper is notified rather than approved in advance.
The issuer or offeror remains responsible for its accuracy and completeness. ARTs follow a different approval and authorisation structure.
In every case, publication of a white paper does not constitute a regulatory endorsement of the project, its commercial viability or the future value of the token.
“One MiCA licence covers every legal obligation”
CASP authorisation covers specified crypto-asset services.
It does not remove obligations arising under AML/CFT rules, sanctions, data protection, operational resilience, consumer protection, payments law, tax law or national company law.
It also does not authorise services that were omitted from the application.
“A template white paper is enough”
A white paper must match the project’s actual tokenomics, holder rights, technology, risks, offer terms and marketing.
Generic or inconsistent documentation can create regulatory, listing and investor due-diligence problems. The same applies where a white paper, website and legal opinion describe materially different token models.
MiCA white papers are also subject to technical formatting and data requirements. These should be considered during drafting rather than added as an afterthought immediately before filing.
“Calling a project decentralised keeps it outside MiCA”
Decentralisation is not determined by branding alone.
A regulator may examine who develops the protocol, controls upgrades, operates the interface, receives fees, manages treasury assets, makes key governance decisions or provides the service to users.
A project can use decentralised technology while still having identifiable persons performing regulated functions.
Who is most affected by MiCA?
MiCA is especially relevant for:
- token issuers planning an EU public offering; - projects seeking admission to trading on EU platforms; - stablecoin issuers; - crypto exchanges; - custodial wallet providers; - crypto brokers and order-execution businesses; - crypto advisory and portfolio-management providers; - companies transferring crypto-assets for clients; - non-EU projects actively targeting EU users; - existing VASPs transitioning to the CASP regime; - investors, exchanges and banking partners reviewing token compliance.
Technology providers can also be affected where their role extends beyond neutral software development and enters the provision or control of a regulated crypto-asset service.
Projects should not wait for an exchange, investor or regulator to identify the issue. Classification and activity mapping should occur while the commercial and technical structure can still be adjusted.
Preparing for a compliant launch or authorisation
The strongest process starts before the token sale, exchange application or CASP submission.
Founders should prepare:
- a clear map of the legal entities involved; - the jurisdictions and markets being targeted; - a description of each entity’s responsibilities; - tokenomics and a precise description of holder rights; - the project’s technical architecture; - custody, transaction and control flows; - offer, distribution and admission-to-trading plans; - draft marketing claims and communication channels; - governance and decision-making structures; - outsourcing and third-party arrangements; - security and complaints-handling procedures; - AML/CFT and sanctions controls; - client-onboarding processes; - a realistic classification, drafting and filing timeline.
These documents should tell one consistent story.
A white paper, website, legal opinion, token terms and authorisation application that describe different models will be difficult to defend. Inconsistencies can also become visible during exchange onboarding, investor due diligence or banking reviews.
Lemur Legal supports founders through token classification, MiCA white paper drafting, crypto legal opinions and regulatory compliance.
The process is most effective when the legal structure is tested while the business model can still be adjusted, rather than after an exchange, investor, regulator or banking partner has already identified a problem.
Build the legal path before entering the market
MiCA provides a common EU framework, but it does not turn crypto compliance into a single checklist.
The correct route depends on the token’s legal nature, the services performed, the entity serving EU clients, the selected jurisdiction and the other regulatory regimes that apply alongside MiCA.
The practical sequence is classification, activity mapping, jurisdiction and authorisation strategy, followed by documentation and implementation.
That order reduces the risk of drafting the wrong white paper, relying on an unsupported exemption or applying for the wrong regulatory permissions.
For founders under commercial pressure, early legal work is not simply a delay before entering the market. It is what makes an EU launch, listing or authorisation process defensible when the documentation is reviewed by a competent authority, exchange, investor or banking partner.