Token Classification and DeFi Under MiCAR: A Legal Checklist for Solana and Ethereum Projects

If you're a Web3 founder planning to launch a token or a DeFi protocol in the EU - including Romania - two questions can stall your go-to-market plan faster than any audit. First: what is your token, legally, under MiCAR? Second: how decentralized is your DeFi product, really, in the sense the regulation actually cares about?

This matters right now. MiCAR is already in force: rules for asset-referenced and e-money tokens took effect on June 30, 2024, and the rest of the regulation - including the licensing regime for crypto-asset service providers - on December 30, 2024. ESMA also maintains a public Interim MiCA Register of token whitepapers and licensed providers. In practice, many exchanges and institutional partners now treat a documented token classification, paired with coherent supporting paperwork, as a baseline requirement before they'll even talk to you.

This article walks through a practical framework - with checklists, red flags, and an interactive decentralization reality check - covering classification (including the MiFID II trap), DeFi decentralization, whitepaper and marketing rules, listing due diligence, AML/Travel Rule readiness, and the specific legal questions raised by Solana's mint/freeze authorities and Ethereum's upgrade keys.

Token classification and DeFi under MiCAR: five key points

1. Classification starts with one question and ends with a second, critical test
   Does the token claim stability? And: could this actually be a MiFID II financial instrument instead - outside MiCAR entirely?
2. "Fully decentralized" is a narrow exception
   Admin keys, contract upgradeability, and control over the front-end can all create legal responsibility and pull a project back into MiCAR's scope.
3. Whitepaper and marketing must be designed together
   Inconsistencies between the two are a major red flag in listing due diligence.
4. Solana and Ethereum aren't purely technical choices
   Solana's mint and freeze authorities, and Ethereum's proxy-admin upgrade keys, translate directly into legal and compliance risk.
5. The Travel Rule and AML aren't optional extras
   Exchange and payment-rail partners will require documented processes, not just written promises.

Quick glossary (one-minute read)

Expand each term for the plain-language definition used throughout:

The two questions that decide your regime

MiCAR creates one harmonized regime for crypto-assets - but it only applies to crypto-assets that aren't already regulated as something else: financial instruments under MiFID II, bank deposits, insurance products, and similar categories. Your first job as a founder is to work out, and be able to document, which box your token belongs in - or why it belongs in none of them.

The classification map: three MiCAR boxes - and the MiFID II exit

The "wrong regime" red flags we see in practice

Explicit or implied yield promises - a "guaranteed" APY, a programmatic buyback, or revenue sharing; corporate-style rights, such as voting on profit distributions; and pooling structures where a manager or team actively manages funds to generate a return for token holders. Each one increases the risk that you've actually built a MiFID II financial instrument - with the very different legal architecture that requires.

The standardized classification test: what regulators actually ask for

Since 2024–2025, EU regulators have pushed hard for consistency. The three European Supervisory Authorities - covering banking, securities, and insurance - jointly published guidelines (December 2024) that include a standardized test and reporting templates for communicating a token's classification to regulators, under Article 97 of MiCAR.

What this means in practice

"It's a utility token" is not documentation

You need documentation - in your whitepaper and in a supporting legal explanation - that shows, affirmatively: why the token is not an e-money token or an asset-referenced token; why it doesn't fall under any express exclusion (for example, a genuinely unique, non-fungible NFT); and, crucially, why it is not a financial instrument.

The practical output is a token-rights matrix and a substance-over-form tokenomics analysis, answering one question: are you inside MiCAR (and if so, under which title), or do you actually need a MiFID II / prospectus conversation?

Quick test: which box does it land in?

Four token designs from real launch conversations. Pick the classification you think is right:

Token 1: Grants access to premium features of the protocol and voting rights on product roadmap decisions. No stability claim, no yield, no profit share.

MiCAR - "other crypto-asset" (utility). Access plus governance over product decisions, without stablecoin behavior or securities-like economics, is the classic Title II pattern. The classification still needs to be documented affirmatively - including why it's not a financial instrument - before a public offer or listing.

