Decentralised finance – known as DeFi – describes a set of financial services delivered through self-executing code on a public blockchain, without a traditional intermediary standing between counterparties. For a digital-asset business building or interacting with a DeFi protocol, the central legal question is not whether the protocol is "decentralised" – it is whether the activities it enables fall inside a regulated perimeter, and if so, who bears the obligations. That question has no single global answer, and misreading it carries material consequences: mis-classifying a token or activity can convert a product launch into an unregistered securities offering or an unlicensed money-transmission operation.
This guide sets out the legal meaning of DeFi across the major regulatory regimes, maps the principal obligation triggers, and identifies the cross-border complications that arise when a protocol's code is deployed in one jurisdiction, its users sit in another, and its development team is incorporated in a third.
What Does "Decentralised Finance" Mean in Law?
DeFi, in functional legal terms, is the delivery of financial-service activities – lending, exchange, asset management, derivatives settlement – through smart contracts (self-executing code that runs automatically when pre-defined conditions are met) deployed on a distributed ledger, typically without a licensed intermediary performing those functions. The word "decentralised" is a technical descriptor, not a legal classification. Regulators in every major hub have been explicit: the absence of a central operator does not, by itself, remove an activity from the regulatory perimeter.
The critical analytical move is functional. Does the protocol enable the exchange of value between counterparties? Does it manage assets on behalf of users? Does it issue instruments that carry rights resembling those of a security or an e-money instrument? If the answer to any of those questions is yes, the regulatory frameworks in the EU, the US, the UK, Singapore and the UAE treat the function – not the architecture – as the primary classification test.
Under MiCA (the EU's Markets in Crypto-Assets Regulation, supervised by ESMA and national competent authorities), a crypto-asset service that is "fully decentralised" without any intermediary falls outside MiCA's CASP authorisation requirement. But ESMA guidance makes clear that "fully decentralised" is a high bar. A governance token that concentrates meaningful control in a founding team, a fee switch that accrues value to identifiable developers, or a smart-contract upgrade key held by a multisig of known persons all cut against a genuine decentralisation claim. In our practice, we rarely encounter a protocol that passes that test cleanly at launch.
The US framework is more granular. The SEC applies the Howey test (the standard for whether an instrument constitutes an investment contract) to token distributions, while the CFTC asserts commodity-derivatives jurisdiction over certain DeFi trading applications. FinCEN applies its money-services-business rules to any system that transmits value, regardless of whether a human operator is involved. Operating without the right federal or state-level authorisation – including a money-transmitter licence or the NYDFS BitLicense where New York users are involved – creates enforcement exposure that the protocol's code cannot insulate.
How Are DeFi Activities Classified Across Major Regimes?
Classification of a DeFi activity depends on a substance-over-form analysis of the rights it confers, not the label applied in a whitepaper. A utility label on a whitepaper does not settle the legal classification – this is perhaps the most consequential misconception we address in practice. Regulators look through the label to the economic reality of what holders receive.
The MiCA token taxonomy distinguishes three categories: asset-referenced tokens (ARTs), e-money tokens (EMTs) and "other" crypto-assets. Each triggers a different set of obligations. An algorithmic stablecoin that maintains peg through tokenised collateral may fall within the ART regime, carrying issuer-authorisation and reserve requirements even if its operation is entirely on-chain. An EMT must be issued by an authorised credit institution or e-money institution. A governance token distributed to protocol participants may fall into "other crypto-assets" but, if it confers profit expectations linked to the efforts of others, risks reclassification as a financial instrument under the Markets in Financial Instruments framework rather than MiCA at all.
In the UK, the FCA's financial-promotion rules and the Money Laundering Regulations apply to cryptoasset activities irrespective of whether a central operator exists. The FCA has made clear that "communicating" or "approving" a financial promotion related to a qualifying cryptoasset requires FCA authorisation or the involvement of an authorised person. A DeFi front-end accessible to UK users is within scope of that obligation.
MAS in Singapore takes a similarly activity-based approach under the Payment Services Act. A protocol enabling the exchange of digital payment tokens for fiat or other digital payment tokens may constitute a digital payment token service, drawing in licensing requirements regardless of whether the exchange function runs through a smart contract rather than an order book operated by a legal person.
In the UAE, VARA's activity-based licence categories – advisory, broker-dealer, custody, exchange, lending, management and transfer/settlement – are drafted to capture the function, not the form of delivery. A yield-aggregation protocol that routes user funds between lending pools performs functions analogous to asset management and custody. VARA has signalled that it will apply its rulebooks to DeFi activities that touch Dubai users or are marketed from Dubai.
Who Is Responsible When There Is No Central Operator?
Identifying the legally responsible party in a DeFi protocol is the hardest and most consequential question for regulators and for businesses building in the space. The answer turns on control – specifically, who controls upgrades, who controls fee flows, and who controls access to the protocol's administrative functions.
Courts in England and Wales have begun to address this in the recovery context. The principle emerging from decisions in that jurisdiction is that property rights in digital assets are recognised, and that injunctive relief can reach smart-contract balances where a sufficiently identified respondent can be joined. The CFAAR (Crypto Fraud and Asset Recovery network, launched in London in September 2021) has been a practical coordination point for those matters. That body of case law is not DeFi-specific, but it establishes a foundation: on-chain activity is not beyond legal process.
For regulatory purposes, the persons who deployed the protocol, who hold administrative keys, who receive fees from protocol operation, or who exercise governance rights through a token majority are, in most regimes, candidates for the attribution of regulatory obligations. The founding development team that retains an upgrade key is functionally an operator, regardless of what the documentation says. Operators we advise are regularly surprised to learn that post-launch decentralisation plans – even genuine ones – do not retroactively resolve the regulatory classification that attached at launch.
In the US, the SEC has pursued enforcement actions on the basis that protocol developers are promoters of unregistered securities where governance tokens were distributed in connection with investment activity. The CFTC has taken parallel action in the derivatives context. Neither agency accepts the argument that smart-contract automation removes human actors from the regulatory analysis.
For a CTA:
The entity, the user base and the control architecture together determine where obligations attach. A pre-launch or pre-distribution legal review is the most cost-effective point at which to identify and address those obligations. For a scoped assessment of your protocol's classification risk, contact OBOLUS at info@oboluslaw.com or map your options here.
What Legal Wrapper Suits a DAO?
A DAO (decentralised autonomous organisation) is a governance structure in which protocol decisions are made through token-weighted voting, often executed automatically by smart contracts. Without a legal wrapper, a DAO is typically treated as a general partnership in common-law jurisdictions – meaning its members share unlimited joint and several liability for its acts. That is rarely an acceptable risk profile for a business of any scale.
The major structural options in current practice are as follows. A Wyoming DAO LLC gives the structure limited-liability status under US law, but subjects it to US regulatory jurisdiction, which is material given the SEC and CFTC's active DeFi posture. A Marshall Islands DAO LLC or a Cayman Islands foundation company are frequently used for protocols seeking a common-law wrapper with lighter domestic regulatory imposition on the entity itself. The Cayman foundation, in particular, has become a standard vehicle because it has no members in the traditional sense – the foundation council acts as a steward rather than an equity-holder – which aligns more cleanly with the governance logic of a token-based DAO.
The BVI and the Cayman Islands both maintain VASP registration regimes under their respective acts, and a DAO that operates a protocol conducting VASP-equivalent activities will need to consider whether the wrapper entity triggers registration obligations. CIMA in the Cayman Islands and the BVI FSC maintain oversight across the relevant activity categories.
The AIFC in Kazakhstan, operating through AFSA, has developed a common-law digital-asset framework that some DAO-adjacent structures have used as an operating jurisdiction, particularly for teams with connectivity to Central Asia or for protocols seeking a non-Western licensing base. In our cross-border practice, we regularly assess the wrapper choice against the protocol's user geography, its token distribution plan and its banking requirements – because the entity domicile that optimises one variable often creates tension on another.
It is also worth noting that a legal wrapper does not insulate token holders from the regulatory classification of the token itself. A governance token issued by a Cayman foundation is still assessed under MiCA, the Securities Act or the MAS Payment Services Act based on its substantive characteristics and the jurisdiction of its holders – not the jurisdiction of the issuer entity.
Who Is Liable When a Smart Contract Fails?
Liability for a smart-contract failure depends on the nature of the failure, the contractual relationships in place and the jurisdiction in which a claim is brought. Three principal failure modes arise in practice: a coding error that causes loss, an oracle failure that produces an incorrect price feed, and an economic exploit that drains a protocol through flash-loan or re-entrancy attack.
In English law, the developers of a smart contract can be liable in tort for negligence where they owe a duty of care to users and the code falls below the standard a competent developer would produce. Whether that duty exists turns on foreseeability and proximity – a publicly advertised protocol with a known user base is much more likely to generate that duty than internal tooling. The DIFC Courts have jurisdiction to entertain equivalent claims for parties with UAE connections, and Singapore's courts have addressed comparable issues in the context of digital-asset property disputes.
Oracle failures introduce a separate chain of liability: the oracle provider, the protocol that relied on the oracle without adequate circuit-breakers, and in some cases the DAO governance participants who approved the oracle integration. Economic exploits are more complex still – a deliberate exploit by a third party may not give rise to liability on the part of the developer unless the vulnerability was known and not disclosed, but class-action dynamics in the US (under federal securities laws where the token is classified as a security) and civil claims in England and Wales have both been actively pursued following protocol exploits.
Audit reports reduce but do not eliminate liability exposure. A clean audit report does not amount to a warranty. It shifts the factual question toward whether a post-audit change introduced the vulnerability, but it does not create a defence against a negligence claim if the exploit involves a vector that a competent auditor should have identified. In matters we have assessed, the contractual terms between the protocol and its auditor, and between the protocol and its users, are often the decisive documents – because the substantive liability analysis begins with what those contracts say, not what the code does.
Does the FATF Travel Rule Apply to DeFi?
The Travel Rule (the obligation under FATF Recommendation 15 to pass originator and beneficiary information with a virtual-asset transfer) formally applies to Virtual Asset Service Providers, not to protocols. The analytical question is whether a DeFi protocol is operated by a VASP. Where it is – where there is an identifiable legal person controlling the service – the Travel Rule applies to transactions above the applicable threshold, which varies by jurisdiction and is a matter for current local legislation.
FATF's guidance on DeFi acknowledges the challenge. Where no owner or operator can be identified, the Travel Rule cannot mechanically apply. But FATF guidance also makes clear that regulators should assess whether a person "owns or controls" a DeFi protocol, and where they do, that person is a VASP. The EU's transfer-of-funds regulation, which implements Travel Rule obligations across the EU under MiCA's broader AML architecture, applies to transfers involving obliged entities. A front-end operator, a developer holding upgrade rights, or a fee-recipient entity is likely to fall within that perimeter.
Practically, this means that a DeFi business with an identifiable legal entity – even one whose protocol is "permissionless" at the smart-contract level – must assess its AML/CFT obligations, implement a compliance programme and consider how transaction monitoring is conducted. The technical architecture of permissionless execution does not satisfy the obligation; a compliance programme that addresses VASP-level monitoring is required where the entity meets the threshold for a regulated status.
MAS in Singapore has been among the more detailed regulators on this point. The FCA in the UK requires AML registration for cryptoasset businesses and applies its financial-crime framework to the activities of those businesses regardless of delivery mechanism. VARA in Dubai and FSRA in Abu Dhabi both require AML programmes from licensed or registered entities, and both have signalled that entity-level analysis – who controls, who benefits – will drive their DeFi enforcement posture.
How Does Tokenization Interact with DeFi Protocols?
Tokenization – the process of representing rights to an off-chain asset (real estate, a fund interest, a receivable) as a token on a distributed ledger – creates a distinct layer of legal complexity when those tokens are introduced into DeFi protocols. The token's legal character is inherited by its on-chain behaviour: a tokenised security that is used as collateral in a lending protocol does not shed its securities-law classification because it has been deposited into a smart contract.
This has direct consequences. A DeFi lending protocol that accepts tokenised securities as collateral may itself be operating a securities lending or margin-lending service. The smart contract's collateral management function is, from a regulatory standpoint, identical in substance to the equivalent function performed by a prime broker. MiCA treats tokenised instruments with a cross-reference to MiFID II and the EU's prospectus regime; real-world asset (RWA) tokenization has attracted heightened scrutiny across all major hubs precisely because the on-chain wrapper does not dissolve the off-chain regulatory classification.
In our practice, we see this most acutely in the context of fund tokenization. A tokenised interest in a fund that would otherwise be a collective investment scheme retains that classification. Distributing it through a DeFi front-end does not convert it into a less-regulated instrument. The SEC, the FCA and MAS have each taken clear positions on this point, and VARA has incorporated equivalent logic into its management and exchange licence categories.
The practical implication for a builder is this: every asset class contemplated for use within or alongside a DeFi protocol requires its own classification analysis, conducted before deployment. The cross-border dimension compounds the issue – a tokenised instrument classified as a security in the US may be classified differently in Malta under the transitional VFA framework, and the relevant test for each user is the law of the user's jurisdiction, not the law of the issuer's domicile.
What Are the Cross-Border Legal Risks for a DeFi Business?
The cross-border risk profile of a DeFi business is structurally different from that of a centralised exchange or custodian. A centralised operator can geo-block users; a DeFi protocol deployed on a public chain cannot control who interacts with it at the smart-contract level, even if the front-end applies IP-address filtering. That asymmetry creates multi-jurisdictional regulatory exposure that is difficult to eliminate and must be managed through legal structure, compliance design and disclosure.
The entity sits in one jurisdiction, the code runs on a global network, the users are distributed across every major market and the banking relationships – if any – are in a third set of jurisdictions. Each of these layers has its own regulatory logic. The entity's home jurisdiction determines its primary licensing obligations. The users' jurisdictions determine whether those users' activity triggers regulatory obligations in their home markets – and, specifically, whether solicitation or offer of a service to persons in those jurisdictions is permitted. The banking jurisdiction determines AML/KYC obligations on the entity's fiat on- and off-ramps.
In a recent matter, a development company incorporated in a common-law offshore jurisdiction had deployed a lending protocol that attracted meaningful user volume from EU and US addresses. The front-end applied a US IP-block, but the smart contracts were accessible without the front-end. We advised on the extent to which the EU user activity triggered MiCA CASP obligations for the entity, and whether the US IP-block was sufficient to establish a good-faith attempt at geo-restriction for FinCEN and SEC purposes. The analysis required coordinating positions across three regulatory regimes simultaneously, with allied counsel engaged in the relevant jurisdictions for local law input.
The DIFC Courts in Dubai and the courts of England and Wales are the most commonly invoked forums for interim relief in cross-border DeFi disputes – worldwide freezing orders and Norwich Pharmacal disclosure orders are available in both. Singapore's courts have also issued proprietary injunctions over crypto assets, and the CFAAR network provides a coordination mechanism for cross-border recovery. For any DeFi business with multi-jurisdictional user exposure, the question of where disputes will be resolved, and under what law, should be embedded in the protocol's governance documentation before launch, not addressed after an incident.
If a prior structure has created regulatory overhang – or if a geo-restriction strategy needs to be pressure-tested before launch – a second-opinion review can identify the gap and map the route to resolution. Write to our team at info@oboluslaw.com or request a scoped review.
What Are the Most Common Legal Mistakes in DeFi Builds?
The most consequential legal mistake in a DeFi build is treating the classification question as a marketing decision rather than a legal one. The four patterns we see most often are each addressable, but each becomes more expensive the longer it is left unresolved.
The first is token classification without legal analysis. A team selects a "utility" label for a governance or revenue-sharing token without a functional legal assessment of the rights the token confers. Where those rights include profit expectations linked to the efforts of the development team, the Howey test in the US, the MiCA classification logic in the EU and equivalent tests under the MAS Payment Services Act and the FCA regime will classify the token as a regulated instrument. The label in the whitepaper has no legal weight.
The second is the assumption that decentralisation is a regulatory defence. As the analysis above makes clear, control – of upgrade keys, of fee flows, of governance concentration – is the operative concept. A protocol that is technically permissionless but operationally controlled by an identifiable group is not decentralised for regulatory purposes.
The third is failing to plan for the DAO wrapper before token distribution. Once tokens are in circulation, restructuring the governance entity is significantly more complex, because it requires engaging with existing token holders and potentially triggering additional regulatory events. The wrapper decision is a pre-distribution exercise.
The fourth, and the one that most directly generates litigation, is deploying a protocol with tokenized assets – whether stablecoins, RWA tokens or fund tokens – without confirming the regulatory classification of those assets in each jurisdiction material to the protocol's user base. In our cross-border practice, we routinely find that a protocol that is well-structured for its home jurisdiction has unaddressed exposure in one or two additional markets that account for a significant portion of its volume.
When Does a DeFi Activity Trigger a Licensing Requirement?
A DeFi activity triggers a licensing requirement when it constitutes a regulated activity under the applicable regime and when there is an identifiable legal person who conducts that activity. The two conditions are conjunctive: a fully automated, truly ownerless protocol in a jurisdiction that confines its regulatory perimeter to identified persons may not trigger a licence obligation. In practice, the second condition is almost always satisfied.
The regulated activities most likely to be triggered by DeFi operations are: operating a virtual-asset exchange (VARA, SFC, MAS, FCA, MiCA CASP); providing custody of virtual assets (VARA, FSRA, FINMA, SFC); providing portfolio management or advisory services over virtual assets (VARA, MAS, FCA, FINMA); operating a lending or margin-lending facility (CFTC, FCA, MAS); and issuing a stablecoin or an ART/EMT (MiCA). Each of these activity categories has a distinct licensing track in each major jurisdiction, and the timelines and capital requirements vary – and are a matter for current local legislation and should be confirmed with current regulatory guidance.
The decision point for a DeFi business is whether to obtain a licence in a primary jurisdiction and rely on that framework (with passporting where available, as under MiCA's CASP passporting regime across EU/EEA states), or to structure the protocol to remain outside the regulated perimeter in the jurisdictions material to its user base. Both paths are viable in the right circumstances; neither is viable without a clear-eyed legal assessment of which activities are in scope and which users are in scope.
Profile A – a protocol deploying in the EU with a legal entity and meaningful governance control: MiCA CASP authorisation is the primary track, with national competent authority engagement in the chosen member state and passporting to other member states once authorised. Timeline and capital requirements vary by activity category and are set by the applicable NCA.
Profile B – a protocol with a global user base, an offshore entity and no EU-facing marketing: the analysis centres on which users' jurisdictions require local registration or licensing, whether a US nexus exists that brings SEC/CFTC jurisdiction, and whether the banking relationships create AML obligations in a third jurisdiction. Allied counsel in each relevant jurisdiction is required for a defensible multi-market position.
Profile C – a DAO with no formal entity, distributed governance and a purely on-chain treasury: the immediate priority is entity formation, because the absence of a wrapper leaves all governance participants exposed to unlimited joint liability in most common-law systems. The regulatory classification question follows the entity decision.
Related at OBOLUS
- DeFi, Tokenization & Smart-Contract Law – practice overview covering the full spectrum of on-chain legal issues for digital-asset businesses
- Real-World Asset Tokenization Under Heightened Scrutiny – legal analysis of RWA tokenization across major regulatory regimes
- Digital-Asset Licensing in the United States – federal and state licensing requirements for digital-asset businesses operating in or into the US
FAQ
Can a DeFi protocol be regulated?
Yes. Regulators in the EU, the US, the UK, Singapore and the UAE apply a functional test: if the protocol enables a regulated activity – exchange, custody, lending, asset management – and an identifiable person controls or operates it, that person is subject to the applicable regulatory regime. Full decentralisation (no identifiable operator, no control) is a theoretical exemption that few protocols achieve at launch. The MiCA CASP regime, VARA's activity-based licences, and the MAS Payment Services Act all operate on this basis.
What legal wrapper suits a DAO?
Without a legal wrapper, a DAO is typically treated as a general partnership under common-law systems, exposing members to unlimited joint liability. A Cayman Islands foundation company is the most widely used structure for protocol DAOs: it has no equity members, its council acts as a steward, and it aligns with token-based governance logic. Wyoming DAO LLCs, Marshall Islands DAO LLCs and BVI structures are alternatives, each with distinct tax, regulatory and liability profiles that depend on the protocol's user geography and activity type.
Who is liable when a smart contract fails?
Liability depends on the nature of the failure and the jurisdiction in which a claim is brought. In English law, developers may be liable in tort for negligence if they owe a duty of care to users and the code falls below the standard of a competent developer. Governance participants who approved a defective integration may also face claims. An audit report reduces but does not eliminate exposure. The contractual terms between the protocol, its auditors and its users are typically the decisive documents in assessing liability.
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 obligations that surround them. We assess token classification against the substance of rights conferred, not the marketing label – and we advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialises in smart-contract legal risk, DAO structuring and the regulatory classification of DeFi protocols across multi-jurisdictional builds.
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.