MiCA Is Fully Enforced. Here's What It Means for Token-Based Compute Networks.

By Wingston Sharon | January 2025

Regulation (EU) 2023/1114 — the Markets in Crypto-Assets Regulation, universally called MiCA — became fully enforceable on December 30, 2024. The provisions covering asset-referenced tokens and e-money tokens came into force earlier (June 30, 2024). The December 30 date brought the full crypto-asset service provider (CASP) regime online.

There's been a lot written about MiCA's impact on exchanges, custodians, and stablecoin issuers. Less has been written about what it means for a different kind of crypto-adjacent project: distributed compute networks that use tokens as a coordination or payment mechanism. That's what I want to work through here.

I'll say upfront: this post is not legal advice. If you're running a token-based compute network, you need legal advice specific to your design, structure, and jurisdictions. What I can offer is a reasonably careful reading of the regulation and an honest assessment of where the lines are drawn.

What MiCA Actually Covers

MiCA regulates three categories of crypto-assets and the services around them:

Asset-referenced tokens (ARTs) — tokens that stabilize their value by referencing multiple assets (fiat currencies, commodities, other crypto-assets). Think multi-currency stablecoins.

E-money tokens (EMTs) — tokens that reference a single fiat currency. Think USDC or EURC-style stablecoins.

Other crypto-assets — everything that doesn't fall into the above two categories, including utility tokens. This is the residual category, and it's the one most relevant for compute network tokens.

The CASP regime covers the services: custody, operation of trading platforms, exchange, execution of orders, placing, reception and transmission of orders, providing advice, and portfolio management — when those services are provided in respect of any of the above categories.

What MiCA Explicitly Does Not Cover

This is important, and the regulation is fairly explicit about exclusions.

Article 2(4) excludes crypto-assets that are unique and not fungible with other crypto-assets. NFTs used as collectibles are generally outside MiCA (with a carve-out for NFTs issued in large series that might be de facto fungible).

Recital 22 notes that MiCA is not intended to apply to crypto-assets that are the "digital representation of a service or physical asset" when they can only be used to obtain that specific service or asset from the issuer. The classic example is a software license key or a services voucher.

DeFi: MiCA doesn't currently apply to "fully decentralized" crypto-asset services with no intermediary. Recital 22 acknowledges this is complex and the Commission is required to report on DeFi by December 30, 2025 — so expect future regulation in this space. But for now, genuinely intermediary-free DeFi is outside scope.

Utility tokens that don't look like investments: The key question for compute network tokens.

The Compute Token Question

Distributed compute networks — whether GPU sharing networks, decentralized AI inference, or similar architectures — commonly use tokens in one of several ways:

1. Access tokens: You hold or spend tokens to access compute resources
2. Reward tokens: You earn tokens for contributing resources
3. Governance tokens: You hold tokens to participate in protocol governance
4. Hybrid: A combination of the above

The MiCA analysis depends heavily on which of these you're running and how the token is structured.

Pure access/utility tokens — where the token can only be redeemed for compute credits from the issuing network, is not traded on secondary markets, and has no dividend or profit-sharing rights — have the strongest argument for being outside MiCA's CASP regime. They look like vouchers or software licenses, not financial instruments.

Reward tokens that are freely transferable and traded — where contributors earn tokens that can be sold on exchanges for fiat or other crypto-assets — look much more like financial instruments. The economic reality is that these tokens have investment characteristics: you're taking compute infrastructure to earn something that has market value. That's closer to an investment than a voucher.

Governance tokens are genuinely contested. ESMA (the European Securities and Markets Authority) has been developing guidance on token classification, and governance tokens that don't have financial rights attached sit in an awkward position. The argument they're not financial instruments is plausible if they genuinely only convey protocol votes. The counterargument is that governance control has economic value.

ESMA's Token Classification Guidance

ESMA published its first technical advice on token classification under Article 2(3) of MiCA in February 2024. It's worth reading if you're in this space.

The key framework ESMA uses: would a reasonable person consider the token a financial instrument? The test is economic substance over legal form. A token labeled "utility token" in its documentation but structured to capture value from the network's growth is going to be scrutinized on the economic substance.

ESMA's guidance emphasizes looking at:
- Transferability and tradability on secondary markets
- Whether returns are linked to the economic performance of the issuer or network
- Whether token holders have any expectation of profit from the efforts of others (the Howey-adjacent question)
- Whether the token can only be used within the specific ecosystem of the issuer

For compute tokens specifically: a token that can only buy compute from your network and can't be traded sits at the utility end. A token that gives you rights to a share of network revenue sits at the securities end. Most real implementations are somewhere in between, and "somewhere in between" is where legal risk concentrates.

The "Non-Transferable for Profit" Standard

The clearest guidance for staying outside MiCA's CASP provisions: design tokens that are genuinely non-transferable or transfer-restricted, that represent only a right to use your specific service, and that carry no expectation of investment return.

This is a real design constraint. Many network architectures use token transferability to bootstrap liquidity and participation. If you restrict transferability, you may make the token less useful as an incentive mechanism.

The tradeoff is compliance certainty versus network design flexibility. There isn't a clever way to have both. Transferable, tradeable tokens that look like they have investment characteristics will attract CASP scrutiny. Non-transferable credits probably won't — but they're also less useful as a decentralization mechanism.

Grandfathering and Timelines

CASPs that were operating before December 30, 2024 in member states that had adopted transitional provisions have a grandfathering period — they can continue operating under national regimes while seeking MiCA authorization. The grandfathering period varies by member state (maximum 18 months from December 30, 2024).

For new projects launching after December 30, 2024: there is no grandfathering. If you're launching a token that looks like it falls under MiCA and you want to provide CASP services in the EU, you need authorization.

The Honest Summary

MiCA provides more clarity than the pre-MiCA environment, where you were trying to apply financial instruments law designed in the 1990s to assets its authors had never imagined. That clarity is genuinely useful.

For compute network builders:

• If your token is purely a non-transferable access credential for your specific service, you're likely outside MiCA.
• If your token is freely transferable and traded on exchanges, you're inside MiCA's scope and need CASP authorization if you're providing any of the covered services.
• If you're somewhere in between — most real networks are — you need legal analysis of your specific design. Not blog posts.

At Agentosaurus, we think about compute economics from a different angle — we're building AI analysis infrastructure, not a decentralized compute marketplace — but we track this space because the infrastructure layer for AI in Europe is going to have to navigate both the AI Act and MiCA simultaneously as these systems converge.

The regulatory landscape for AI infrastructure in Europe is dense and getting denser. That's not a complaint; it's the operating environment. Building compliance into architecture from the start is cheaper than retrofitting it later.

If you're working through MiCA classification questions for a compute network — hello@agentosaurus.com.