Working through MiCA compliance reveals that the same strategic errors appear in project after project. Most are preventable — if you know what to look for. Here are the seven biggest mistakes Web3 startups make when approaching MiCA.
1. Treating a "utility token" as automatically MiCA-exempt
The most common misunderstanding: founders describe their token as a "utility token" and believe this label places it outside MiCA. It doesn't.
Under Article 3(1)(9) MiCA, a utility token is defined as a crypto-asset that is only intended to provide access to a good or a service supplied by its issuer. Utility tokens are within MiCA scope — they fall under Title II, which requires a whitepaper and notification to the relevant NCA. The label is a regulatory category, not an exemption.
The confusion often stems from US securities law concepts. Under the Howey Test, "utility" can be a defence against security classification. Under EU law, it is not. MiCA treats utility tokens as their own regulated category, distinct from ARTs, EMTs, and financial instruments.
How to avoid it
- Treat your token as within MiCA scope unless an exclusion clearly applies (Article 2(3) NFT exemption, Article 2(4) financial instrument exclusion, or genuine non-EU targeting)
- If you believe you have a utility token, prepare the Title II whitepaper and notify the NCA — this is the correct pathway, not an avoidance strategy
- Check whether
Article 4(3)(c)applies — offers to the public of utility tokens providing access to goods or services that already exist may be exempt from some Title II whitepaper obligations, but not from MiCA generally
2. Assuming decentralisation removes MiCA scope
"We're fully decentralised, no issuer exists" — another extremely common framing, and one that regulators are increasingly sceptical about.
Recital 22 of MiCA does state that "where crypto-asset services are provided in a fully decentralised manner without any intermediary, they should not fall within the scope of this Regulation." But ESMA and national competent authorities have been clear that this exemption is narrow.
The key questions regulators ask:
- Is there an identifiable person who benefits economically from the protocol?
- Is there an identifiable person who controls admin keys, upgrade paths, or frontend interfaces?
- Who set the initial parameters, and who can change them?
- Does a DAO have an identifiable multisig or treasury controller?
In practice, most "decentralised" projects still have identifiable persons — core developers, foundation treasury signers, frontend operators — who trigger MiCA scope. Genuine protocol-only automation without any human decision-maker is rare.
How to avoid it
- Document your decentralisation claim rigorously — what is automated, who controls what, who benefits
- Consider the frontend question separately from the protocol itself — a decentralised smart contract system accessed via a centralised frontend you control typically triggers CASP obligations for that frontend
- If your project is moving toward "sufficient decentralisation" over time, plan the regulatory transition carefully
Find out where your project sits in MiCA
Compliora AI runs your actual project — structure, tokens, services — through MiCA and flags every regulatory trigger. In 5 minutes you know exactly what applies and what doesn't.
Start Assessment →3. Ignoring the MiCA/MiFID II boundary
Many teams assume their token is "crypto" and therefore MiCA applies. They never ask whether the token might actually be a financial instrument under MiFID II, which would put it outside MiCA entirely (per Article 2(4)(a) MiCA) and into the full securities law regime.
Any token with economic rights — revenue share, dividends, redemption against the issuer's assets, profit entitlement, or governance rights with meaningful financial consequences — is a candidate for financial instrument classification under Article 4(1)(15) MiFID II.
If you misclassify, you may:
- Prepare a MiCA whitepaper when you need a Prospectus Regulation prospectus
- Apply for CASP authorisation when you need MiFID II investment firm authorisation
- Build a service offering based on the wrong legal framework, requiring expensive restructuring later
The ESMA Guidelines of 17 March 2025 (ESMA75-453128700-1323) provide the current criteria for distinguishing crypto-assets from financial instruments. See our dedicated analysis: MiCA vs MiFID II: Which Applies to Your Token.
How to avoid it
- Before assuming MiCA, run the MiFID II transferable security test first
- Pay special attention to governance tokens with fee switches, revenue-sharing arrangements, or LP tokens with yield flows
- When in doubt, engage specialist counsel on the classification before investing in regulatory infrastructure
4. Relying on offshore incorporation to avoid MiCA
A Cayman Islands foundation, a BVI holdco, a Seychelles trading entity — these are common structures in Web3. But none of them automatically exclude MiCA.
MiCA applies based on where services are offered and provided, not where the entity is incorporated. An offshore entity that targets EU users, accepts EU payments, markets to EU residents, or allows EU clients on its platform triggers MiCA scope just like an EU-incorporated entity would.
The tell-tale signs that regulators use to identify "targeting":
- Website localisation to EU languages and currencies
- Marketing campaigns and ads reaching EU geographies
- Partnerships with EU companies, influencers, or service providers
- Active community engagement in EU-focused channels
- Event sponsorships at EU conferences
- Acceptance of EU-issued payment instruments without restriction
To genuinely be "non-EU" for MiCA purposes, you need enforced IP geoblocking, KYC-based EU resident exclusion, and no EU-focused marketing. A disclaimer on signup asking users to confirm they're not EU residents is not sufficient.
How to avoid it
- Either structure to be genuinely non-EU (with real enforcement) or plan to comply with MiCA
- Half-measures create the worst outcome: no EU market access and no genuine non-EU exemption
- Reverse solicitation exemptions exist under MiCA but are narrow — don't rely on them as a business model
5. Starting marketing before MiCA compliance is ready
Many teams assume MiCA obligations only trigger at the moment of token sale or trading listing. They then start presale marketing, community building, airdrop campaigns, and advisor announcements — all before the MiCA whitepaper is prepared and notified.
The problem: MiCA marketing communications rules under Article 7 apply to communications about the offering, not just the offering itself. Marketing communications must be:
- Fair, clear, and not misleading
- Consistent with the whitepaper
- Identifiable as marketing communications
If the whitepaper hasn't been prepared yet, how can marketing be consistent with it? This creates a sequencing problem that many projects miss. Similarly, public offerings of utility tokens or crypto-assets that involve "communications to prospective purchasers" can trigger Title II obligations earlier than founders expect.
How to avoid it
- Prepare the MiCA whitepaper first, notify the NCA, and only then start active marketing
- Design pre-notification communications carefully — general educational content about your project is usually fine; specific offer terms and token marketing are risky
- Document your timeline — whitepaper date, notification date, first public marketing date, offering start date — to demonstrate the proper sequence
6. Misusing the NFT exemption
"It's an NFT, so MiCA doesn't apply" is another common error. Article 2(3) MiCA excludes crypto-assets that are "unique and not fungible with other crypto-assets" — but the scope of this exemption is narrower than most founders think.
Recital 11 MiCA makes clear that:
- Fractional parts of unique NFTs are not themselves unique
- Issuance of crypto-assets as NFTs in large series or collections is an indicator of fungibility
- Mere attribution of a unique identifier does not make a crypto-asset unique and non-fungible
In practice, this means a typical 10,000-PFP collection — where all NFTs mint at the same price, grant similar utility, and trade interchangeably in secondary markets — likely falls within MiCA scope despite the "NFT" label.
The ESMA Guidelines of 17 March 2025 include an interdependent value test: if the value of an NFT primarily derives from its unique characteristics and individual utility (like a one-of-one digital artwork), it's more likely to be genuinely unique. If the value derives from membership in a series or collection (like a PFP project), it's more likely to be fungible in substance.
How to avoid it
- Don't rely on the NFT label — assess your collection's actual fungibility characteristics
- For large PFP or similar series projects, assume MiCA applies and prepare for Title II compliance
- If your NFT grants financial rights (revenue share, staking yield, redemption), it's almost certainly a financial instrument regardless of the NFT branding
7. Waiting too long to apply for CASP authorisation
Among CASPs operating under Article 143(3) grandfathering, the single biggest strategic error is underestimating the time needed to prepare and complete a MiCA authorisation application.
The statutory timeline under Article 63 MiCA is 25 working days for completeness review plus 40 working days for substantive assessment — around three months formally. In practice, most authorisations are taking 6-12 months due to information requests, NCA capacity constraints, and iterative refinement of documentation.
If your grandfathering ends on 1 July 2026 and you haven't submitted by early 2026, you risk a regulatory gap — the period between grandfathering ending and authorisation being granted during which you cannot legally operate.
Add in 3-6 months of preparation work before submission, and the realistic timeline to plan for is 9-15 months from decision to active authorisation.
The queue is real. National competent authorities across the EU are receiving unprecedented CASP application volumes. France's AMF, Germany's BaFin, Ireland's CBI, and others have all publicly acknowledged capacity constraints. Applications submitted in the final 3-6 months of grandfathering periods face extended processing simply because authority capacity is overloaded.
How to avoid it
- Start preparation immediately if you haven't already
- Aim to submit at least 6 months before your national grandfathering deadline
- Engage with your NCA proactively — most offer pre-application meetings that improve submission quality
- Have a contingency plan for what happens if authorisation isn't granted before grandfathering ends
Summary: the pattern behind the mistakes
Looking across all seven mistakes, a common thread emerges: hoping that a label, a structure, or an assumption will do regulatory work that it can't do. MiCA is substance-driven, not form-driven. NCAs and ESMA consistently apply a "substance over form" approach.
The projects that navigate MiCA successfully share some common features:
- They treat classification as a fact-based exercise, not a labelling exercise
- They engage with regulators early rather than trying to avoid them
- They allocate realistic time and budget to compliance work
- They document their analysis carefully, so if a regulator later challenges their classification, they have defensible reasoning
Getting these right doesn't guarantee success, but getting any one of them badly wrong is often fatal — either through enforcement action, loss of banking relationships, inability to get EU clients, or being delisted from exchanges that require MiCA-compliant partners.
Avoid all 7 mistakes — get an expert assessment
Compliora AI runs your project through each of these pitfalls in minutes. Get a clear report showing which of the seven apply to you, what to fix, and what to prioritise.
Start Assessment →