Staking-as-a-Service Under MiCA: What Every EU CASP Needs to Know

Why MiCA Regulates Staking-as-a-Service Even Though It Never Mentions Staking

MiCA — Regulation (EU) 2023/1114 — contains no article titled "staking," no staking-specific capital requirement, and no dedicated licensing category for validators. Yet staking-as-a-service is firmly inside MiCA's regulatory perimeter. The mechanism is indirect but unambiguous: Article 2 defines MiCA's scope as applying to any person that provides crypto-asset services in the EU, and Article 3(1)(16) defines crypto-asset services to include custody and administration of crypto-assets on behalf of clients. When a CASP holds a client's private keys and participates in staking on that client's behalf, it is providing a custody service — and that is what MiCA regulates. The staking mechanics are incidental; the custody relationship is the hook.

ESMA confirmed this framing explicitly. In Q&A reference 2067, the European Commission answered that MiCA does not establish a bespoke regime for staking, but that intermediary staking — where a third party manages keys and staking operations for clients — falls within the existing custody and portfolio management provisions. This is the critical regulatory distinction. Solo staking, where a token holder runs their own validator node, retains their own private keys, and interacts directly with the protocol, falls outside MiCA's scope entirely: there is no intermediary, no custody, and no client relationship. Staking-as-a-service, by contrast, involves an intermediary holding or controlling the client's assets, which triggers Article 75 duties, segregation obligations, and the explicit-consent requirement under Article 75(5). The legal test is not what the service is called — it is who controls the private keys.

Which CASP Licence Class Do Staking Providers Need?

MiCA's Annex IV divides CASP services into three capital classes, and the classification is cumulative: the minimum own-funds floor you must meet is the highest class triggered by any single service you offer. Staking-as-a-service does not have its own named entry in Annex IV — instead, ESMA's position is that it falls under custody and administration of crypto-assets on behalf of clients, because the CASP holds or controls client assets while delegating them to a validator. That service is a Class 2 activity, which carries a minimum own-funds floor of €125,000 — or 25% of fixed overheads under Article 67, whichever is higher.

The upgrade risk is the critical operational point. A firm already authorised for Class 1 services only — reception and transmission of orders, execution, placing, investment advice, portfolio management, or transfer services — sits at a €50,000 floor. The moment that same firm begins holding or controlling client crypto-assets to participate in staking on their behalf, it has triggered Class 2 and must meet the €125,000 minimum before offering the service. Adding staking without reassessing your prudential position is one of the most common authorisation errors compliance teams make. For a full breakdown of the authorisation process, see the complete CASP licence requirements guide.

Remember that these are floors, not caps. Under Article 67, a firm whose fixed overheads are large enough may owe significantly more than €125,000 — the rule requires own funds equal to the higher of the Annex IV minimum or one quarter of projected annual fixed overheads. Firms operating for less than twelve months use projected figures under Article 67(2). Only specific deductions listed in Article 67(3)(a)–(d) are permitted when computing the overhead base; no others apply.

Article 75 Custody Obligations That Apply to Every Staking Provider

When ESMA confirmed in Q&A 2067 that staking-as-a-service constitutes custody under MiCA, the practical consequence is that every obligation in Article 75 applies in full — not selectively. There is no staking-specific carve-out or lighter regime. If your platform stakes on behalf of clients, you are a custodian of those assets for the entire lifecycle of the position, including the bonding and unbonding periods when the assets are locked and may be illiquid.

The core Article 75 requirements that staking providers must implement are as follows. First, the CASP must conclude a written agreement with each client that clearly specifies the duties the CASP assumes and the responsibilities allocated to each party — including what happens if slashing or a validator failure occurs. Second, Article 70(1) requires strict segregation: client crypto-assets must be kept separate from the CASP's own estate at all times, including during bonding periods when assets are committed to a validator. Third, the CASP must maintain records that are accurate and current, capable of identifying each individual client's assets at any given moment — this cannot be a batch or pooled ledger that obscures individual entitlements. Fourth, client assets must be returned on demand in accordance with the custody agreement; any lock-up or notice period must be disclosed upfront and contractually agreed. Fifth, and critically, Article 75(8) establishes a presumption of liability: any loss arising from the staking service itself is deemed attributable to the CASP, unless it resulted from an external event beyond the CASP's reasonable control. Validator slashing caused by the CASP's own infrastructure choices is unlikely to qualify as such an external event.

The following compliance checkpoint covers what a product or legal team should verify before launch:

