The Edges of MiCA Scope 2026 — DeFi, Staking, DLT Pilot, Article 60, Reverse Solicitation

Why MiCA is best understood at its edges

MiCA has no article-level DeFi exemption. The carve-out sits in Recital 22: “Where crypto-asset services are provided in a fully decentralised manner without any intermediary, they should not fall within the scope of this Regulation.” The same recital says MiCA applies to services and activities performed, provided or controlled, directly or indirectly, by persons — “including when part of such activities or services is performed in a decentralised manner.”

That single sentence is the template for almost every hard MiCA question. The regime was written around entities acting on behalf of clients. So the difficult cases are the boundary cases — where there is no clear intermediary, where the activity is half-covered, where another EU regime takes over, or where the token simply is not what its label says. This pillar walks the perimeter: DeFi as the spine, then staking and lending, the DLT Pilot Regime interface, the Article 60 bank track, reverse solicitation for non-EU firms, and the MiCA-versus-MiFID II line.

In every one of those cases the test is substantive. Not “is the protocol decentralised” but “for each identifiable legal entity, what service is it providing.” Not “is this called staking” but “how are the assets held and what is promised.” Not “what does the issuer call the token” but “what rights does it actually confer.” The label never controls; the substance does.

DeFi — the spine of the scope question

The Recital 22 exclusion is real but narrow. The substantive question is whether any identifiable legal entity is involved in the service. If yes, even where the underlying protocol runs on smart contracts, the entity is within MiCA scope. If no, and the service operates entirely autonomously, the carve-out applies.

In practice, very few systems described as DeFi in 2026 actually meet the carve-out’s strict reading. Most have:

• A frontend operated by a legal entity (a foundation, a development team, a commercial company)
• A governance mechanism controlled by identifiable token holders
• A treasury managed by signers
• Development that produces protocol upgrades from an identifiable team

Any one of these elements brings the relevant entity within MiCA scope for whatever crypto-asset service it provides.

The three layers DeFi systems typically span

A typical DeFi system in 2026 has three layers, each with different MiCA implications:

Layer 1 — The smart contract code. Open-source, deployed on-chain, executable by anyone. If genuinely autonomous and uncontrolled, this layer is outside MiCA per Recital 22.

Layer 2 — The frontend. A web interface (often Vercel-hosted, sometimes IPFS-hosted) that allows users to interact with the smart contracts. Operated by an identifiable legal entity. This is where MiCA exposure typically lives. The frontend operator is providing a crypto-asset service (exchange, swap, or custody-equivalent) and falls within MiCA scope as a CASP.

Layer 3 — The governance / treasury / development organisation. Often structured as a DAO with a legal-entity wrapper (Cayman Foundation, Wyoming DAO LLC, Liechtenstein Trust). Controls the treasury and votes on protocol upgrades; in some cases also collects protocol fees. Whether this layer falls within MiCA depends on what the entity actually does — pure governance is generally outside; fee distribution or custody-equivalent activity is generally inside.

The assessment for a DeFi system is not “is the protocol decentralised” — that’s a yes/no the protocol’s marketing answers. It is “for each identifiable legal entity in the system, what crypto-asset services is it providing, and which fall within MiCA scope.”

What the authorities have said

No EU authority has published a binding test for when a DeFi frontend becomes a CASP. The EBA and ESMA covered decentralised finance in their January 2025 report on recent developments in crypto-assets under Article 142, and national competent authorities assess arrangements case by case against Recital 22. In practice the question each authority asks is the one above: which identifiable entity provides which service. Treat any claim that a particular regulator has “cleared” a DeFi structure with caution unless it comes with a published decision.

DeFi grey zones

Several activities sit in genuinely unsettled territory:

Pure protocol governance. A DAO that votes on protocol parameters but provides no service. Generally outside MiCA. But where governance produces fee distribution or custody-like activities, the boundary moves.

Wrapped crypto-assets. Tokenisation of one crypto-asset into a wrapped representation (e.g., wBTC on Ethereum). Whether wrapping is a service within MiCA depends on whether an entity custodies the underlying asset — typically yes, which brings wBTC issuance under Title III if it has stable-value characteristics or under Title V as a transfer service.

