On paper, building a staking service inside the European Union's fastest-moving crypto-registration hub looks straightforward. In practice, the classification question alone – is this a custody arrangement, a securities intermediation, or a virtual asset service? – can reframe the entire compliance stack. Lithuania's regulator, the Bank of Lithuania, oversees VASP (virtual asset service provider) supervision under the national AML regime while the country's operators now transition toward the CASP authorisation framework established by MiCA (the EU Markets in Crypto-Assets Regulation). A staking service sits at the boundary of both regimes. Getting the classification right before launch is not optional. This guide maps the regulated basis, the application process, the cross-border interactions with tax and banking, and the decision points that determine whether your staking product needs a licence, a registration, or a structural redesign.
What Is a Staking Service in Lithuanian and EU Law?
A staking service, for legal purposes, is an arrangement under which a service provider accepts, pools, or manages a client's proof-of-stake tokens to generate rewards on that client's behalf. The legal classification turns on whether the provider takes custody, exercises discretion over the asset, or promises a return – not on whether the product is marketed as "decentralized." Under the applicable VASP provisions overseen by the Bank of Lithuania, custody and transfer activities involving virtual assets require registration at minimum. Under the MiCA regime, CASP authorisation covers custody and administration of crypto-assets on behalf of clients, which most third-party staking arrangements satisfy. The substance of what the operator actually does with the tokens is the determinative factor.
Mis-classifying a staking product as a purely technical service when it involves custody or discretionary management is one of the most common structural errors we see in inbound Lithuania builds. The Bank of Lithuania has made clear, in its supervisory practice, that economic substance governs. A service that receives tokens, stakes them, and distributes rewards is providing a service on behalf of the client – regardless of what the whitepaper calls it.
The additional classification risk is on the securities side. A staking arrangement that pools client assets, allocates rewards pro-rata, and insulates participants from operational decisions begins to resemble a collective investment scheme under EU financial instruments law. Where that line is crossed, the applicable regime shifts entirely – from the VASP or MiCA track to one governed by fund-authorisation requirements, with materially different timelines and capital expectations.
The Regulatory Regime: Bank of Lithuania, VASP Registration, and the MiCA Transition
Lithuania's crypto supervision sits with the Bank of Lithuania, which has operated one of the EU's most active VASP registration environments since the late 2010s. Historically, the regime allowed relatively fast registration, with AML/KYC program requirements and a fit-and-proper assessment for key personnel. That baseline remains operative while Lithuania transitions its registered VASPs to full MiCA CASP authorisation, a process that ESMA and the European Commission have set in motion across all member states.
For a staking service launched today in Lithuania, the practical path runs through two sequential steps. First, the operator confirms whether its activities require current VASP registration under the existing national AML-anchored rules. Second, it plans for the MiCA CASP authorisation that will govern ongoing operations as the transition period concludes. The Bank of Lithuania is the national competent authority for MiCA purposes in Lithuania, so the dialogue with the regulator is continuous rather than a one-time filing.
The Travel Rule obligation – formally the requirement to pass originator and beneficiary data with virtual-asset transfers, anchored in the FATF Recommendation 15 framework – applies to Lithuanian-registered VASPs on outbound and inbound transfers. A staking service that moves tokens on behalf of clients between wallets it does not fully control must build Travel Rule compliance into its protocol design, not retrofit it. We regularly advise operators who discover this gap after the architecture is locked.
One additional layer: the whitepaper obligation under MiCA applies to issuers of crypto-assets other than ART and EMT categories. If the staking service is also issuing a reward token, that token's classification – utility, ART (asset-referenced token), or EMT (e-money token) – triggers its own disclosure and authorisation track. The two compliance streams run in parallel and must be scoped simultaneously.
Contact OBOLUS at info@oboluslaw.com to scope your classification and registration path before you commit to a structure. The specific facts of your custody model, reward mechanism, and user base will change the analysis meaningfully.Step by Step: How Does a Staking Business Register or Apply in Lithuania?
Registration and authorisation for a staking service in Lithuania follow a defined sequence, with the Bank of Lithuania as the gating authority at each stage.
Step 1 – Legal entity establishment. The operator establishes a Lithuanian private limited liability company (UAB) or equivalent. Registered office, a local director with genuine responsibilities, and a substance requirement are assessed at the outset. A shell structure with no real decision-making in Lithuania will not satisfy the Bank of Lithuania's substance expectations under MiCA. This step typically takes a matter of weeks, depending on notarial and registration queues.
Step 2 – AML program documentation. The operator prepares an AML/KYC program aligned with the Lithuanian AML Law and FATF standards. For a staking service, this program must address wallet attribution, the Travel Rule protocol for transfers, monitoring of staking reward flows, and the customer-due-diligence model for on-boarding stakers. The program is reviewed by the Bank of Lithuania as part of any registration or authorisation dossier.
Step 3 – VASP registration (current regime) or CASP authorisation application (MiCA). For operators launching under the current transition window, registration with the Bank of Lithuania under the applicable AML-anchored VASP provisions is the immediate step. The dossier includes the AML program, a description of activities (covering custody, transfer, and any exchange activities), fit-and-proper documentation for key personnel and beneficial owners, and a business plan. Timeline under the registration track varies by dossier quality; authorisation under MiCA will carry a defined regulatory review period aligned to the CASP provisions.
Step 4 – Technology and smart-contract documentation. The Bank of Lithuania, consistent with ESMA guidance under MiCA, expects technical documentation of the staking mechanism. This includes the smart contract architecture, the custody model (hot/cold wallet split, third-party custodian arrangements), the reward distribution logic, and any oracle or data-feed dependency for reward calculations. In our cross-border practice, operators who submit this documentation proactively see materially fewer follow-up queries from the regulator.
Step 5 – Ongoing compliance and MiCA transition planning. Post-registration, the operator is under continuous supervision. The MiCA transition timeline means that existing registrations will require conversion to full CASP authorisation within the period set by the applicable transitional provisions. Planning the gap analysis – what the current registration covers versus what CASP authorisation will require – should begin at incorporation, not at the deadline.
How Does Smart Contract Architecture Affect Your Legal Exposure?
The smart contract layer is not legally neutral, and Lithuanian regulators are not the only ones watching it. A staking service that operates through an autonomous smart contract on a public chain has a different liability profile from one that routes tokens through an operator-controlled contract. The distinction matters for two reasons: custody classification and liability attribution.
Under the applicable VASP provisions and the MiCA CASP framework, custody is assessed functionally – if the operator controls the private keys, or controls the smart contract that controls the keys, that is custody regardless of what the contract code says about decentralization. Structuring around that classification by inserting a nominally autonomous contract layer does not eliminate the regulatory obligation; it may instead create a disclosure gap that the Bank of Lithuania will flag in review.
On liability, the question of who is responsible when a smart contract fails to execute as expected is not resolved by the code itself. In a third-party staking service context, the operator is the contracting party with the user. If the contract misbehaves – whether through a bug, an oracle failure, or a governance manipulation – the operator faces claims under the applicable consumer and contract law, not the blockchain protocol. In our practice, we have seen operators who assumed that publishing code to a public chain transferred legal risk to the network. It does not.
Tokenization of staking positions – issuing a liquid receipt token to represent a staker's claim – adds a further classification layer. If that receipt token confers rights to rewards and is tradeable, it may qualify as a financial instrument or a crypto-asset requiring its own whitepaper under MiCA. The DAO structure question is directly relevant here: if governance of the staking protocol is delegated to a DAO, the legal wrapper of that DAO and the allocation of liability within it must be documented before the Bank of Lithuania will accept a clean registration dossier.
In a recent structuring matter, a DeFi protocol operator building a staking module sought guidance on whether its receipt-token mechanism crossed the ART threshold under MiCA. We assessed the rights structure against the substance of the stabilization mechanism and the redemption rights, concluded that the token did not satisfy the ART definition, and documented the analysis for regulatory presentation. The operator filed its registration dossier with the Bank of Lithuania with the classification analysis as a supporting exhibit. The question was resolved before launch rather than in a supervisory inquiry.
Cross-Border Interaction: Tax, Banking, and the Multi-Jurisdiction Reality
Operating a staking service from Lithuania does not confine the legal exposure to Lithuania. Where the users are, where the banking is, and where the token was issued all create parallel regulatory and tax obligations that must be mapped before launch.
On the tax side, Lithuania has a corporate income tax regime applicable to UAB entities. Staking reward income received by the operator requires characterization – whether it is ordinary trading income, financial intermediation income, or service fee income affects both the Lithuanian tax rate and the VAT position. The EU VAT treatment of crypto-asset services is not uniform; the Bank of Lithuania's supervisory practice does not resolve the VAT question, which runs through the Lithuanian State Tax Inspectorate and ultimately through CJEU jurisprudence on financial services exemptions. We work with allied counsel in the relevant tax jurisdiction where a cross-border VAT analysis is required.
Banking for Lithuanian-registered crypto businesses has been a persistent operational bottleneck. Traditional Lithuanian banks have applied cautious policies toward crypto-business clients. Operators routinely use electronic money institutions (EMIs) domiciled in Lithuania or elsewhere in the EU, combined with correspondent banking relationships, to build a workable treasury stack. The banking structure is a first-priority concern – not a post-licensing administrative detail. A staking business that cannot open an operating account cannot receive staking fees, pay staff, or manage reward distribution at scale.
For users domiciled outside the EU – in the US, UK, or Asia – the staking service must assess whether offering the product into those jurisdictions triggers a local registration obligation. The SEC and CFTC have both issued guidance and enforcement actions relevant to staking products offered to US persons. The FCA's financial promotion rules apply to crypto-asset marketing directed at UK users. MAS in Singapore takes a territorial approach to its Payment Services Act regime. A Lithuanian registration under MiCA does not passport regulatory permission into those jurisdictions. Operators we advise regularly build a jurisdiction-by-jurisdiction access matrix into their terms of service and KYC gating before launch.
If your staking service will be accessible to users across multiple jurisdictions, write to OBOLUS at info@oboluslaw.com. A prior application that stalled often reflects a structural issue – entity substance, banking, or user-base scope – that a second read can surface and resolve.
Decision Matrix: Which Operator Profile Suits Which Path?
Not every staking product has the same regulatory footprint, and the compliance path should reflect the operator's actual model rather than a generic template.
Profile A – Institutional staking-as-a-service. An operator offering staking to institutional clients (exchanges, funds, custodians) on a white-label basis, retaining custody of keys and distributing rewards via an audited smart contract. This profile requires VASP registration now and CASP authorisation under the custody and administration activity class as MiCA transitions. AML/KYC obligations are calibrated to institutional counterparty due diligence. The timeline to operational registration is a matter of weeks under the current regime, subject to dossier quality; CASP authorisation will take longer and requires more detailed regulatory capital documentation. The key risk is the securities classification of any reward token issued as part of the service.
Profile B – Retail staking platform. An operator pooling retail user tokens into a validator infrastructure and distributing proportional rewards via a user-facing application. This profile has the highest regulatory surface: custody obligations, consumer disclosure requirements under MiCA's whitepaper rules, financial promotion compliance for any marketing, and the heightened AML obligations that come with retail on-boarding. The collective investment scheme risk is live for this profile if the reward mechanism is presented as an investment return. Timeline to authorisation under MiCA is longer and requires detailed product documentation. Banking is the first constraint to resolve.
Profile C – Protocol-level staking with no user custody. A protocol that provides staking infrastructure to validators without taking custody of user assets – where users delegate directly to a validator via their own wallets and the operator earns a protocol fee. This profile may sit outside the VASP/CASP custody perimeter, but it requires careful documentation of the fee mechanism, the smart-contract control structure, and the reward flow to confirm that no custody is being taken at any point. The Bank of Lithuania expects that documentation to be made available on request. This is the most defensible profile from a regulatory-perimeter standpoint, but the documentation burden is non-trivial.
Common Mistake: A Utility Label Does Not Settle Classification
A widespread assumption among staking service operators is that labeling a reward token as a "utility token" in the whitepaper resolves the securities or ART classification question. It does not. The Bank of Lithuania, ESMA, and every major EU national competent authority assess token classification on the basis of the economic rights the token confers, the stabilization mechanism (if any), and the redemption expectations of the holder – not on the marketing label the issuer chooses.
Under MiCA, a token that tracks the value of a fiat currency or a basket of assets, or that offers a redemption right backed by a reserve, is an ART or EMT regardless of what it is called. A token that confers a right to participate in the financial return of an enterprise may be a financial instrument under the applicable EU financial instruments regime rather than a crypto-asset under MiCA at all. The label is the starting point of the regulator's inquiry, not the end of it.
We assess classification against the substance of rights, not the marketing label. That analysis is the first step of any staking-service engagement. Operators who skip it and proceed to registration on the assumption that their token is clearly a utility asset routinely encounter supervisory correspondence from the Bank of Lithuania requesting reclassification evidence before the registration is processed.
Related practices at OBOLUS
- DeFi, tokenization and smart-contract law for digital-asset businesses – legal framework for DeFi protocols, token issuances and smart-contract structuring
- Oracle and data feed liability for established operators – liability mapping for operators dependent on on-chain data feeds and oracles
- Exchange listing legal counsel under heightened scrutiny – token classification and listing diligence in a tightened regulatory environment
FAQ
Can a DeFi protocol be regulated?
Yes. Regulators, including the Bank of Lithuania and ESMA under MiCA, assess DeFi protocols on the basis of whether a person or entity exercises control over the protocol's functions or takes custody of user assets. If such control exists, the applicable VASP or CASP regime applies regardless of how the protocol is labeled. Pure, non-custodial, autonomously operating protocols present a lower regulatory surface but are not automatically outside supervision – the facts of control and custody determine the answer.
What legal wrapper suits a DAO?
No single legal wrapper suits every DAO. Common approaches include a Marshall Islands DAO LLC, a Cayman Islands foundation company, a Swiss association, or a BVI company acting as a protocol administrator. The choice turns on where governance is exercised, where contributors are located, and whether the DAO's activities require a licensed entity. For a staking-protocol DAO with EU-facing operations, the legal wrapper must be compatible with the Bank of Lithuania's substance requirements for any regulated activities the DAO conducts or administers.
Who is liable when a smart contract fails?
Liability when a smart contract fails turns on the relationship between the operator, the user, and the contract. Where an operator deploys and maintains a staking contract, offers it to users under terms of service, and earns a fee from its operation, the operator is the counterparty and bears liability under the applicable contract and consumer-protection law. The autonomous nature of the code does not eliminate that liability. Liability can be allocated contractually, and smart-contract audit documentation is relevant to any defense of reasonable care, but the operator cannot contract out of mandatory consumer protections under EU law.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across more than seventy jurisdictions, on disputes and on-chain asset recovery across more than twenty-five forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We assess classification against the substance of rights, not the marketing label – that discipline is the foundation of every staking-service engagement we take on. We advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel – specialising in smart-contract architecture classification, DAO structuring and staking-service regulatory analysis across EU and cross-border jurisdictions.
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.