• Client agreement signed before staking begins, covering duties, fee structure, lock-up terms, and liability allocation.
• On-chain or ledger segregation confirmed — client assets must not commingle with the CASP's treasury at any point, including during bonding.
• Per-client record-keeping system in place, auditable and capable of producing individual asset positions on demand.
• Redemption process documented — including realistic unbonding timelines disclosed to clients before they commit assets.
• Liability framework reviewed by counsel — specifically mapping which failure scenarios fall inside or outside the Article 75(8) presumption.
• Operational resilience controls applied to the staking infrastructure itself; for context on the broader IT risk framework, see DORA compliance for CASPs.

The Hard Line: You Cannot Stake Client Assets on Your Own Account

Article 70(1) of MiCA is unambiguous: CASPs must prevent the use of clients' crypto-assets for their own account. ESMA's position in Q&A 2067 applies this prohibition directly to staking. A CASP cannot stake client assets and retain the resulting rewards for itself — even if the client has explicitly consented to that arrangement in writing. The prohibition is categorical. Consent does not create an exception.

The line between the permitted model and the prohibited model comes down to where the economic benefit of the staking activity flows. Under the permitted structure, the CASP stakes on behalf of the client, all staking rewards accrue to the client, and the CASP deducts an agreed service fee from those rewards before passing the remainder on. The CASP earns from the service relationship, not from the staking position itself. Under the prohibited structure, the CASP retains staking rewards in whole or in part on its own account — whether framed as a spread, a yield share, or any other mechanism — because the client asset is effectively being deployed to generate returns for the CASP's own balance sheet. That structure is off the table regardless of how the commercial arrangement is labelled or what the client has agreed to.

This distinction matters at the product design stage, not just at the compliance review stage. Platforms that built their staking economics around a yield-sharing model — where the CASP keeps a portion of gross rewards — need to restructure to a fee-on-rewards model where 100% of staking proceeds are allocated to the client first, and the CASP's compensation is a transparent, contractually stated service charge. Common mis-designs include treating the spread between gross validator yield and client-facing APY as CASP revenue, or pooling rewards and distributing net of a retained margin. Both of these approaches use client assets to generate income for the CASP's own account and fall squarely within the prohibition. For a broader view of where CASPs routinely misconfigure their service models, see the seven biggest MiCA compliance mistakes and review the foundational licensing requirements in the CASP licence requirements guide.

Explicit Client Consent and Liquidity Risk During Bonding Periods

ESMA's Q&A 2067 makes explicit what many CASPs have treated as an afterthought: where staking services are offered alongside any other MiCA-regulated service, the CASP must obtain explicit, documented client consent before committing any assets to a staking protocol. The reason is straightforward — staking typically subjects assets to bonding and unbonding periods during which the client cannot transfer, sell, or otherwise access those assets. That constraint directly conflicts with the client's reasonable expectation of liquidity, and MiCA's consent requirement exists precisely to make that conflict transparent and deliberate.

In practice, this means three things must happen before the first asset is ever staked on a client's behalf. First, pre-contract disclosure must cover, at minimum: the expected bonding period for each supported network, the unbonding timeline (which can range from hours to multiple weeks depending on protocol), and the slashing risk — the possibility that validator misbehaviour causes a partial or total loss of staked principal. These are not boilerplate warnings; they must be specific to the protocol and asset class involved. Second, the CASP must obtain per-client, per-service consent that is affirmative and recorded — a generic terms-of-service acceptance will not satisfy the standard. Consent must be obtained again if the CASP adds support for a new network with materially different bonding or slashing parameters. Third, that consent record must be retained as a durable, auditable document: who consented, to what terms, and when — timestamped and linked to the relevant client account.

The bonding and unbonding cycle also feeds directly into custody record-keeping duties under Article 70 MiCA. Because assets held on behalf of clients during a bonding period remain client assets — not the CASP's own — the position records must accurately reflect both the staked status and any temporary restriction on transferability at all times. A CASP that fails to distinguish between freely available client assets and those locked in a bonding period risks misrepresenting client positions in its registers, which is a separate compliance failure from the consent deficiency. CASPs should ensure their custody ledger system can flag the staked/locked state of each asset lot in real time, so that the CASP's operational controls and its client-facing records stay consistent throughout the unbonding cycle.

Liquid Staking Tokens: When Your stETH or LST Becomes an ART or EMT