Cross-chain bridges. Operated by identifiable legal entities running on smart contracts. The entity is providing transfer services and falls within MiCA scope. Bridge operators have generally been the first DeFi-adjacent actors to engage with supervisors.

Institutional DeFi. Platforms that facilitate institutional access to DeFi protocols (Aave Institutional, Compound Treasury). The platform operator is unambiguously a CASP.

Staking and lending — partial coverage, not a free zone

A founder building a staking, lending, or yield product asks the natural question: do we need a MiCA licence? The honest answer is not the clean yes or no they want. MiCA does not establish a comprehensive, standalone regime for the staking, lending, or borrowing of crypto-assets. Those activities, as activities in themselves, sit largely outside MiCA’s current scope. But “outside MiCA” is not “unregulated”, and it is not a stable position.

Staking: the structural question

Staking is the activity of using crypto-asset holdings to participate in Proof-of-Stake consensus mechanisms — the user locks up tokens and runs (or delegates to) validators to earn rewards. Whether it falls within MiCA scope depends entirely on the operational structure. Three patterns:

Pattern 1 — User self-staking. The user controls the private keys, runs the validator software, and receives rewards directly. No CASP involvement. Out of scope under Recital 22 — the same DeFi carve-out for fully decentralised activity without an intermediary.

Pattern 2 — CASP staking-as-a-service. A CASP custodies the user’s crypto-assets and operates the staking infrastructure on the user’s behalf. The CASP is the intermediary. In scope: at minimum, custody and administration of crypto-assets (Article 3(1)(17)) plus typically transfer and operational management of the staking activity.

Pattern 3 — Delegated staking through a CASP. The CASP custodies the user’s assets and delegates them to external validators. In scope on the same basis as Pattern 2 — custody plus a delegation service.

For the user, all three may produce similar economic outcomes. For the CASP and the supervisor, the regulatory treatment is materially different.

Custody of staked assets is still custody. Article 75 applies as it does to unstaked assets: a custody agreement, a register of positions, a custody policy, segregation of client holdings (75(7)) and liability for losses attributable to the CASP, capped at market value (75(8)). MiCA does not allocate slashing losses; whether a slashing event is attributable to the CASP turns on how it runs the validators, so the client agreement should say plainly who bears that risk.

CASP staking: the conduct stack

CASPs offering staking-as-a-service face the full conduct obligations:

• Article 75 custody — the custody agreement, register of positions and custody policy; segregation of staked client assets (75(7)); sub-custody only with CASPs authorised under Article 59 (75(9)).
• Article 66(2) client information — fair, clear and not misleading, including in marketing: slashing risk, lock-up periods, validator selection and reward variability.
• Article 67 own funds — no specific increase for staking, but the operational-risk profile informs the prudential assessment under Article 68 governance.
• Article 73 outsourcing — where validator operations are outsourced, the outsourcing framework applies, including service-level monitoring and sub-custody documentation.
• Article 72 conflicts of interest — where validator selection is influenced by third-party arrangements (MEV revenue sharing, priority slot allocation), the conflict has to be identified, prevented or managed, and disclosed only as a last resort.

Slashing is the protocol penalty for validator misbehaviour or extended downtime. Double-signing and equivocation produce material slashing; extended downtime produces small per-hour slashing. CASPs that bear the risk typically operate validators in-house with redundancy, limit validator concentration, hold operational-risk capital beyond the Article 67 minimum, and document the loss-compensation framework in client terms. Pushing slashing risk onto clients through service terms has to meet the Article 66(2) standard — the disclosure must be specific and prominent. Lock-up disclosure (duration, early-exit conditions, fees, queue-dependent variability) is part of the same obligation.

Liquid staking — its own classification puzzle

Liquid staking issues a tokenised representation of staked crypto-assets that can be transferred and used in DeFi while the underlying assets remain staked (stETH, mSOL, rETH). It raises a distinct question on three fronts:

• The liquid-staking token itself falls within MiCA Title II as a generic crypto-asset, or potentially Title III as an ART if the design tracks the underlying value through a stabilisation mechanism rather than a pure 1:1 representation. Case-by-case classification by ESMA.
• The issuance entity — where a legal entity issues the token (Lido’s stETH, Coinbase’s cbETH), that entity is the issuer under MiCA, triggering Title II white-paper notification or Title III/IV authorisation.
• The liquid-staking activity — if the issuer custodies the underlying staked assets for token holders, that is a CASP custody service. Token issuance plus custody produces a layered regulatory picture.

