For a regulated entity – an exchange, a custodian, a fund, or a payment institution – adding a staking service to the product stack is rarely as clean as the engineering roadmap suggests. The legal question is not simply whether staking is permissible; it is whether staking, in the specific form proposed, constitutes a regulated activity, creates a securities or collective-investment exposure, and can be offered across the intended user base without triggering separate licensing obligations in each target market. Getting that analysis wrong converts a revenue line into a regulatory liability before a single reward is distributed.
Under regimes that have moved fastest on digital-asset oversight – MiCA in the European Union, the VARA (Virtual Assets Regulatory Authority) regime in Dubai, and the MAS Payment Services Act framework in Singapore – staking is neither uniformly permitted as an ancillary activity nor uniformly prohibited. Classification turns on the structure of the staking arrangement: who holds the keys, how rewards accrue, whether the operator pools assets, and whether the user retains any redemption right. Each variable shifts the regulatory answer. This page maps that analysis for the operator who already holds or is seeking a digital-asset licence and needs to understand how a staking service sits within that perimeter.
Why Staking Classification Determines Everything Downstream
Staking is not a single legal concept. It describes a technical mechanism – validating or attesting to blocks on a proof-of-stake network in exchange for protocol rewards – but the legal character of what a regulated entity offers depends entirely on how that mechanism is packaged for the end user.
A regulated entity that holds customer assets and delegates them to a validator on behalf of the customer is doing something structurally different from one that pools assets, issues a derivative receipt, and pays a blended yield. The first arrangement may sit within existing custody permissions. The second may constitute collective investment management, deposit-taking, or – under MiCA's e-money token or asset-referenced token provisions – a service requiring separate authorisation. In our practice, the most consistent source of regulatory difficulty at this stage is the assumption that a single staking product has a single legal character. It rarely does.
The cross-border dimension compounds the point. A regulated custodian operating under an ADGM/FSRA authorisation in Abu Dhabi may serve users in the EU, Singapore, and the United Kingdom through the same interface. Each of those regimes applies its own staking-classification logic. The product that fits neatly within the FSRA's recognised-virtual-asset activity scope may simultaneously constitute an unregistered collective investment scheme under FCA perimeter guidance or trigger MAS licensing obligations for a digital payment token service. Operators we advise routinely discover this gap only when a regulator raises it – by which point the remediation path is both more expensive and more time-consuming than early analysis would have been.
For a scoped classification memo on your proposed staking structure, contact OBOLUS at info@oboluslaw.com. The analysis above describes the standard path. Your facts – the entity, the user base, the key-holding arrangement – change the conclusion materially. Map your options.
What Falls Inside the Regulated Perimeter for Staking Services?
The regulated perimeter for a staking service offered by a licensed entity depends on two axes: the activity performed and the asset involved. Most flagship regimes regulate activity, not the underlying token, so the same technical action can cross or stay within the perimeter depending on how the service is structured.
Under MiCA, a CASP (Crypto-Asset Service Provider) authorisation covers defined activities – custody, operation of a trading platform, exchange, transfer services, placement, advice, and portfolio management. Staking does not appear as a defined CASP activity in its own right. That silence is significant. It means a CASP offering staking must demonstrate either that the staking service falls within an already-authorised activity (typically custody, with delegation as an ancillary function) or that it does not constitute a regulated activity at all. Where the operator pools assets and pays a yield that is not purely the pass-through of protocol rewards, the closer analogy is portfolio management or collective investment – both of which carry separate authorisation requirements.
Under the VARA regime, activity-based licences cover custody and management services. Staking offered as part of a custody service is generally within scope of that licence, subject to VARA's applicable rulebook requirements. Where staking is offered as a standalone yield product – particularly one that quotes a fixed or indicative return – the closer analysis is whether the activity falls within VARA's management and investment services category, which requires a separate licence category.
The FCA's perimeter in the United Kingdom is currently anchored to the Money Laundering Regulations registration for cryptoasset businesses, with a broader financial-promotion regime layered over the top. A regulated firm offering staking to UK users must ensure the promotion of the staking service complies with FCA financial-promotion rules – a requirement that applies regardless of where the entity is licensed. The substantive activity question – whether the staking service constitutes a collective investment scheme or a specified investment activity – depends on the specific structure and is analysed case by case.
How Does a Staking Service Interact With an Existing Digital-Asset Licence?
A regulated entity considering staking should start by reading the exact scope of its existing authorisation before designing the product. The interaction between the staking service and the existing licence creates three possible outcomes: the staking service is within scope as an ancillary activity, it requires a variation or extension of the existing authorisation, or it is outside the licence scope entirely and requires a fresh application.
In our cross-border practice, the variation-or-extension path is the most common and the least anticipated. An exchange licensed to operate a trading platform is typically not authorised to hold customer assets at rest on a validator. Adding staking without a custody permission – or without the regulator's acknowledgment that the staking is incidental to an existing permission – creates an unlicensed activity risk that sits, quietly, on the entity's regulatory record until it is discovered. The remediation is rarely a simple notification; it is more often a formal variation application, which restarts a regulatory clock.
The SFC in Hong Kong applies a similar logic under the VATP licensing regime. A platform authorised to operate a virtual-asset trading platform is not automatically authorised to offer staking services that involve the pooling of client assets. The SFC has signalled, in its published guidance on the VATP framework, that ancillary services must be assessed against the applicable licensing conditions rather than assumed to be covered. Operators we advise in this market treat that as a hard pre-launch gate: no staking product goes live without written confirmation from the SFC or, at minimum, a formal legal opinion that the service is within the existing licence scope.
For entities in the AIFC under AFSA supervision in Kazakhstan, the common-law jurisdiction provides a relatively clear analytical path: the licence scope is defined by activity categories in the applicable regulations, and the firm's analysis of whether staking falls within an authorised category is documented and retained. AFSA's approach to novel digital-asset products has, in our experience, been responsive to structured pre-application dialogue – a path worth using before committing engineering resource to a product that may require a fresh licence.
Token Classification and the Staking Yield: The Security Exposure
The most serious legal exposure in a staking service is not the staking itself but the characterisation of the yield. A protocol reward that is simply the pass-through of block rewards on a proof-of-stake network looks different, legally, from a yield that is pooled, blended, and paid at a rate that is not directly traceable to specific validator activity. The second structure invites a securities analysis.
Under US federal law, the SEC's application of the Howey test to staking arrangements is active. The SEC has taken enforcement positions against exchange-operated staking programs on the basis that they constitute investment contracts – the customer pools funds with the operator, who performs the effort of validating, and the customer expects a return. The legal consequence is that the staking service may require registration as a securities offering. That analysis applies to any entity with US users, regardless of where the entity is licensed.
A common assumption in this space is that labelling the staking reward a "protocol-native reward" rather than a "yield" settles the classification. It does not. Regulators in the major hubs increasingly expect substance-over-form analysis: what rights does the user have, who controls the delegation, how is the reward calculated, and what happens to the user's assets if the operator becomes insolvent? Those questions determine classification. A label on a whitepaper does not. In our practice, we assess classification against the structure of rights conferred on the user and the obligations assumed by the operator – not the marketing description.
In the EU, a staking arrangement that results in the operator issuing a token representing the user's staked position – sometimes called a liquid staking token or LST – may constitute the issuance of an asset-referenced token (ART) under MiCA, depending on the reference value mechanism. ART issuance carries its own authorisation requirement and reserve obligations. Operators building liquid staking services for the EU market without this analysis in place are creating a structural problem that will surface at the worst possible moment: when the service is already live and the user base is already exposed.
AML Obligations and the Travel Rule in Staking Contexts
A regulated entity adding staking services does not escape its existing AML/CFT obligations – it extends them. The Travel Rule (the obligation to pass originator and beneficiary data with a virtual-asset transfer, based on FATF Recommendation 15) applies to transfers of virtual assets to and from the staking infrastructure, to the extent those transfers meet the applicable threshold in each jurisdiction.
In practice, this means the entity must determine whether the movement of user assets to a validator – and the return of those assets plus rewards – constitutes a "transfer" for Travel Rule purposes. Most FATF-aligned jurisdictions treat this as a transfer when the user's assets leave the entity's custody and are sent to an external validator address. The consequence is that Travel Rule compliance, including counterparty VASP identification, applies to each such movement above the applicable threshold.
This is an operational design issue as much as a legal one. The staking infrastructure must be built to capture and transmit the required originator and beneficiary data, or the entity is in Travel Rule breach from day one of the product launch. We have seen regulated firms launch staking products without this review and subsequently face remediation periods of several months to bring the data architecture into compliance. The regulator's expectation, consistently expressed across the major hubs, is that the obligation is addressed in product design, not retrofitted after launch.
Structuring a Cross-Border Staking Service: Decision Matrix
For a regulated entity serving users across multiple jurisdictions, the staking service structure is typically not a single legal choice but a stack of them: where the staking entity sits, where users are located, where the validator infrastructure is operated, and where customer assets are held. Each layer has a different regulatory answer.
Three profiles illustrate the decision logic:
Profile A – Custodian-led delegation: A custodian licensed under VARA or the FSRA holds user assets and delegates to an external validator as an ancillary custody service. The user retains beneficial ownership; rewards are passed through directly. This structure is the most conservative. It fits within most custody licence scopes without requiring a variation. The key risk is validator slashing – the user's principal may be reduced if the validator misbehaves. The custodian's liability exposure for slashing losses, and whether the custodian is required to indemnify the user, must be addressed explicitly in the user agreement.
Profile B – Pooled staking with synthetic receipt: An exchange pools user assets, delegates to a managed validator set, and issues a liquid staking token representing the user's position. This structure requires analysis of: (a) whether the pooling constitutes collective investment management; (b) whether the LST constitutes an ART under MiCA; (c) what securities law consequences follow in each user jurisdiction. The timeline to reach a legally clean launch from a standing start is typically a matter of months, not weeks, because the number of regulatory questions to resolve is materially larger. For EU-facing operators, MiCA's whitepaper and authorisation requirements may apply before the product can be publicly offered.
Profile C – Institutional staking for fund clients: An entity acting as fund administrator or custodian for a digital-asset fund offers staking as part of the fund's investment strategy. The applicable regime is primarily the fund-domicile law (Cayman, BVI, or a regulated EU fund structure) combined with the custodian's licence conditions. The fund documents must authorise staking; the fund's offering memorandum must disclose staking risks; and the custodian must confirm that staking is within the scope of its custodial mandate. In our experience, these three confirmations are rarely all in place at the moment the fund manager wants to activate staking – creating a pre-launch legal sprint that could have been avoided with earlier structuring.
Common Mistakes Regulated Entities Make When Launching Staking
Regulated entities make several predictable legal errors when adding staking to their product range. Identifying them early is cheaper than correcting them after launch.
The most frequent error is treating the staking product as an engineering decision rather than a regulatory one. The product team builds the integration, the compliance team reviews it after the fact, and the legal analysis is compressed into a short sign-off process that does not adequately address classification, licence scope, or the cross-border user base. This is how licence scope problems get embedded into live products.
The second error is failing to update user agreements and risk disclosures before launch. Staking introduces new risk categories – validator slashing, unbonding periods that lock user assets, smart contract failure – that are not covered by a standard custody or exchange user agreement. A regulated entity that has not updated its terms before offering staking is exposed both to regulatory findings about inadequate disclosure and to civil liability claims from users who suffer a loss that was never disclosed.
The third error is the securities analysis gap described above. In our cross-border practice, the US nexus question is the one most consistently overlooked by non-US operators. The presence of any US user – even a small number, even users who were not specifically targeted – is sufficient to trigger a securities law analysis. An entity that has not documented and confirmed the absence of a US securities exposure, or has not structured the product to exclude US users, is carrying a material latent risk.
A practical illustration: in a recent structuring matter, a licensed custodian in a Gulf free zone sought to launch a pooled staking product for its retail and institutional user base. The product had been in development for several months before legal review began. Analysis identified that the pooled structure would constitute collective investment management under the applicable regime, that three of the target jurisdictions had separate securities-law concerns, and that the user agreement did not address slashing at all. The product was restructured to a custodian-led delegation model, the user agreement was redrafted, and two of the three cross-border jurisdictions were addressed through enhanced onboarding controls. The launch proceeded – but on a timeline measured in additional months, not the original weeks, and at a significantly higher legal cost than an earlier engagement would have required.
If your staking product is already in development, the time to address these questions is now, not at the pre-launch review. Contact OBOLUS at info@oboluslaw.com for a structured pre-launch assessment. If a prior application stalled or a regulator raised a concern, a second read can surface the structural reason and the route forward. Map your options.
Self-Assessment: Is Your Staking Service Legally Ready?
Before a regulated entity launches a staking service, the following questions should have documented answers. If any of them remain open at the point of launch, the risk is being carried rather than managed.
First: has the entity confirmed, in a formal legal opinion or a documented analysis by qualified counsel, that the staking service falls within the scope of its existing authorisation? If not, what variation is required and has it been applied for?
Second: has the entity conducted a token-classification analysis for the jurisdiction of each material user group? Does that analysis address the US securities question specifically?
Third: if the staking service involves a liquid staking token or any form of synthetic receipt, has the ART/EMT analysis under MiCA been completed for EU-facing users?
Fourth: has the entity reviewed its Travel Rule obligations in the context of the staking infrastructure? Is the technical architecture capable of capturing and transmitting the required data for each movement of user assets to or from the validator?
Fifth: do the user agreement and risk disclosures specifically address slashing risk, unbonding periods, smart contract risk, and the entity's liability position in each scenario?
Sixth: for pooled staking structures, has the entity confirmed that the pooling does not constitute collective investment management under the law of each relevant jurisdiction?
If the answer to any of these questions is "not yet," the staking service is not legally ready to launch.
Related at OBOLUS
- DeFi, Tokenization and Smart-Contract Law – the full practice-area guide for digital-asset businesses operating across regulated markets.
- Oracle and Data-Feed Liability in Nigeria – liability analysis for smart-contract data dependencies in an emerging-market jurisdiction.
- Staking Service Legal Framework for Early-Stage Founders – the parallel analysis for pre-licence operators building staking infrastructure from inception.
FAQ
Can a DeFi protocol be regulated?
A DeFi protocol can fall within a regulatory perimeter, but the threshold question is whether there is a sufficiently identifiable legal person responsible for the protocol's operation. Regulators in the major hubs – including ESMA under MiCA and the FCA in the UK – have signalled that the absence of a legal entity does not automatically place a protocol outside the regulated perimeter if there are identifiable persons exercising control. Governance token holders and founding teams can, depending on the facts, be treated as responsible parties for regulatory and liability purposes.
What legal wrapper suits a DAO?
No single legal wrapper is universally correct for a DAO (decentralized autonomous organization). The choice among a Cayman foundation company, a BVI company, a Marshall Islands LLC, or a Wyoming DAO LLC depends on the DAO's activities, its member profile, its tax position, and the jurisdictions where it operates or has users. A DAO conducting regulated activities – staking, lending, asset management – requires a wrapper that is capable of holding the relevant licence. The legal and operational consequences of leaving a DAO unwrapped include unlimited member liability in many jurisdictions.
Who is liable when a smart contract fails?
Liability for a smart-contract failure turns on the applicable law, the contractual relationship between the deployer and the user, and the nature of the failure. A developer who deploys a contract with a known or discoverable vulnerability may face negligence claims. A regulated entity that relies on a third-party smart contract as part of its licensed service carries the compliance risk for failures in that contract, regardless of whether the entity wrote the code. User agreements that purport to exclude all smart-contract liability are not invariably effective, particularly in consumer-facing contexts under EU or UK law.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We assess token and service classification against the substance of rights conferred – not the label on a whitepaper – and we advise across the full cross-border stack that a regulated entity operating a staking service will encounter. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Roman Levitt, Technology and DeFi Counsel – specialist in smart-contract risk, DeFi regulatory perimeters, and the cross-border legal structuring of staking and tokenization services for regulated digital-asset businesses.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.