Liquid staking tokens (LSTs) — instruments like stETH or protocol-issued receipt tokens — introduce a classification layer that sits entirely separate from the custody question. A CASP that issues or facilitates an LST is not simply providing a custody service; depending on how that token is designed, it may itself constitute a regulated token category under MiCA, triggering the full requirements of Title III (ARTs) or Title IV (EMTs). The service and the instrument must be assessed independently.

The critical variables are economic function and redemption mechanics. An LST that tracks a basket of staked assets — diversified across protocols or validators — and whose value is referenced to that basket's performance may qualify as an Asset-Referenced Token under Article 3(1)(6) MiCA. An LST pegged one-to-one to a fiat currency with an unconditional right of redemption at par starts looking much more like an E-Money Token under Article 3(1)(7). Most current LSTs fall into neither category cleanly, but that determination requires a documented legal analysis — not a default assumption. Each token must be assessed on its own terms.

If an LST qualifies as an ART or EMT, the issuer faces a materially different compliance burden: whitepaper approval by the relevant national competent authority, reserve asset requirements, redemption rights for holders, and — for tokens designated as significant — direct EBA supervision. CASPs distributing third-party LSTs also carry due-diligence obligations: distributing an unclassified token that should carry an ART or EMT designation is itself a compliance failure. For any LST in your product stack, a documented, case-by-case legal classification analysis is not optional — it is the starting point. See our breakdown of token taxonomy under MiCA for the full classification framework.

DORA and AML/TFR: The Regulatory Layers on Top of MiCA Staking Obligations

MiCA is not the only regulatory layer a staking provider must satisfy. Since January 2025, all CASPs — including those offering staking-as-a-service — are subject to the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA). For staking operations specifically, DORA's reach is pointed: validator nodes, staking pools, and the infrastructure used to delegate or unbond assets qualify as critical ICT services. Where a CASP relies on a third-party validator network, that relationship must be governed under DORA's third-party ICT risk framework, including contractual requirements, concentration risk assessments, and ongoing monitoring. Crucially, a slashing event, unbonding failure, or validator downtime that causes material client loss is not merely a product issue — it is a candidate for classification as a major ICT-related incident triggering mandatory reporting to the competent authority. See the full requirements in our DORA compliance guide for CASPs.

On the AML/CFT side, staking rewards distributed to clients constitute crypto-asset transfers for the purposes of the Transfer of Funds Regulation (Regulation (EU) 2023/1113, TFR). This means the EU Travel Rule applies: originator and beneficiary information must travel with the transfer, even when the counterparty is the CASP's own staking infrastructure. Beyond the Travel Rule, every client onboarding must meet the standards set under the current AML directives and the forthcoming Anti-Money Laundering Regulation (Regulation (EU) 2024/1624, AMLR). CASPs must conduct risk-based KYC, screen for sanctions and PEPs, and apply enhanced due diligence where staking volumes or jurisdictional exposure elevates risk. From 2028, the new Anti-Money Laundering Authority (AMLA) will assume direct supervisory responsibility over the largest CASPs operating cross-border in the EU — adding a pan-European enforcement dimension that national-only compliance programmes will not be sufficient to address. Full Travel Rule obligations are covered in our EU Travel Rule and TFR guide.

• Validator infrastructure = critical third-party ICT service under DORA; contractual and monitoring requirements apply.
• Slashing / unbonding failures may trigger DORA major incident reporting obligations.
• Staking reward distributions are TFR-covered transfers; Travel Rule compliance is mandatory.
• KYC/AML onboarding must meet AMLR standards for all staking clients, regardless of reward size.
• AMLA direct supervision of largest cross-border CASPs begins 2028 — compliance programmes must be built for that standard now.

Staking Compliance Checklist: Eight Steps Before You Go Live

Before you accept a single token for staking on behalf of an EU client, every compliance control below must be in place. This is not a best-practice wish list — these are hard regulatory requirements under Regulation (EU) 2023/1114. Work through each step sequentially; later steps depend on earlier ones being locked down.