Lending: the gap the EU is already reviewing

MiCA’s CASP regime is built around the ten crypto-asset services in its annex — custody, exchange, execution of orders, transfer, advice, portfolio management, operation of a trading platform, placement, and reception/transmission of orders. Staking and lending, as standalone activities, are not on that list. The EU did not leave the gap silently: Article 142 required the Commission, after consulting the EBA and ESMA, to report on the latest developments in crypto-assets, explicitly including decentralised finance and the lending and borrowing of crypto-assets. The EBA and ESMA published a joint report feeding into that work in January 2025. A regulator does not commission a market analysis of an activity it intends to leave permanently unregulated.

So the realistic position for most staking or lending businesses is: the core yield activity is in the grey zone, but the surrounding services are squarely MiCA-regulated and need a CASP authorisation. A staking product needs the staked assets held somewhere — that is custody, a regulated service. Users move assets in and out — that engages transfer and often exchange. A lending platform typically custodies collateral. The firm is rarely fully outside the regime; it is partially inside it. And substance over form applies throughout: a product labelled “staking” or “yield” that, in substance, pools client funds for collective investment or promises a deposit-like return can fall under collective-investment or deposit-taking rules regardless of the crypto-native label.

The practical move for a founder is threefold. Get the specific product classified — “does MiCA regulate staking” has no general answer; a custodial, pooled, fixed-return product and a non-custodial, pass-through, variable-reward product have completely different profiles. Authorise the MiCA-regulated services around it regardless. And build for the future regime — segregated assets, clear disclosures, a controlling entity that can hold an authorisation, so that a future staking/lending regime is an adjustment, not an existential problem.

The DLT Pilot Regime interface

The EU’s digital-finance architecture rests on two pillars adopted together. The DLT Pilot Regime (Regulation (EU) 2022/858), in force from 23 March 2023, covers trading and settlement of tokenised financial instruments on permissioned distributed-ledger infrastructure. MiCA (Regulation (EU) 2023/1114), with the CASP regime applying from 30 December 2024, covers crypto-assets that are not financial instruments.

The two are mutually exclusive at the per-token level. The classification of the token under MiFID II (financial instrument or not) determines which regime applies. A tokenised share is a security; a stablecoin pegged to a basket is a crypto-asset; a tokenised investment-fund unit is a security; a utility token is generally a crypto-asset.

What the Pilot Regime grants

The Regime lets recognised market infrastructures operate as a DLT-MTF (multilateral trading facility), a DLT-SS (settlement system, operating as a CSD), or a DLT-TSS (combined trading and settlement). It grants targeted exemptions from MiFID II and CSDR for operational features specific to DLT — for example, allowing direct end-investor access to the DLT-MTF without intermediation by an investment firm, or allowing the DLT-SS to settle without operating exactly as a traditional CSD. The exemptions are not blanket. The market infrastructure still holds MiFID II authorisation, complies with the underlying conduct rules, and engages with its home NCA. The Regime is a sandbox, not a deregulation — and the compliance lift is heavier than a CASP authorisation, not lighter.

Three thresholds cap the Regime during the pilot phase: issuer market capitalisation under EUR 500 million for shares, issue size under EUR 1 billion for bonds, and aggregate DLT-financial-instrument market value under EUR 6 billion per market infrastructure. A successful DLT-MTF approaching the aggregate ceiling must exit the Regime or limit growth — the framework is not designed to scale to traditional-CSD volumes. That also means the Pilot Regime is a path for mid-cap equity tokenisation and corporate-bond pilots, plus selected UCITS-unit tokenisation — not for the largest companies or sovereign bonds.

RWA tokenisation — marketing versus regulation

The “real-world asset” tokenisation discussion bundles together very different regulatory situations:

• Tokenised investment-fund or real-estate-fund units — generally a UCITS or AIFM matter; the token wrapper is a representation, the underlying fund is the regulated product.
• Tokenised bonds within the Pilot Regime thresholds — Pilot Regime applies for trading/settlement; MiFID II for issuance and conduct.
• Tokenised commodities or commodity-backed assets — typically MiCA scope as crypto-assets unless the design produces a MiFID II derivative.
• Tokenised real-estate ownership (direct) — typically not within either Regime; subject to general real-estate and securities law.

