On paper, a DeFi protocol operating out of Lithuania looks straightforward. The jurisdiction has a well-established virtual asset service provider (VASP) registration regime under the Bank of Lithuania, a favorable corporate-tax environment, and direct access to EU passporting as MiCA matures. In practice, the legal structuring question is considerably more precise: which activities the protocol performs, how governance rights are distributed, and how token flows are characterized each carry independent regulatory consequences – and misclassifying any one of them can convert a product launch into an unregistered securities offering. This guide sets out the sequential structuring steps a DeFi protocol must work through to operate legally in Lithuania, with the cross-border tax and banking interactions that every protocol builder encounters.
What is the regulated perimeter for DeFi in Lithuania?
The regulated perimeter for a DeFi protocol in Lithuania turns on function, not form. If the protocol facilitates exchange, custody, transfer, or management of virtual assets – even autonomously through smart contracts – the Bank of Lithuania's VASP supervision framework may capture it. The transition to MiCA (the EU Markets in Crypto-Assets Regulation), administered through ESMA and the Bank of Lithuania as national competent authority, tightens this further: activities that previously sat in a grey zone now map to defined CASP (crypto-asset service provider) categories with authorisation obligations.
The first analytical question is always: does a human intermediary perform the regulated activity, or does the smart contract itself? Regulators increasingly look through the automation. Where a protocol team deploys, upgrades, or profits from smart-contract infrastructure, the team – and the legal entity behind it – bears regulatory exposure. In our practice, we see founding teams regularly underestimate this attribution risk.
Lithuania's VASP regime historically offered a lighter-touch entry point into the EU. That advantage persists for the interim period, but the supervisory posture of the Bank of Lithuania has tightened materially. Operators who structured under the prior regime now face the question of whether their activities require a CASP authorisation upgrade or a new filing under MiCA's whitepaper obligation. The answer depends on activity scope – and it is not uniform across protocol types.
A common assumption is that a utility label on a whitepaper settles the legal classification. It does not. Under MiCA and under the Bank of Lithuania's supervisory approach, classification follows the substance of rights conferred – governance entitlements, revenue-sharing mechanics, redemption features – not the marketing descriptor. We assess classification against that substance, and the analysis frequently produces a different answer than the issuer expects.
CTA #1 — For a team meeting this question at the structure-design stage: The classification decision must be made before the token is deployed, not after the first user complaint. The entity, the activity, and the token each require separate analysis. Map your options with OBOLUS.
How should the legal entity be selected for a DeFi protocol in Lithuania?
Entity selection for a DeFi protocol is a multi-variable decision that balances regulatory access, liability containment, governance formalism, and tax efficiency. A Lithuanian private limited company (UAB) is the most common vehicle for a VASP or MiCA-candidate protocol. It provides legal personality, limited liability, and a direct relationship with the Bank of Lithuania for regulatory filings. It also serves as the contracting entity for banking, auditors, and institutional counterparties.
For protocols with significant on-chain governance – what practitioners informally call a DAO structure (decentralized autonomous organization) – a standalone UAB may be insufficient. A DAO without a legal wrapper has no legal personality. It cannot sign contracts, hold assets, or respond to regulatory correspondence. The standard resolution is to pair on-chain governance with an off-chain legal entity: the UAB in Lithuania anchors the regulated activities, while governance token holders retain a defined role through the corporate structure – typically as members of a governing board or through a foundation construct in another jurisdiction.
The cross-border dimension matters here. A DeFi team with developers in multiple countries, investors in the US, and users globally cannot treat Lithuania as an island. The UAB sits within a structure that may also include a Cayman foundation (for token governance), a BVI holding company, or a Swiss association depending on the investor base and where liquidity events are expected. We regularly advise on this multi-entity stack and the interaction between Lithuanian VASP obligations and the regulatory expectations of the other layers.
One structural pattern worth flagging: protocols that issue tokens to contributors outside the EU must assess whether those tokens constitute securities under the law of each recipient's jurisdiction. A Lithuanian UAB does not immunize a token offering from US securities analysis or Singapore MAS scrutiny. The entity is the foundation, not the limit, of the compliance perimeter.
Step 1 – Token classification: how is it done correctly?
Token classification is the most consequential single step in DeFi protocol structuring, and errors here compound through every subsequent filing. The correct method is a substance analysis against the applicable regime – not a label-and-publish approach.
Under MiCA, tokens fall into three primary categories: asset-referenced tokens (ARTs), e-money tokens (EMTs), and "other" crypto-assets. A DeFi governance token that confers voting rights and a share of protocol fees may resist easy placement in any single MiCA bucket – but it may simultaneously exhibit characteristics that attract securities-law analysis under the financial instruments framework applicable in Lithuania and across the EU. The two analyses are independent and must both be completed.
The classification memo should document: (a) the rights conferred on holders at launch and through the governance structure; (b) the economic exposure of holders to a common enterprise or to a specific issuer; (c) the technical mechanics of issuance, transfer, and redemption; and (d) any marketing materials that could inform a regulator's or court's view of investor expectations. This memo becomes a live document – token functionality changes with each protocol upgrade, and the classification must track those changes.
In our cross-border practice, we see the utility/security boundary litigated in multiple forums simultaneously. A Lithuanian regulator may reach one conclusion; the US SEC or CFTC may reach another. The structuring memo must anticipate both and provide a defensible position in each jurisdiction where the token is distributed or traded.
Step 2 – VASP registration and MiCA authorisation: what is the process?
The Bank of Lithuania administers both the legacy VASP registration process and the transition to MiCA CASP authorisation. For a DeFi protocol performing regulated activities, engagement with this process is not optional. The question is which pathway applies and when.
Under the legacy regime, VASP registration required AML/CFT compliance documentation, a fit-and-proper assessment of beneficial owners and directors, and a set of internal governance policies. Timelines and capital requirements for both the legacy regime and the full MiCA CASP authorisation are subject to current regulatory guidance and should be confirmed against the latest Bank of Lithuania and ESMA publications at the time of filing – we do not state these figures as fixed numbers because they vary by activity category and are updated as implementation progresses.
Under MiCA, the CASP authorisation process is more detailed. It requires a whitepaper approved and published in accordance with MiCA requirements, a business plan demonstrating ongoing capital adequacy, compliance with conduct of business rules, and – critically for DeFi – an analysis of whether the protocol itself constitutes a CASP or whether the issuing entity does. The passporting benefit of MiCA CASP authorisation means a Lithuanian authorisation carries across all EU and EEA member states, which is the primary regulatory advantage of the Lithuanian entry point.
For protocols that fall outside the CASP perimeter – because the activity is genuinely decentralized with no identifiable intermediary – MiCA still imposes a whitepaper obligation on the entity that offers tokens to the public in the EU. That obligation is not equivalent to CASP authorisation, but it is not trivial. It requires issuer disclosure, right-of-withdrawal mechanics, and liability exposure for misleading statements.
Step 3 – AML compliance and the Travel Rule: what does a DeFi protocol owe?
AML/CFT obligations for a DeFi protocol in Lithuania derive from both the national AML framework aligned to FATF recommendations and, under MiCA's transition, from EU-level requirements. The Travel Rule (the obligation to pass originator and beneficiary identification data alongside a virtual-asset transfer) is the most operationally demanding element.
For a protocol whose smart contracts intermediate transfers between user wallets, the Travel Rule question is genuinely complex. FATF's guidance on virtual assets, updated under Recommendation 15, makes clear that a VASP obligation can attach to entities that "conduct, enable, or facilitate" virtual-asset transfers – even where those transfers are technically peer-to-peer at the chain level. A DeFi team that controls the front-end interface, the deployment keys, or the fee-extraction mechanism is exposed to this analysis.
Practical compliance means at minimum: a documented assessment of whether the protocol is a VASP under Lithuanian and EU definitions; if yes, a Travel Rule solution (one of the established interoperability protocols operating in the market); KYC/AML procedures for any user-facing interface; and a sanctions-screening process. Operators we advise routinely underestimate the cost of retroactively implementing Travel Rule compliance after a supervisory enquiry – building it into the initial architecture is substantially more efficient.
Step 4 – Smart-contract legal review: what does counsel actually check?
A smart-contract legal review is distinct from a security audit. A security audit checks code for exploits. A legal review checks the code for legal consequences – and the two documents serve different purposes for different audiences.
Legal review of smart contracts for a DeFi protocol in Lithuania covers: (a) whether the contract's operations constitute regulated activities; (b) whether the contract terms, interpreted under Lithuanian or EU law, are enforceable as contractual terms or are void for uncertainty; (c) whether upgrade or governance mechanisms (multisig keys, timelocks, DAO votes) create a control relationship that triggers regulatory attribution; and (d) whether the contract's interaction with external oracles, bridges, or liquidity pools generates additional regulatory exposure.
The cross-border dimension here is acute. A smart contract that settles in USDC through a Circle-issued stablecoin deploys into a technical environment that crosses multiple jurisdictions simultaneously. Circle holds contract-level freeze authority over USDC – this is an operational fact that affects both the risk profile of the protocol and the regulatory analysis. Structuring counsel must account for it.
In a recent engagement, a DeFi team preparing for a Lithuanian VASP registration discovered, through legal review, that their upgrade proxy created a unilateral administrative control point that a regulator would characterize as a centralized intermediary function. Remediation before the filing – redesigning the upgrade mechanism to require a governance vote with a timelock – avoided what would have been a classification problem at the authorisation stage.
Step 5 – Tax and banking: what cross-border interactions must be planned?
Tax and banking are the two friction points that determine whether a Lithuanian DeFi structure is operationally viable, not merely legally compliant.
On the tax side, Lithuania offers a competitive corporate income tax rate and has a developing administrative practice on the treatment of token issuances, staking rewards, and liquidity provision income. However, the tax characterization of DeFi-specific transactions – protocol fees received by the UAB, token distributions to contributors, conversion events – must be confirmed with Lithuanian tax counsel because the written guidance from the tax authority does not yet cover all DeFi scenarios. Where the corporate group spans multiple jurisdictions, transfer pricing between the Lithuanian UAB and holding-layer entities requires a documented policy. Operators we advise who skip the transfer pricing step regularly encounter banking problems when correspondent banks flag intra-group flows as unexplained.
On the banking side, Lithuania's fintech-friendly banking sector has attracted a number of crypto-oriented EMIs (e-money institutions) and banks. However, banking access for DeFi protocols is not guaranteed. Banks apply their own AML/risk policies to protocol clients, and a protocol that cannot demonstrate clean KYC coverage of its user base, a coherent AML policy, and a regulated status (or a documented basis for not being regulated) will face account rejections. This is not a Lithuanian-specific problem – it is a global pattern. Where Lithuanian banking is unavailable or insufficient, allied counsel in the relevant jurisdiction can assist with alternative banking strategies in other EU or offshore banking centers.
CTA #2 — For teams whose prior application stalled or whose account was closed: A structural re-read of the entity and activity profile often surfaces the specific reason a bank declined. The route back typically requires regulatory clarification, not just a new application. Contact OBOLUS to scope a second review.
Which protocol profile matches which structure?
The right structure depends on the activity, the token, and the user base. Three common profiles illustrate how the analysis resolves.
Profile A – A protocol performing exchange or transfer functions with a centralized front-end. This profile most clearly attracts VASP registration and, under MiCA, CASP authorisation. The Lithuanian UAB registers with the Bank of Lithuania, completes the MiCA transition to CASP, issues a MiCA-compliant whitepaper, and implements Travel Rule compliance. The EU passport makes the structure scalable. The key risk is the timeline to full MiCA authorisation, which is measured in months and requires ongoing capital adequacy. The team should plan banking early.
Profile B – A genuinely decentralized protocol with no controlling intermediary. This profile requires a different analysis. If no entity performs a CASP activity, full CASP authorisation may not be required. But the token offering still triggers MiCA whitepaper obligations if tokens are offered to EU persons. The Lithuanian entity – if it exists – may serve primarily as a contracting and IP-holding vehicle, with governance living on-chain. Legal review must confirm that the absence of control is genuine and documentable, because a regulator will look hard at deployment keys, fee extraction, and upgrade mechanisms.
Profile C – A protocol with a governance token and institutional backers. Where token distribution involves institutional investors or public sale rounds, the securities-law analysis becomes primary. The Lithuanian UAB may need to be complemented by a Cayman or BVI structure for the token governance layer. Allied counsel in the relevant offshore jurisdictions should be engaged alongside Lithuanian counsel. The cross-border securities analysis – covering the EU, the US, Singapore, and any other market where tokens are distributed – must be completed before distribution, not after.
Self-assessment checklist before you file
Before engaging with the Bank of Lithuania or initiating a MiCA CASP authorisation process, a DeFi protocol team should be able to answer these questions with documented support:
- Is there a classification memo for every token the protocol issues or intermediates, reviewed against MiCA and the applicable financial-instruments regime?
- Is there a legal analysis of whether the protocol's smart-contract operations constitute VASP or CASP activities under the current Lithuanian framework?
- Is there a corporate structure chart showing every entity, every beneficial owner above the relevant threshold, and the flow of funds between entities?
- Has a smart-contract legal review been completed, distinct from the security audit?
- Is there a documented AML/CFT policy and a Travel Rule solution if required?
- Has banking access been confirmed with at least one institution, with a fallback identified?
- Has transfer pricing been documented for intra-group arrangements?
- Has a whitepaper been prepared in accordance with MiCA disclosure standards, or has a reasoned basis for exemption been documented?
A team that cannot answer all eight with supporting documents is not ready to file. Filing prematurely with the Bank of Lithuania creates a supervisory record that can complicate a later clean application.
Related at OBOLUS
- DeFi, tokenization and smart-contract law practice – the full scope of our technical and regulatory DeFi advisory work
- Smart-contract legal review for digital-asset firms – what a legal review covers and how it differs from a security audit
- De-risking and account closure defence in Canada – how to respond when a bank withdraws services from a digital-asset business
FAQ
Can a DeFi protocol be regulated?
Yes. Regulatory perimeters are drawn around activities, not technology labels. A DeFi protocol that facilitates exchange, custody, transfer, or lending of virtual assets can attract VASP or CASP obligations under Lithuanian law and under MiCA, regardless of whether those functions are performed by a smart contract rather than a human intermediary. The key question is whether an identifiable entity controls, deploys, profits from, or enables the protocol – if so, that entity bears the regulatory exposure.
What legal wrapper suits a DAO?
A DAO without a legal wrapper has no legal personality and cannot contract, hold assets, or engage with regulators. The most common solution pairs on-chain governance with an off-chain legal entity – a UAB in Lithuania for regulated activities, combined with a foundation or trust structure in a recognized offshore jurisdiction for token governance. The choice between these wrappers depends on the investor base, the token distribution, the jurisdiction of key team members, and the expected locations of liquidity events. No single structure is optimal for all DAOs.
Who is liable when a smart contract fails?
Liability when a smart contract fails depends on the specific failure mode and the applicable legal framework. Where a bug or exploit causes loss, liability analysis focuses on whether the deploying team owed a duty to users, whether the code constituted a warranty, and whether marketing materials made representations the code did not fulfill. In jurisdictions with developed crypto-asset case law – including England and Wales and Singapore – courts have shown willingness to hold deploying entities to account. A smart-contract legal review, completed before deployment, is the primary risk-reduction tool.
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 structures that sit around them. Digital assets are the whole of our practice. We assess token classification against the substance of rights conferred, not the marketing label – and where structuring intersects with disputes, our team coordinates freezing relief and on-chain tracing across leading common-law forums. To discuss your DeFi structuring situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specializes in smart-contract legal review, token classification, and DeFi protocol structuring across EU and offshore 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.