• Step 1 — Confirm your CASP licence covers custody (Class 2). Staking-as-a-service involves holding client assets, which is custody and administration of crypto-assets on behalf of clients. This is a Class 2 service under Annex IV. Verify your authorisation explicitly lists this service; an execution-only or Class 1 licence is insufficient. See Article 75 and Annex IV, Class 2.
• Step 2 — Recalculate own funds for Class 2. Your minimum own-funds requirement rises to the higher of €125,000 or 25% of projected fixed overheads (the Fixed Overheads Requirement), computed in accordance with Article 67. Confirm the figure before launch, not after the first supervisory review.
• Step 3 — Draft and execute a custody agreement that covers staking duties. The agreement must set out staking mechanics, reward distribution, slashing risk allocation, and liability limits. Generic custody terms do not satisfy the specific disclosure obligations in Article 75(2).
• Step 4 — Implement asset segregation controls — on-chain and off-chain. Client assets must be segregated from firm assets at both the wallet and ledger level. Commingling, even temporarily for validator batching, breaches Article 75(7). Document your technical and operational controls and have them audited before go-live.
• Step 5 — Design and obtain explicit client consent before committing any assets. Article 75(4) requires prior, specific, informed consent. Build a consent flow that explains the staking mechanism, lock-up period, slashing exposure, and reward structure. Blanket T&C acceptance does not meet this standard.
• Step 6 — Assess any liquid staking token (LST) you issue for ART or EMT classification. If your protocol issues an LST that tracks value or claims redemption rights, it may qualify as an asset-referenced token or e-money token under Articles 3, 16, and 43. A separate issuance authorisation may be required — assess this with legal counsel before issuance.
• Step 7 — Map validator infrastructure as a critical ICT third-party provider under DORA. External validator nodes and staking infrastructure providers fall within the scope of Regulation (EU) 2022/2554 (DORA). Complete a DORA-aligned ICT risk assessment, establish contractual requirements, and include validator providers in your concentration risk register.
• Step 8 — Build STOR capability for market-abuse detection. CASPs operating staking platforms must monitor for and report suspicious transactions or orders under Article 92 MiCA. Establish a Suspicious Transaction and Order Report (STOR) workflow — policies, triggers, and a designated reporting function — before accepting client assets.

Each step maps to a named MiCA provision. If any one of them is missing at launch, you are not operating a compliant staking service — you are operating an unlicensed or under-controlled one. Review your full CASP licence requirements and cross-check against the most common MiCA compliance mistakes before going live.

Frequently asked questions

Does offering staking rewards to clients require a MiCA CASP licence?

Yes. The European Commission confirmed in ESMA Q&A 2067 that staking-as-a-service — where an intermediary holds client crypto-assets and stakes them on the client's behalf — is ancillary to custody and administration of crypto-assets on behalf of clients. That service is regulated under MiCA Article 75, and providing it requires authorisation as a CASP with a Class 2 licence (minimum own funds of €125,000 or one quarter of fixed overheads, whichever is higher).

Can a CASP keep some of the staking rewards for itself as a fee?

Yes, but only in a specific way. ESMA's position is that all staking proceeds must be allocated to the client who owns the staked assets. The CASP may contractually agree to retain a portion of those proceeds as a service fee, but it cannot conduct staking activities on its own account using client assets — even with the client's explicit consent. Article 70(1) of MiCA prohibits CASPs from using clients' crypto-assets for their own account.

Who bears liability if client crypto-assets are lost during a staking event such as slashing?

Under Article 75(8) of MiCA, losses of crypto-assets stemming from the provision of staking services — including losses from the underlying staking activity itself — are deemed attributable to the CASP. The CASP will only be excused if it can demonstrate that the loss resulted from an external event beyond its reasonable control. In practice, this means slashing losses are very likely to fall on the CASP, making robust validator due diligence and operational controls essential.

Do bonding and unbonding periods affect a CASP's custody obligations?

Yes. During bonding and unbonding periods, the CASP must still satisfy its Article 70 segregation and record-keeping obligations — it must be able to identify each client's assets at any point in time, even when those assets are locked on-chain. Additionally, because staking may restrict a client's ability to access their assets, the CASP must obtain the client's explicit consent before committing their assets to staking, and must disclose the expected bonding and unbonding timeline upfront.

Is a liquid staking token (LST) such as stETH regulated under MiCA?

It depends on the token's design and economic function. If an LST references a basket of assets or grants redemption rights backed by reserves, it may qualify as an Asset-Referenced Token (ART) under MiCA Title III or an E-Money Token (EMT) under Title IV. Each token requires individual legal assessment. If it qualifies as an ART or EMT, the issuer faces additional obligations including whitepaper approval (by the NCA for ARTs) and, if deemed significant, direct EBA supervision.

Does DORA apply to a CASP's validator infrastructure?

Yes. CASPs have been subject to DORA since January 2025. Validator nodes and staking infrastructure used to deliver the service to clients qualify as critical third-party ICT providers and must be managed under DORA's third-party risk framework, including due diligence, contractual requirements, and monitoring. An unbonding failure or slashing event that disrupts service may also constitute a major ICT-related incident requiring notification to the competent authority.