The Pilot Regime is narrower than the RWA discussion suggests. RWA-platform marketing that conflates it with general tokenisation infrastructure overstates its scope.

The two regimes share infrastructure (both engage with ESMA’s supervisory-convergence work and interact with the AMLR/AMLA framework on AML supervision) but not scope. An entity operating in both (a DLT-MTF for tokenised securities plus crypto-asset custody) runs a two-track engagement: the Pilot Regime authorisation with the MiFID II supervisory team, the CASP authorisation with the MiCA team, coordinated but separate. The Regime has applied since 23 March 2023, and Article 14 of Regulation 2022/858 required the Commission to report on it after three years, including on whether to extend, amend, make permanent or end it and on the thresholds.

Credit institutions and investment firms — the Article 60 track

MiCA created two entry points to crypto-asset services. Article 63 is the default — a new entity files a complete CASP application and the NCA decides within 40 working days of a complete file. Article 60 is a notification route for entities that already hold an EU financial-services licence, and it lists them precisely:

• Credit institutions — any crypto-asset service (60(1)).
• Central securities depositories — custody and administration only (60(2)).
• Investment firms — the crypto-asset services equivalent to the investment services they are authorised for: custody maps to safekeeping, a trading platform to an MTF or OTF, exchange to dealing on own account, execution, placing, reception and transmission, advice and portfolio management to their MiFID counterparts (60(3)).
• E-money institutions — custody and transfer services only, and only for the e-money tokens they issue (60(4)).
• UCITS management companies and AIF managers — services equivalent to their portfolio-management and non-core services: reception and transmission, advice, portfolio management (60(5)).
• Market operators — operating a trading platform (60(6)).

Payment institutions are not on the list; they need an Article 63 authorisation.

Each entity notifies its home NCA at least 40 working days before providing the services for the first time, with the information in Article 60(7): a programme of operations, AML/CFT controls and risk assessment, business continuity, ICT documentation, client-asset segregation, custody and other service-specific policies. The NCA has 20 working days to check completeness; where something is missing it sets a deadline of up to 20 working days, and the 40-working-day period is suspended until then. Further requests do not suspend it, and the entity may not start while the notification is incomplete (60(8)).

The route saves the application, not the conduct rules. Once notified, the entity follows MiCA’s rules for the services it provides — Article 66 conduct, safeguarding under Article 70, governance, conflicts, outsourcing and complaints, and the service-specific rules in Articles 75 to 82. What it does not take on is set out in Article 60(10): Articles 62, 63, 64, 67, 83 and 84 do not apply, because the existing licence already covers authorisation, withdrawal, prudential capital and the control of shareholdings. The right to provide the services falls away if the underlying licence is withdrawn (60(11)).

Cross-border service still uses the Article 65 passport notification. Article 60 is the right route for an established bank adding custody, an investment firm adding crypto trading or execution, a fund manager adding crypto portfolio management, or a market operator adding a crypto trading platform. It is the wrong route for anyone not on the list, and for any service outside the equivalence the paragraph allows.

Reverse solicitation — when non-EU firms can serve EU clients

A crypto exchange licensed in Dubai, Singapore, or the British Virgin Islands has EU users. The compliance team asks: do we need a MiCA authorisation, or can we keep serving them without one? The answer founders hope for is reverse solicitation — and MiCA codifies a version of it in Article 61. But the way the Regulation and ESMA’s guidelines build it, reverse solicitation is the narrow exception, not the workaround.

Article 61 allows a third-country firm (one with no MiCA authorisation and no EU establishment) to provide a crypto-asset service to a client located in the EU where that service is provided at the client’s own exclusive initiative. Each word carries weight: own (the impulse must come from the client, not from the firm or an intermediary acting for it), exclusive (a client nudged by the firm’s advertising has not acted on exclusive initiative), and initiative (responding to a firm’s outreach is not initiative).

What the exemption does NOT permit:

What the firm wants to do	Allowed under Article 61?
Serve a client who genuinely approached the firm unprompted	Yes — within the narrow exemption
Advertise, market, or promote to EU clients, then serve those who “respond”	No — soliciting defeats the exemption
Use a client’s initial request to cross-sell new crypto-assets or services	No — explicitly barred
Rely on a website disclaimer to convert solicited clients into “client-initiated” ones	No — disclaimers cannot override facts

ESMA’s guidelines under Article 61, finalised in December 2024, carry a consistent message from the consultation onwards. The exemption is to be construed narrowly and regarded as the exception. Facts beat paperwork — whether a relationship was genuinely client-initiated is assessed on the facts, and contractual disclaimers stating “client-initiated” cannot supersede contrary facts. Soliciting is broad — EU-targeted advertising, EU-language marketing, EU-geo-targeted paid media, sponsorship of EU events, and EU-focused affiliate arrangements all amount to soliciting. And supervisors are directed to detect and prevent circumvention.

The cross-selling line is the one firms most often miss. A client who opened an account to buy one crypto-asset has invited that service and nothing more; marketing staking, derivatives, or a new token is a fresh solicitation and evidence to a supervisor that the firm runs a solicitation model. The exemption also does not last indefinitely — it covers the discrete service the client requested, and an expanding, ongoing EU book drifts out of “own exclusive initiative” territory. A firm with a growing EU book should be planning a MiCA CASP authorisation or an EU establishment, not extending the exemption. The diagnostic for counsel is not “do we have a disclaimer” but “would a supervisor, looking at our advertising, affiliates, and client records, conclude we solicited.”

The MiCA-versus-MiFID II line — when a token leaves MiCA entirely

Most crypto-regulation conversations start with “which MiCA licence do we need.” There is an earlier question that determines whether MiCA applies at all: is the token a financial instrument? MiCA is, by design, the regime for crypto-assets that are not already covered by existing EU financial-services law. Article 2(4)(a) excludes from MiCA any crypto-asset that qualifies as a financial instrument under MiFID II, with the definition sitting in MiFID II Article 4(1)(15) by reference to Annex I Section C. If a token is a transferable security or a derivative, MiCA does not apply — MiFID II and its surrounding framework do. The two regimes do not overlap on the same asset: a token is either a financial instrument (MiFID II) or a crypto-asset that is not one (MiCA), never both. Getting this wrong is the most expensive classification error in crypto: a team that builds a MiCA white-paper-and-CASP plan for a token that is actually a security has planned for the wrong regime entirely.

For years, whether a given token was a financial instrument was answered differently across member states. ESMA closed that gap. On 19 March 2025 it published its Guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments (ESMA75-453128700-1323). National competent authorities and market participants must make every effort to comply — which makes the guidelines the single reference point.

The transferable-security test

The most common category a token falls into is a transferable security. ESMA applies three cumulative criteria — all three must be met:

Criterion	What it means
Not a payment instrument	The token is not, by its nature, a means of payment
Class of interchangeable securities, same issuer	The token belongs to a class of securities that are interchangeable and issued by the same issuer
Negotiable on the capital market	The token is negotiable on the capital market

A token that meets all three is a transferable security (a financial instrument) and sits under MiFID II, not MiCA. A token that fails any one is not a transferable security on this test, though it may still be another type of financial instrument or a MiCA crypto-asset.

Derivatives and hybrids

A crypto-asset can also be a derivative — either the underlying of a derivative contract or itself structured as one. The assessment references MiFID II Annex I Section C, points (4) to (10), which identify features such as a future commitment (a forward, option, swap, or similar) and a value derived from an external reference point. Teams focused on the “utility token versus security” debate sometimes miss that a token with a forward commitment and a value tracking an external benchmark is a derivative — a third regime, with its own licensing consequences.

The hardest cases are hybrid tokens. ESMA’s instruction is clear: assess them substance over form. If any component of the token fits the financial-instrument definition under MiFID II, that classification applies and takes precedence over the issuer’s label. A “utility token” that, in substance, confers profit participation or is a negotiable class of securities is not saved by its name.

Tokenised RWA — the line in practice

Real-world-asset tokenisation is where this line gets tested most often in 2026. The governing principle is substance over form: a token wrapper on a transferable security produces a tokenised transferable security, not a non-security crypto-asset. The MiFID II Article 4(1)(15) test applies to the underlying right, not the technical wrapper. Working through the common categories:

Tokenised asset	Typical classification
Treasuries, investment-grade bonds, equities	Almost always MiFID II — the underlying is a transferable security
Fund units (UCITS, AIF)	Almost always MiFID II — units in a collective investment undertaking (Section C(3))
Real estate via SPV or partnership	Typically MiFID II — the participation is usually a collective-investment unit
Real estate, direct title (no SPV)	Borderline — may be a non-financial-instrument crypto-asset under MiCA; rare in practice
Private credit	Borderline — fund participation is MiFID; a direct debt claim may be bond-like (MiFID) or a crypto-asset
Commodities (non-derivative)	Typically MiCA — unless a commodity-derivative wrapper produces MiFID classification
Carbon credits	Mixed — spot credits typically MiCA, carbon derivatives MiFID
Art and collectibles	Typically MiCA for direct/fractional tokens; MiFID where an art investment fund is involved

The practical trap is filing for CASP authorisation expecting it to cover RWA activity. A CASP authorisation covers crypto-asset services; it does not cover MiFID-regulated activity. An operator servicing both a financial-instrument-token stream and a crypto-asset-token stream needs both CASP authorisation under MiCA and MiFID II investment-firm authorisation — a dual-authorisation framework that is more complex than single-track CASP, with different supervisors and a six-to-twelve-month authorisation timeline. And the DLT Pilot Regime, covered above, is the narrow sandbox for the financial-instrument side, not a general RWA framework.

The classification decision sits upstream of everything else. If the token is a financial instrument, the MiFID II framework applies (Prospectus Regulation for the offer, investment-firm authorisation for intermediaries, the MiFID conduct regime), and MiCA is irrelevant. If it is an EMT or ART, MiCA Titles IV/III apply (issuer authorisation, reserves). If it is another crypto-asset, MiCA Title II applies (white paper notification, the lighter regime). And classification is not a one-time exercise — added staking rewards or a governance change can drift a token toward financial-instrument territory, and later fractionalisation does the same, so re-assess when the design changes materially.

The review and the direction of travel

Article 142 required the Commission to report on the latest developments in crypto-assets, in particular areas MiCA does not address — decentralised finance and the lending and borrowing of crypto-assets among them — accompanied where appropriate by a legislative proposal. The EBA and ESMA reported on these areas in January 2025. Any change to the DeFi carve-out or a new lending or staking regime needs a legislative proposal; check its status rather than relying on a forecast.

The through-line across every edge in this pillar: the perimeter is moving inward, not outward. The DeFi carve-out is narrow. Staking and lending are under active review. The DLT Pilot Regime and the MiFID II line both turn on a classification that the issuer cannot dictate. Article 60 is an authorisation shortcut, not a substance exemption. Reverse solicitation is the exception, not the route. A business plan built on any of these edges as a permanent loophole is built on a regime that is expected to change.

The buyer’s view

For builders and operators making structural decisions in 2026:

• DeFi — a pure-protocol launch with no entity ownership and no controlled frontend is the cleanest MiCA position; any commercial frontend probably needs CASP authorisation. Cayman/Liechtenstein wrappers solve US securities-law risk, not EU CASP-scope risk.
• Staking and lending — classify the specific product first, authorise the surrounding custody/exchange/transfer services regardless, and build for a future regime.
• DLT Pilot Regime — confirm the token’s MiFID II classification and the size thresholds before assuming the Regime applies; it is narrower than RWA marketing suggests.
• Article 60 — the right route when you already hold a listed sectoral licence and the service falls within the equivalence in Article 60; notify at least 40 working days ahead and remember the Article 65 passport for cross-border.
• Reverse solicitation — sustainable only for genuinely occasional, unsolicited contact at small scale; a material EU book needs authorisation or an EU establishment.
• MiFID II line — run the token through ESMA’s March 2025 guidelines before any MiCA work; the wrong regime is the costliest error in crypto.

The diagnostic for counsel across all of these is the same: not “is X regulated” but “run our specific structure through the classification and tell us, in writing, which entity provides which service and what each token actually is, right down to which surrounding services need authorisation.” Counsel that answers “you’re fine, it’s outside MiCA” without that analysis has given a dangerously incomplete answer. The firms in our index with relevant experience are listed below.