A DeFi protocol expanding into EU markets faces a legal question that most teams defer too long: does the protocol, its governance token, or any service it performs cross the threshold into regulated activity under MiCA (the Markets in Crypto-Assets Regulation), and if it does, who is the accountable legal person? With MiCA now in full application across EU and EEA member states, operating without a clear answer to that question is not a gap in paperwork – it is exposure to supervisory action by ESMA and the relevant national competent authority, plus the reputational fallout that follows a public finding.
This guide walks through the structuring decision in sequential steps: classification first, then entity architecture, then the operational and cross-border considerations that determine whether the structure actually holds. The cross-border reality is central. A protocol incorporated outside the EU can still be caught by MiCA if it actively targets EU users. Where the code runs is irrelevant; where the users are is the operative fact.
Step 1: Classify the token and the activity before you build the structure
The first and most consequential step in DeFi legal structuring is token classification, because the answer drives every subsequent decision about entity type, licensing need, and disclosure obligation. MiCA draws three principal categories – asset-referenced tokens (ARTs), e-money tokens (EMTs), and "other" crypto-assets – and each carries a distinct authorisation and whitepaper regime. The classification is not determined by what a team writes on a marketing page; it turns on the substance of the rights the token confers.
This is the point where a common assumption causes real harm. A utility label on a whitepaper does not settle the legal classification. We assess classification against the substance of rights, not the marketing term. A token that tracks a basket of fiat currencies, entitles the holder to redeem against a reserve, or derives its value primarily from a reference asset is likely an ART or EMT regardless of the name printed on it. A token structured purely as access to software functionality – with no expectation of profit, no governance power over economic parameters, and no redemption feature – has the stronger argument for falling outside the ART/EMT categories.
Governance tokens raise a further dimension. Where a governance token confers voting rights over protocol revenue, fee distribution, or treasury allocation, the rights conferred begin to resemble those of a financial instrument. That proximity to investment-contract logic is not resolved by MiCA alone; the underlying securities law of the relevant member state remains relevant, and ESMA has signalled that classification is a substance-over-form exercise. Teams we advise routinely discover mid-build that a governance token designed for community engagement carries economics that require rethinking before launch.
The practical output of this step is a written classification memorandum that the team can take to the regulator, the bank, and investors. Without it, each counterparty will form its own view, and those views will rarely converge on the most favourable reading for the protocol.
Step 2: Determine whether the protocol triggers CASP authorisation under MiCA
A protocol that performs a regulated crypto-asset service – exchange, transfer, custody, operation of a trading platform, advice, or portfolio management over crypto-assets – requires CASP (crypto-asset service provider) authorisation from the competent authority in its EU member state of registration. MiCA's activity-based test looks at what the protocol does in practice, not whether there is a human intermediary or whether the service is provided algorithmically.
Fully decentralised protocols with no identifiable issuer and no intermediary are treated differently under MiCA's recitals, but the operative test for that carve-out is strict. "Fully decentralised" in MiCA's sense means there is genuinely no legal person or group of persons who controls or can modify the protocol's core economic functions. In our practice, very few protocols launched today meet that standard at inception. Founders hold admin keys. Multisig governance has identifiable signatories. A foundation receives treasury funds. Each of these is a thread connecting a legal person to the protocol's function, and regulators will pull those threads.
The consequence of misreading the CASP threshold is serious. Operating an exchange or transfer service for EU users without CASP authorisation exposes the accountable entity – and potentially the controlling persons – to supervisory orders, financial penalties scaled to turnover, and public disclosure of the finding by the national competent authority under MiCA's enforcement provisions.
For protocols that do cross the CASP threshold, the next question is which member state to anchor the authorisation in. MiCA's passporting mechanism means that a CASP authorised in one member state may operate across the EU and EEA without a separate application in each country. The choice of anchor jurisdiction therefore becomes a strategic structuring decision, not just an administrative one.
To map your CTA position at this stage: The process above describes the standard CASP analysis path. Your facts – the token mechanics, the user geography, the governance architecture – change the analysis materially.
For a scoped classification and CASP-threshold assessment, contact OBOLUS at info@oboluslaw.com. We structure the analysis around your actual protocol mechanics, not a generic checklist. Map your options.
Step 3: Select the entity architecture for the protocol
The right legal entity for a DeFi protocol depends on three factors: the classification result from Step 1, the CASP analysis from Step 2, and the governance model the team intends to operate. These factors do not point in the same direction for every protocol, and the entity choice made at incorporation is expensive to reverse once the protocol has users, investors, and regulatory correspondence.
The most common structures we analyse across the EU DeFi environment are these:
A foundation-plus-operating-company model separates the IP and protocol governance (held by a non-profit foundation, typically in a civil-law jurisdiction) from the commercial service business (held by a company that can hold the CASP authorisation and take on contractual liability). This model works well where the protocol intends to pursue genuine progressive decentralisation: the foundation holds governance while the operating company manages the regulated front-end. The risk is regulatory see-through – ESMA and national competent authorities have indicated that they will look past entity separation to identify the party that in substance controls the regulated activity.
A single CASP-authorised company in a chosen EU anchor jurisdiction is the cleaner route for protocols that accept their regulated status and want to build from a compliant foundation. The anchor jurisdiction choice has material consequences for authorisation timeline, supervisory intensity, and the practical availability of banking. Teams that pursued a Lithuanian VASP registration under the prior regime now transition to MiCA CASP authorisation under the Bank of Lithuania's supervision. Malta's MFSA supervises transitioning VFA entities under the VFA framework as that regime converges on MiCA. Neither jurisdiction is intrinsically better; the choice turns on the protocol's profile, the national competent authority's track record with DeFi applications, and the team's capacity to support an on-the-ground presence.
A DAO legal wrapper is a third option, most relevant for protocols that want formal legal personality for their decentralised autonomous organisation without forcing the DAO into a conventional corporate form. Options include limited liability companies with DAO-referenced governance documents, foundations with on-chain governance mirrors, and specific DAO-recognition regimes in certain jurisdictions. Within the EU, no member state has yet enacted a purpose-built DAO statute equivalent to some offshore frameworks, so the wrapper is typically an analogue structure that contracts to give effect to on-chain votes.
Step 4: How does a MiCA CASP application proceed in practice?
A MiCA CASP application is a structured regulatory submission to the national competent authority in the chosen anchor member state, and the process is more demanding than the prior VASP registration regimes it replaces. The application requires detailed disclosures on governance, ownership, fit-and-proper assessments for key personnel, a programme of operations, internal controls documentation, and – for protocols with novel mechanics – a technical description of how the service operates on-chain.
The whitepaper obligation, where applicable, must be notified to the competent authority before marketing begins. For tokens other than ARTs and EMTs, the whitepaper is not pre-approved by the regulator, but it must meet MiCA's content requirements and carry the protocol's own liability for material omissions or misstatements. This means the whitepaper is a legal document, not a marketing brochure, and it should be reviewed with that liability framing in mind.
Timelines for CASP authorisation under MiCA are set by the regulation itself, but the clock runs from a complete application – and regulators in several member states have suspended the clock pending additional information requests on complex DeFi applications. In our cross-border practice, we have seen applications for algorithmically complex protocols take materially longer than simpler intermediary models, because the competent authority needs additional time to assess the activity classification. Building realistic timeline buffers into a product roadmap is therefore not conservatism; it is commercial planning.
The cross-border interaction at this step is significant. The entity seeking CASP authorisation must demonstrate substance in the anchor jurisdiction: a registered address, at least one senior manager based there, and genuine operational control exercised from that location. A brass-plate structure – with all real decision-making offshore and a nominal office in the anchor state – will not satisfy the substance requirements that national competent authorities apply under MiCA. This has direct implications for team structure, compensation arrangements, and where the protocol's key personnel are located.
Step 5: Address AML, Travel Rule obligations, and smart-contract compliance architecture
A CASP authorised under MiCA operates within the EU's AML regime, which applies FATF Recommendation 15 standards to virtual asset transfers, including the Travel Rule – the obligation to pass originator and beneficiary data alongside a crypto-asset transfer. For a DeFi protocol, Travel Rule compliance is architecturally challenging: the protocol must either build or integrate a mechanism for capturing and transmitting the required data, or structure the service in a way that a compliant intermediary handles the Travel Rule obligation at the point of customer interaction.
Smart-contract compliance architecture is a distinct but related concern. MiCA does not regulate smart contracts directly, but a CASP that delivers its regulated service through smart contracts cannot use the smart-contract layer as an insulation from its regulatory obligations. The CASP remains responsible for the conduct of the service regardless of the technical delivery mechanism. This means that upgrade mechanisms, admin key controls, emergency pause functions, and oracle dependencies must all be disclosed and documented – because the regulator and, in a dispute, the court, will treat the entity controlling those functions as responsible for the service's conduct.
One micro-matter from our recent practice illustrates the point. A DeFi lending protocol expanding into the EU engaged us after its initial compliance review flagged that the protocol's admin multisig – held by the founding team – gave those individuals unilateral authority to modify interest rate parameters that directly affected user returns. The competent authority had indicated this was an exercise of economic control inconsistent with the "fully decentralised" carve-out. We restructured the governance mechanism to route parameter changes through a time-locked on-chain vote with a defined quorum, and documented the change in a revised governance framework submitted with the CASP application. The application proceeded on a cleaner factual basis, and the competent authority's questions focused on KYC/AML rather than the decentralisation argument.
Step 6: Manage the cross-border tax and banking interaction
The legal structure for a DeFi protocol does not operate in isolation from the tax and banking environment, and in our practice the banking problem surfaces before the tax problem does. EU banks applying their own AML policies have significant discretion over whether to onboard a DeFi protocol company, and a legally sound CASP authorisation does not automatically translate into a banking relationship. The anchor jurisdiction choice, the protocol's token economics, and the operator's prior compliance history all factor into the bank's assessment.
The tax interaction is equally layered. A foundation-plus-operating-company structure, for example, generates transfer-pricing questions between the entities: what is the arm's-length consideration for the foundation's licence of IP to the operating company? A DAO-wrapper structure generates questions about where governance income – protocol fees flowing to a treasury – is taxed, and whether the DAO is a transparent or opaque vehicle for its token holders. These questions do not have uniform answers across EU member states, and the protocol's effective tax position depends on the specific interaction between the entity's jurisdiction of incorporation, the jurisdiction of economic substance, and the residence of token holders.
For protocols with a token that generates staking rewards or fee income, the cross-border VAT position also requires analysis. Several EU member states treat certain crypto-asset services as VAT-exempt financial services, but that exemption does not apply uniformly to all protocol revenue streams. Structuring the fee architecture to align with the applicable VAT treatment is part of the entity design, not a post-launch adjustment.
If a prior application stalled or a banking relationship was declined, a second structural review can surface the reason and the route back. Contact OBOLUS at info@oboluslaw.com or message us via t.me/oboluslaw. Map your options.
Step 7: Build the decision matrix for your protocol profile
Different protocol profiles require different structuring approaches, and the right answer is determined by the intersection of token economics, user geography, governance model, and risk tolerance. The following profiles cover the main scenarios we work through with clients.
Profile A – Pre-launch protocol, token not yet issued, EU users expected: The priority is a classification analysis before the token mechanics are finalised. Small changes to the governance rights, redemption features, or fee-distribution logic at the design stage can shift the classification outcome and materially reduce the compliance burden. Entity incorporation should follow the classification result, not precede it. Timeline for this path: classification work typically runs over several weeks; entity incorporation in a chosen EU anchor jurisdiction follows; CASP pre-application engagement with the national competent authority can begin in parallel. The key risk at this profile is locking in token mechanics that force an ART or EMT classification and the heavier authorisation requirements that come with it.
Profile B – Existing protocol, already serving EU users, no CASP authorisation: This is the most common situation we encounter at the bottom of the funnel: a protocol that grew into EU usage organically and now needs to regularise its position. The immediate priority is a CASP-threshold analysis to determine whether the current activity already crosses the regulated boundary. If it does, the team faces a choice between structuring for authorisation, adjusting the service to fall outside the CASP perimeter, or geoblocking EU users while the structure is put in place. None of these options is cost-free, and the right choice depends on how central the EU user base is to the protocol's commercial model. Timeline for this path is longer than Profile A because the application starts from an existing operational baseline that the competent authority will scrutinise against the current regulatory picture.
Profile C – Protocol with a DAO governance structure, seeking EU legal recognition: The DAO wrapper is the core structuring question here. The wrapper must give the DAO legal personality sufficient to contract, hold assets, and take regulatory responsibility, without centralising control in a way that defeats the governance model the community expects. In our cross-border practice, the choice of wrapper jurisdiction – and the interaction between on-chain governance rules and the wrapper's constitutional documents – is the design problem that requires the most careful analysis. Allied counsel in the relevant jurisdiction are engaged where local law governs the wrapper's formation.
Objection: a whitepaper label settles the classification
A common assumption among founding teams is that calling a token a "utility token" in the whitepaper is sufficient to avoid MiCA's ART and EMT regimes. It is not. ESMA and national competent authorities assess token classification on a substance-over-form basis: the rights conferred, the economic mechanics, and the reasonable expectations of holders determine the outcome. A whitepaper can document the intended design, but it does not bind the regulator. We have seen classification opinions reverse mid-process when the competent authority examined how the token actually operated on-chain compared to how the whitepaper described it.
The practical safeguard is a classification analysis done against the actual smart-contract code and governance documents, not just the marketing narrative. That analysis should be refreshed whenever the protocol is materially upgraded, because changes to fee logic, redemption features, or governance rights can move the classification outcome even when the token name stays the same.
Related at OBOLUS
- DeFi, Tokenization & Smart-Contract Law – our practice overview for protocols, DAOs and token issuers across EU and beyond
- DAO Legal Wrapper for Early-Stage Founders – structuring legal personality for decentralised governance teams
- VASP Licensing in Estonia – the Estonian licensing path as a complement to or alternative to MiCA anchor choices
FAQ
Can a DeFi protocol be regulated?
Yes – under MiCA, a DeFi protocol that performs a defined crypto-asset service for EU users can require CASP authorisation regardless of how the service is technically delivered. The "fully decentralised" carve-out in MiCA's recitals is narrow: it applies only where there is genuinely no identifiable legal person exercising control over the protocol's economic functions. Most protocols at or shortly after launch do not meet that threshold, because founders, foundations, or multisig holders retain meaningful control.
What legal wrapper suits a DAO?
The right wrapper depends on the DAO's governance model, the jurisdiction of its primary activity, and whether it needs to hold a regulated licence. Common options include a non-profit foundation with constitutional documents mirroring on-chain governance, a limited liability company with DAO-governance provisions, or a hybrid foundation-plus-operating-company model. No EU member state currently has a purpose-built DAO statute, so the wrapper is an analogue structure designed to give the DAO legal personality without forcing it into a conventional corporate form.
Who is liable when a smart contract fails?
Liability follows control. Where an identifiable legal person – a company, foundation, or individual – controls the smart contract through admin keys, upgrade functions, or governance rights, that person carries legal exposure for losses arising from the contract's operation. MiCA's CASP framework reinforces this: a CASP delivering its regulated service through smart contracts remains responsible for the conduct of that service. The smart-contract layer does not insulate the operator from regulatory or civil liability.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers, DeFi protocols 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 surround them. Digital assets are the whole of our practice. In DeFi structuring specifically, we assess classification against the substance of rights, not the marketing label – and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where a dispute arises. To discuss your protocol's position, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialising in smart-contract compliance architecture, token classification under MiCA, and DAO legal structuring for protocol teams expanding into EU markets.
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.