Token 2: Marketed with a projected APY, funded by a programmatic buyback from protocol revenue; holders vote on how profits are distributed.

MiFID II risk - the "wrong regime" trap. Yield promises, revenue-linked buybacks, and voting on profit distributions are exactly the securities-like rights ESMA's qualification guidelines target. If it qualifies as a financial instrument, it exits MiCAR entirely - into a much stricter regime with prospectus implications. This is a redesign conversation, not a labeling one.

Token 3: Designed to always be worth exactly 1 EUR, redeemable at par, backed by reserves.

EMT. Stability referenced to a single official currency is the e-money token definition - and the EBA has been explicit that ART and EMT issuers in the EU must be authorized before they can operate. This is the high-bar path: authorization, governance, reserve-asset rules, and contingency plans, classified before development begins.

Token 4: Aims for a stable value by referencing a basket: 50% USD, 30% gold, 20% BTC.

ART. Stability referenced to a basket of assets - currencies, commodities, other crypto-assets, or a mix - is the asset-referenced token definition, with its own dedicated regime: formal authorization, reserve rules, detailed policies, and contingency plans. Calling it a "utility token" in the whitepaper changes nothing: substance over form.

These are screening calls, not legal conclusions

Real classification turns on the full token-rights matrix, the marketing, and the redemption mechanics - the same design can land differently depending on details. Get a classification memo for your token.

DeFi and MiCAR: when is a protocol really decentralized?

MiCAR's Recital 22 acknowledges that services provided in a fully decentralized way, with no intermediary at all, can fall outside the licensing regime for crypto-asset service providers. In practice, though, regulators treat that exception narrowly - and the analysis is highly fact-specific.

"Who controls the admin keys, who operates the user interface, who collects the fees, and who decides on protocol upgrades - regulators may end up identifying an 'intermediary' functionally, based on who actually operates the infrastructure, regardless of how the project is marketed."

- The functional test at the heart of every DeFi scoping analysis; MiCAR does not clearly define "fully decentralized", as legal commentators including Bird & Bird have flagged

If the analysis reveals identifiable, concentrated control over technical parameters, economics, access, custody, or marketing, there's a real chance that a person or entity behind the project meets the legal definition of a crypto-asset service provider - or, depending on the model, an "offeror" or "issuer" under MiCAR. Run the reality check below before you assume your project sits outside the regulation.

Interactive: the DeFi decentralization reality check

Tick each statement that is true for your project as it actually operates - not as the docs describe it. The more boxes you can honestly tick, the more defensible a "fully decentralized" position becomes:

Ten control questions regulators and exchanges will ask

• Smart contracts are not upgradeable - or upgrades require a timelock plus a genuinely functioning DAO voting quorum
• No small, identifiable group controls admin, guardian, or emergency keys
• Key economic parameters (fees, listed assets, risk parameters, oracle sources) are not set by a concentrated team
• The treasury is not controlled by a small, identifiable group
• The official front-end, domain, and hosting are not operated by a single controlling entity
• Neither the interface nor the smart contracts include a team-controlled blocklist or allowlist
• The protocol never takes custody of, or otherwise administers, users' assets
• Marketing, utility promises, and the roadmap are not published by a single responsible team
• There is a documented multisig, timelock, and emergency procedure for whatever keys do exist
• There is a plan for what happens if the founding team disappears - handover to a DAO, or formal relinquishment of authorities

Every unticked box is a point of concentrated control

And concentrated control is exactly what turns "decentralized" marketing into an identifiable intermediary - a CASP, offeror, or issuer under MiCAR. The answer isn't necessarily to relinquish everything (compliance needs can justify keeping controls); it's to know your position and govern it deliberately. Get your protocol's control map reviewed.

Solana vs. Ethereum: what a regulator or exchange is actually asking

In listing due diligence, the real question isn't "which blockchain are you built on?" It's: who can change the rules of the game? That means technical control, economic control, and the ability to block users or alter token supply.

