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

Why MiCA is best understood at its edges

MiCA Article 2(2)(e) excludes from the regulation’s scope crypto-asset services “provided in a fully decentralised manner without any intermediary.” Recital 22 elaborates: where a crypto-asset service is provided without the involvement of any intermediary acting on behalf of clients, the service is outside MiCA.

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 Article 2(2)(e) 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 Article 2(2)(e).

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 major NCAs are saying

BaFin (Germany). Published a 2026 position paper stating that frontend operators facilitating DeFi protocol interaction are providing crypto-asset services within the meaning of MiCA. The position is the strictest among major EU NCAs. BaFin has opened one investigation against a Frankfurt-based DeFi frontend operator (resolved as MiFID II categorisation, not MiCA enforcement).

AMF (France). Follows BaFin’s reading. The AMF has been particularly active on tokenised RWA platforms and DeFi hybrids — assessing each platform’s specific structure.

AFM (Netherlands). Pragmatic case-by-case approach. The AFM has pre-engaged with several DeFi-adjacent platforms operating from the Netherlands to clarify status before formal supervisory action.

Bank of Lithuania. Confirmed that Lithuanian-based DeFi frontends operating without CASP authorisation are subject to enforcement. Has not publicly named subjects, but the supervisory approach is clear.

ESMA. Coordinating an EU-wide convergence project on DeFi scope. The Q3-Q4 2026 ESMA opinion will likely tighten the boundary further — particularly around frontend operators and governance token treatment, then cross-chain bridges.

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 Article 2(2)(e) — 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.

ESMA’s 2025-2026 Q&A clarified the ambiguities. Custody of staked assets is custody — the Article 75 framework applies (segregation, daily reconciliation, bankruptcy-remoteness) the same as for non-staked assets. Operating the staking infrastructure is treated as an integrated part of the custody-administration service where conducted on behalf of clients. Reward distribution to client accounts is part of the service. And slashing-risk allocation defaults to the CASP under Article 75(7) unless properly documented as user-allocated.

CASP staking: the conduct stack

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

• Article 75 custody safeguarding — segregation of staked client assets, daily reconciliation, bankruptcy-remoteness, sub-custody rules where validators are third parties.
• Article 7 marketing communications — risk disclosures covering slashing risk, lock-up periods, validator-selection criteria, and reward variability; ESMA Guidelines on format-specific risk warnings apply.
• 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 78 inducements — where validator selection is influenced by third-party arrangements (MEV revenue sharing, priority slot allocation), the inducements rule may apply.

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. Attempting to push slashing risk onto clients via service terms draws Article 7 fair-clear-not-misleading scrutiny — the disclosure must be specific and prominent, and the client must demonstrably understand it. Lock-up disclosure (duration, early-exit conditions, fees, queue-dependent variability) is part of that same Article 7 obligation; some CASPs received supervisory engagement on buried lock-up disclosure in early 2026.

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: the Article 142 review clause mandates the Commission, working with ESMA and EBA, to assess developments in the crypto-asset market, explicitly including the lending and borrowing of crypto-assets. ESMA and EBA published a joint report under that clause in early 2025 analysing lending, borrowing, and staking trends across the EU. 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 substantive 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 runs three years from 23 March 2023, extendable for another three; the Commission’s review (expected 2026-2027) will report on making the Regime permanent and on raising or removing the thresholds, alongside deeper integration with CSDR and MiFID II.

Credit institutions and investment firms — the Article 60 track

MiCA created two parallel entry points to crypto-asset services. Article 63 is the default — a new entity files a complete CASP application, goes through the five-month review, and receives a licence for the services in its programme of operations. Article 60 is a streamlined notification route for entities that already hold a sectoral EU financial-services licence: credit institutions under CRR, investment firms under MiFID, EMIs under EMD2, payment institutions under PSD2, UCITS managers, AIFMs, and central securities depositories. These entities have already been through a substantive authorisation — governance, risk management, compliance, internal audit, a competent management body. Adding crypto-asset services does not require a second authorisation file from scratch.

The path saves the application — not the compliance. Once the notification is complete and the 40-working-day window has passed, the entity is treated as a CASP for the notified services: Article 66 conduct rules apply, Article 67 own funds (same higher-of-two methodology), Articles 68-73 on governance, conflicts, outsourcing, complaints, custody, and transfer, and Articles 76-77 on marketing and consumer protection. The AML rulebook applies. The supervisor that already oversees the entity continues to do so — a French bank notifying is supervised by the ACPR for its crypto business, with no second supervisor introduced.

MiCA Annex II maps which crypto-asset services each licence category can provide. Credit institutions get the full set — custody, exchange, transfer, advice, portfolio management, trading-platform operation. MiFID investment firms get the crypto-asset services that mirror their existing investment-services authorisation. EMIs get exchange of crypto-assets for funds, transfer, and custody where it fits the EMD2 set. UCITS managers and AIFMs get advice and portfolio management limited to what fits collective-portfolio management. A service the mapping does not cover requires the Article 63 route.

The mechanics: the entity files at least 40 working days before commencement, with a description of the services, the commencement date, the governance and risk-management arrangements specific to the crypto business, client-asset safeguarding procedures, IT systems, proof-of-reserves and segregation for custody, and AML/CFT policies. The NCA reviews for completeness and eligibility — it cannot block on substantive grounds (this is an information regime), but it can object on incompleteness, on the entity not meeting the Annex II conditions for its licence type, or on a governance concern. In practice NCAs use the window to engage, and the 40-working-day floor often becomes a 60-80 calendar-day reality.

Two further traps recur. The 40-working-day window counts working days from a complete notification, and information requests stop the clock. And the notification governs only the home-NCA relationship — cross-border service into other member states still uses the Article 65 passport notification, the same mechanism an Article 63 CASP uses. The notification stack is two-layered for cross-border activity. Article 60 is the right route for established banks adding crypto custody, MiFID firms layering crypto trading onto existing venues, EMIs adding crypto transfer, and asset managers offering crypto portfolio management to professional clients. It is the wrong route for a non-financial corporate setting up a new venture or a pure exchange or wallet provider with no traditional footprint (Article 63 is faster); it is equally wrong for any service outside the Annex II mapping.

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 issued its 2025 guidelines under the Article 61 mandate, and the message is consistent from its consultation through its final report and guidelines. 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 2026 review and the direction of travel

MiCA Article 142 requires the Commission to review DeFi treatment and the lending/borrowing question. ESMA’s opinion is expected in Q3-Q4 2026. The likely outcomes for DeFi: most likely, the Commission confirms the current Article 2(2)(e) carve-out for genuinely autonomous protocols and tightens the boundary around frontend operators and other intermediaries, then signals a broader framework for DeFi-specific risks (smart-contract risk, MEV, oracle risk) in a future package. Less likely, a new DeFi-specific regulation is proposed — the Commission has signalled reluctance to layer more regulation on top of MiCA. Unlikely, the carve-out is removed entirely, which would require a political consensus that does not appear to exist.

The through-line across every edge in this pillar: the perimeter is moving inward, not outward. The DeFi carve-out is narrow and getting narrower. Staking and lending are under active review. The DLT Pilot Regime and the MiFID II line both turn on a substantive 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 sectoral licence and the service is within the Annex II mapping; budget 60-80 calendar days 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.