A token issuer preparing to deploy smart contracts across the European Union faces a question that goes well beyond code: does the contract create a regulated instrument, and if so, who is responsible for it? Under the Markets in Crypto-Assets Regulation (MiCA), the classification of a token determines whether the protocol, the issuer, or an intermediary triggers authorisation, whitepaper, and ongoing disclosure obligations. Getting that classification wrong converts a product launch into an unregistered offering – and the risk materialises before the first user connects a wallet.
This guide sets out the step-by-step process for a smart-contract legal review under MiCA and the cross-border considerations that shape it. It addresses token classification, the regulated perimeter for DeFi and tokenization (the process of representing real-world or on-chain rights as blockchain tokens), disclosure requirements, DAO structure, and the points at which outside counsel should be engaged. Each step begins with a direct answer, names the applicable regime, and identifies the most common mistake at that stage.
Why smart-contract review is different under MiCA
MiCA imposes obligations that attach to the function of a token or protocol, not to its technical form. The regulation distinguishes three primary token categories – asset-referenced tokens (ARTs, which reference multiple assets or currencies), e-money tokens (EMTs, which reference a single fiat currency), and a residual category covering other crypto-assets including utility tokens – and applies different issuer and service-provider requirements to each. A smart contract that issues, transfers, or exchanges any of these instruments falls into a defined perimeter unless a specific exemption applies.
ESMA and the relevant national competent authorities share supervisory responsibility under MiCA, with ESMA coordinating policy and enforcement standards across EU and EEA member states. The passporting mechanism means that authorisation in one member state carries throughout the bloc, but it also means that a product accessible to users in any member state triggers the full regime – there is no safe corner of the EU where MiCA does not reach.
In our cross-border practice, we regularly see issuers assume that a protocol's non-custodial design removes it from the regulated perimeter. That assumption is increasingly difficult to sustain. Where a smart contract systematically performs an exchange function, a custody function, or a transfer and settlement function, the question turns on whether any identifiable person is providing that service in a professional capacity – not on whether a central server exists.
Step 1: Token classification – the threshold question
The first step in any smart-contract legal review under MiCA is to determine, on a substance-over-form basis, which category or categories of instrument the smart contract creates, transfers, or settles. This analysis drives every downstream obligation.
The classification exercise maps the rights conferred by the token against the three MiCA categories and against the pre-existing financial instruments perimeter. A token that confers a right to a share of profits, a governance right coupled with an economic expectation, or a claim against a defined pool of assets may fall outside MiCA's scope entirely – into the regulated financial instruments regime under the existing EU regime for investment services. That outcome is not a lighter one; it is typically heavier.
The most common mistake at this step is relying on the label applied in marketing materials. A utility label on a whitepaper does not settle legal classification. ESMA has signalled, and national competent authorities have confirmed in supervisory correspondence, that substance controls. The relevant questions are: what rights does the token holder actually hold against whom; what legitimate expectation of economic return, if any, does the protocol create; and does the token reference or track an external asset or currency? Answers to those questions determine the regime, not the term used in the project documentation.
Mis-classifying a token can convert a product launch into an unregistered securities offering – triggering enforcement action, issuer liability, and, in cross-border structures, simultaneous regulatory exposure in multiple EU member states. We assess classification against the substance of rights conferred, using the same analytical framework the regulator applies.
Cross-border note: Where the issuer is domiciled outside the EU but the smart contract is accessible to EU-resident users, MiCA's provisions on offers to the public are engaged. The "offer to the public" concept under the regulation does not require physical presence in the EU; it follows the user. Operators we advise routinely discover this after initial deployment, at which point remediation is considerably more expensive than upfront review.
Step 2: Does the protocol need a CASP authorisation?
Once token classification is settled, the second step determines whether any entity connected to the smart contract must obtain authorisation as a crypto-asset service provider (CASP) under MiCA. CASP activities include operating a trading platform, providing custody, executing orders, exchanging crypto-assets for fiat, and providing transfer and settlement services – each defined by the regulation's activity list.
The critical analytical point is identifying who, if anyone, is the service provider in a DeFi context. Where a protocol is operated by an identifiable legal entity or a foundation that retains administrative keys, upgrades the contract, or collects fees from protocol activity, that entity is a strong candidate for CASP status. Where the protocol is genuinely governed by a fully decentralised token holder community with no controlling entity, the question is harder – but the absence of a clear defendant does not mean the absence of a regulatory obligation, and national competent authorities have been cautious about confirming de-centralisation as a bright-line exemption.
For tokenization structures – where a smart contract represents ownership or economic rights in an underlying asset – the CASP analysis intersects with the question of whether the token constitutes a financial instrument regulated under the existing investment-services regime. If it does, MiCA does not apply to that token, but a separate set of authorisation requirements may.
A CASP authorisation in one EU/EEA member state passports throughout the bloc. Operators considering multiple jurisdictions should map the authorisation strategy early: the passporting benefit means a single licence can serve the entire market, but the choice of home state affects supervisory intensity, processing timelines, and ongoing compliance costs.
CTA #1: The process above describes the standard analytical path. Your facts – the entity structure, the user geography, the token mechanics, and the banking arrangement – change the analysis materially. For a scoped assessment of your smart-contract structure under MiCA, contact OBOLUS at info@oboluslaw.com.
Step 3: Whitepaper and disclosure obligations
Where a token falls within MiCA's scope and no exemption applies, the issuer must prepare and publish a crypto-asset whitepaper that satisfies the regulation's content and presentation requirements. The whitepaper is not a marketing document; it is a regulated disclosure instrument, and the issuer bears civil liability for material omissions or misstatements.
The content obligations differ by token category. ART and EMT whitepapers carry the heaviest requirements, including reserve asset disclosure, redemption mechanics, and regulatory approval before publication. Whitepapers for other crypto-assets – including most utility tokens within MiCA's scope – must be notified to the relevant national competent authority before offering, but do not require prior approval. The practical distinction matters: approval timelines for ART and EMT issuers are measured in months, not weeks.
Smart-contract code is not a substitute for a whitepaper. Where the protocol's behaviour is governed entirely on-chain, the issuer must still produce a compliant off-chain disclosure document that explains the token, the project, the rights conferred, and the risk factors in plain language. In practice, we see protocols with sophisticated on-chain governance deploy whitepapers that were drafted for a different product – this creates a material mismatch between the disclosed and actual token mechanics and is a recurring source of regulatory exposure.
For tokenization structures involving real-world assets, the whitepaper must address both the token mechanics and the underlying asset – its legal title, custody arrangement, and any encumbrances. Where the underlying asset is a financial instrument, the overlap with the existing EU prospectus or investment-services disclosure regime must be carefully managed.
Step 4: DAO structure and legal wrapper options
Where a smart-contract protocol is governed by a decentralised autonomous organisation (DAO) – a token-holder governed structure that coordinates through on-chain voting rather than through traditional corporate organs – the legal review must address the liability exposure of governance participants and the appropriate legal wrapper for the DAO itself.
The legal wrapper question has no universal answer under MiCA. The regulation does not define a DAO-specific legal form. A DAO operating without any legal entity risks being treated as an unincorporated association or general partnership in the relevant EU member states, which can expose active governance participants to personal liability for the DAO's regulatory obligations. Several structuring options exist: a foundation in a civil-law jurisdiction, a limited liability company with a token-holder governance overlay, or a structure in a jurisdiction that has introduced bespoke DAO legislation. Each option carries different tax treatment, supervisory exposure, and banking accessibility.
In our practice, the most significant DAO structuring risk we encounter is the assumption that decentralisation of governance is equivalent to absence of legal personality. It is not. A DAO that issues tokens, collects protocol fees, and enters into contracts – even if those contracts are encoded in smart-contract logic – is conducting economic activity. The question regulators and courts apply is whether there is a controlling mind or a set of controlling participants behind that activity, not whether the activity is technically automated.
For DAOs seeking to operate within the EU under MiCA, the practical path typically involves establishing a legal entity in a member state that can hold the CASP authorisation, employ personnel, and interface with the banking system, while preserving on-chain governance rights for token holders within a defined governance perimeter that does not itself constitute a regulated CASP activity.
Step 5: Cross-border interaction with tax and banking
A smart-contract legal review under MiCA cannot be completed in regulatory isolation. The same facts that determine MiCA classification simultaneously engage tax characterisation – whether the token is income-producing, capital in nature, or subject to VAT – and banking access, which remains a practical constraint for many DeFi and tokenization projects operating in the EU.
Tax treatment of tokens is jurisdiction-specific within the EU and varies materially between member states even within the MiCA regime. The classification of a token as an ART, EMT, or utility token does not automatically determine its tax treatment; the tax analysis is conducted separately by the relevant national tax authority. Issuers planning to operate across multiple EU member states should conduct the tax analysis in parallel with the MiCA classification review, not after it. A structure that is clean from an MiCA perspective can carry significant VAT exposure in one jurisdiction and be tax-neutral in another.
Banking access for DeFi and tokenization projects remains operationally challenging across the EU. Many EU commercial banks apply conservative de-risking policies to crypto-asset businesses, regardless of MiCA compliance status. Regulated status under MiCA removes one category of objection – the absence of a regulated licence – but does not eliminate others, including the bank's own AML policy, its correspondent bank's requirements, and the jurisdiction of the issuer entity. In our cross-border practice, we advise clients to map the banking strategy before committing to a corporate domicile, not after.
The Travel Rule (the obligation to pass originator and beneficiary data with a virtual-asset transfer) applies under MiCA's AML framework to CASPs processing transfers. For smart-contract protocols that pass value between wallet addresses, the Travel Rule implications depend on whether any identified CASP is in the transfer chain. DeFi protocols that route transfers entirely peer-to-peer between unhosted wallets are in a grey zone that ESMA has not yet resolved definitively.
Micro-matter: Tokenization structure under MiCA
In a recent engagement, a real-estate tokenization platform preparing to offer tokens to EU retail investors engaged us to review the classification and disclosure structure before launch. The smart contract created fractional economic rights in an underlying property portfolio, with returns distributed on-chain. Initial documentation labelled the tokens as utility tokens. On review, the rights conferred – a proportional economic return tied to an external asset pool – placed the tokens clearly within the ART regime rather than the utility category, requiring issuer authorisation and a whitepaper subject to regulatory approval rather than mere notification. We restructured the disclosure and entity arrangements accordingly, and the client proceeded to the authorisation process with a complete and accurate regulatory position. The matter was resolved in the months before the client's planned EU launch window.
Step 6: The decision point – when to engage counsel
The right moment to engage counsel for a smart-contract legal review under MiCA is before the token economics and smart-contract architecture are finalised – not after the whitepaper has been drafted or, worse, after the initial deployment. Classification decisions, once embedded in a token's on-chain mechanics, are expensive to reverse. Issuer liability under MiCA for a whitepaper that mischaracterises the token category attaches regardless of intent; the standard is objective.
The decision matrix for an inbound operator breaks into three broad profiles. A project deploying a single-purpose utility token with no economic return component and a genuinely non-custodial architecture should still conduct a classification review – the MiCA residual category imposes whitepaper notification obligations even where no authorisation is required – but the compliance burden is manageable with proportionate outside support. A project deploying a protocol that performs exchange, custody, or transfer functions for users requires a full CASP authorisation analysis and, depending on the activity set, may need to pursue authorisation in one or more member states before launch. A project deploying a tokenization structure involving real-world assets or a DAO governance layer requires a parallel review of MiCA classification, the existing financial instruments regime, DAO legal wrapper options, tax treatment, and banking access – a matter that typically takes several weeks of focused legal work and benefits from coordinated advice across the regulatory, tax, and structuring dimensions.
Where the issuer is domiciled outside the EU, allied counsel in the relevant jurisdiction will need to advise on the home-country regulatory position. OBOLUS coordinates that cross-border analysis as a single engagement, structuring the advice around the issuer's commercial timeline rather than the jurisdictional boundaries of any single legal system.
CTA #2: If a prior classification analysis produced an uncertain conclusion, or if a deployment has already occurred and the regulatory position has not been formally reviewed, a second read of the structure can identify the exposure and the route to remediation. To map the licence, classification, and disclosure stack for your build, write to OBOLUS at info@oboluslaw.com.
Common assumption: a utility label settles classification
A common assumption among issuers coming to MiCA for the first time is that labelling a token as a utility token in a whitepaper or terms of service resolves the classification question. It does not. MiCA's classification regime is functional: the rights actually conferred by the token, the expectations a reasonable holder would form from the protocol's design, and the economic mechanism the smart contract implements are the operative facts. The label is relevant only as evidence, and it is weak evidence where the on-chain mechanics point in a different direction.
ESMA's guidance and the supervisory practice of leading national competent authorities confirm that regulators review token mechanics, not token names. A token marketed as a governance token that also entitles the holder to a share of protocol revenue is not a pure governance instrument; the economic component may bring it within a regulated category. A token marketed as a stable store of value that references a basket of currencies is an ART regardless of the marketing term applied to it.
The practical implication is that a classification opinion cannot be issued on the basis of a marketing document alone. It requires review of the smart-contract code, the governance documentation, the economic model, and the intended user relationship. We conduct that review systematically, assessing classification against the substance of rights conferred – the same analysis the regulator applies – and producing a written classification opinion that the issuer can present to a national competent authority, a banking partner, or a prospective investor.
Related at OBOLUS
- DeFi, Tokenization and Smart-Contract Law – our core practice covering protocol legal review, DAO structuring, and token classification across regimes.
- Cross-chain bridge legal risk – compliance burden analysis for multi-chain protocol operators navigating AML and regulatory exposure.
- AIF structuring for digital assets in Estonia – fund-wrapper options for digital-asset portfolios in an EU member state with a developed regulatory record.
FAQ
Can a DeFi protocol be regulated?
Yes, and the question is increasingly how – not whether. Under MiCA, the relevant test is whether any identifiable person provides a crypto-asset service in a professional capacity through or in connection with the protocol. A genuinely autonomous, non-upgradeable protocol with no controlling entity sits in a difficult regulatory grey zone; a protocol operated or upgraded by a foundation, a company, or an identifiable developer group is a strong candidate for CASP obligations. National competent authorities across the EU have declined to confirm decentralisation as a categorical exemption, and ESMA's evolving guidance points toward function over form.
What legal wrapper suits a DAO?
No single answer fits every DAO under MiCA. A foundation in a civil-law EU member state is a common choice where the DAO needs a legal entity to hold a CASP authorisation and engage with the banking system. A limited liability company with a governance overlay is used where the DAO's activities are primarily commercial rather than advocacy-oriented. Jurisdictions outside the EU that have introduced bespoke DAO legislation offer additional options, but those structures must be evaluated for their ability to passport MiCA authorisation – which they cannot do directly. The right structure depends on the DAO's activity profile, its membership, and its banking and tax position.
Who is liable when a smart contract fails?
Liability follows control and representation, not code authorship alone. Under the principles applicable in EU member states, a person or entity that deployed the contract, represented its behaviour to users, or retained the ability to upgrade or pause it is exposed to claims arising from a failure. MiCA's whitepaper liability provisions impose civil liability on issuers for material omissions and misstatements in the disclosed token mechanics. Where no legal entity is identifiable, courts in leading common-law forums have reached back to active governance participants. Code-as-law does not override the general law of obligations in the jurisdictions where users are located.
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. In our practice, we assess token classification against the substance of rights conferred – not the marketing label – applying the same analytical framework regulators use. We work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where a dispute arises. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialist in smart-contract legal review, DeFi protocol classification, and DAO structuring under MiCA and cross-border digital-asset regimes.
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.