A closer look: Solana's mint and freeze authorities

If mint authority exists and is controlled by a small team or narrow DAO, it allows minting or burning tokens - directly affecting supply and user expectations. Freeze authority allows accounts to be frozen; Solana's own documentation notes that once it's revoked, accounts can no longer be frozen going forward. Keeping these authorities active gives you a visible technical "steering wheel" - exchanges will expect you to justify why you kept it and show it's properly governed.

A closer look: Ethereum's upgradeability and role-based permissions

On Ethereum and most EVM chains (including many Layer 2 networks), the equivalent risk sits in proxy patterns: who controls the proxy admin, the timelock, "guardian" keys, or roles that can pause the contract or blacklist addresses. If keys exist that can upgrade or halt a contract, or change its economic parameters, there is a point of legal responsibility - even though the code executes entirely on-chain.

The bottom line

It isn't the blockchain that determines your legal regime - it's the real level of control you retain. The legal work is translating that technical control into roles (issuer, offeror, operator, CASP), responsibilities, required disclosures, and - where relevant - AML documentation.

Whitepaper, the Interim MiCA Register, and marketing rules

For crypto-assets other than ARTs and EMTs, a MiCAR whitepaper becomes relevant whenever there's a public offer in the EU, or the token is admitted to trading. ESMA maintains a central record - the Interim MiCA Register - covering whitepapers, licensed CASPs, and non-compliant entities.

A point founders often miss

Register listing ≠ regulatory approval

ESMA is explicit that listed whitepapers are not approved by any regulator - responsibility for the content stays with the issuer or offeror. The register is a market transparency tool, not a stamp of approval. That's precisely why exchanges and institutional partners run their own due diligence on your classification analysis rather than relying on the listing itself.

Marketing under MiCAR isn't just PR copy: it must be fair, clear, not misleading - and consistent with the whitepaper. In practice: clear risk disclaimers (volatility, "high risk", no guarantees); a clean separation between educational content and calls to action; and no price predictions, "guaranteed yield" language, or investment-style phrasing - all of which pull you toward MiFID II territory.

What to expect from a CASP's due diligence before listing

Licensed platforms manage their own reputational and regulatory risk. Based on market practice, expect some version of the following requests:

1. Legal structure and beneficial ownership
   Who stands behind the project - corporate chain, UBOs, and jurisdictions.
2. Token supply details
   Vesting schedules, lock-ups, and who controls minting or contract upgrades.
3. A legal memo addressing your classification analysis
   MiCAR versus MiFID II - or a documented justification for why a whitepaper isn't required.
4. AML and sanctions screening results
   Documented processes, not written promises.
5. Incident-response procedures and named contact points
   Evidence that you control key risks: market abuse, adequate disclosures, and controls over token supply.

AML, KYC, and the Travel Rule: real impact even on "DeFi-ish" products

The Travel Rule applies across the EU

Regulation (EU) 2023/1113 extends Travel Rule obligations to crypto-asset transfers across the EU - and FATF, the global standard-setter, treats it as a baseline: collecting and transmitting sender/recipient data, customer due diligence, and suspicious transaction reports where warranted.

Where it hits startups concretely

Your on-ramp and off-ramp relationships (licensed exchanges, payment service providers); wallet screening, sanctions checks, and transaction monitoring; and how you handle self-hosted (non-custodial) wallets, based on risk level and the operational requirements your exchange partners impose.

One more layer: the AML Regulation

The EU's Anti-Money Laundering Regulation (Regulation (EU) 2024/1624) strengthens AML/CTF rules across the bloc, applies directly, and increases the compliance burden on "obliged entities" - which includes crypto-asset service providers.

How Buju, Stanciu & Asociații structures token and DeFi projects

BSA, based in Bucharest, works at the intersection of IT/commercial law and crypto-asset regulation, with a focus on practical implementation rather than pure legal theory. Our typical approach breaks into five workstreams:

1. Token classification package (MiCAR/MiFID II)

Analysis of the rights the token confers plus a full tokenomics review; a classification memo (ART, EMT, utility, or other - plus a MiFID II risk assessment); role mapping: issuer/offeror, CASP, protocol operator, or DAO.

2. MiCAR documentation stack

The MiCAR whitepaper itself - structure, disclosures, risk factors, and a technology section; terms and conditions, risk disclosures, privacy/cookie policies; internal policies, especially for teams functioning as an "operator" or working closely with a licensed platform.

3. Go-to-market and marketing compliance

Review of your website, pitch deck, campaigns, social media, and KOL contracts; communication rules and disclaimers designed to avoid financial-promotion pitfalls and inconsistencies with your whitepaper.

4. Listing and exchange readiness

Data room preparation (cap table, token distribution, technical controls); contracts covering market making, listing agreements, custody, and SaaS/software licensing; support negotiating with exchanges and AML/KYC vendors.

5. AML/KYC and Travel Rule readiness

Especially for on-ramp/off-ramp products: AML/KYC policies sized to your actual business model; screening and monitoring workflows, sanctions checks, suspicious transaction reporting; contractual integration with vendors - SaaS providers, analytics tools, compliance software.

How BSA compares to larger firms - a realistic view

A note on this comparison

This reflects how BSA positions its own services relative to publicly known practice areas of these firms - not an independent or exhaustive evaluation of their work. All of them are serious options; the right choice depends on your project's size, complexity, and delivery needs.

Key takeaways

1. Classification starts with "does it claim stability?" - and ends with the MiFID II test
   Could this actually be a financial instrument instead? That question decides your entire legal architecture.
2. "Fully decentralized" is a narrow exception
   Admin keys, upgradeability, and front-end control can all create legal responsibility and pull the project back into MiCAR.
3. Whitepaper and marketing are designed together
   Inconsistencies between them are a major red flag in listing due diligence.
4. Solana and Ethereum aren't purely technical choices
   Mint/freeze authorities and proxy-admin upgrade keys translate directly into legal and compliance risk.
5. Travel Rule and AML compliance aren't optional extras
   Exchange and payment-rail partners will require documented processes, not just written promises.

Frequently asked questions

Preparing a token launch or DeFi product for the EU market?

The highest-leverage first step is a two-to-four-week pre-launch legal sprint: classification (including the MiFID II test), legal structure and role allocation, documentation (whitepaper plus terms and conditions), and a listing/partnership plan - with concrete deliverables, not theoretical memos.

Contact us

Sources and references

Regulation (EU) 2023/1114 (MiCAR): EUR-Lex · Regulation (EU) 2023/1113 (Transfer of Funds Regulation / Travel Rule): EUR-Lex · Regulation (EU) 2024/1624 (Anti-Money Laundering Regulation): EUR-Lex · ESMA - Interim MiCA Register; Guidelines on the qualification of crypto-assets as financial instruments: esma.europa.eu · Joint Guidelines of the European Supervisory Authorities on the regulatory classification of crypto-assets (December 2024): eiopa.europa.eu · EBA - guidance on asset-referenced and e-money tokens under MiCA: eba.europa.eu · FATF - guidance on virtual assets and the Travel Rule: fatf-gafi.org · Solana Developer Docs - "Freeze Account", "Set Authority": solana.com/docs · Bird & Bird - "EU-U.S. Regulatory Divergence in Crypto-Assets" (2025): twobirds.com · A&O Shearman - "MiCAR Under the Microscope, Part 4: The CASP Licensing Regime": aoshearman.com · Buju, Stanciu & Asociații (BSA): Blockchain & Cryptocurrencies Legal Assistance

Disclaimer: This article is for general informational purposes only and does not constitute legal advice. For recommendations tailored to your specific situation, please seek a dedicated legal analysis of your project. Information about the firms mentioned in the comparison reflects publicly known practice areas and BSA's own positioning.