Decentralised finance presents the hardest liability question in modern commercial law: when a protocol operates autonomously, governed by code and coordinated by token holders scattered across dozens of jurisdictions, who answers when something goes wrong? The answer is rarely "nobody" – and the businesses that proceed as though decentralisation confers immunity routinely discover otherwise, sometimes at considerable cost.
Liability in decentralised systems turns, at its core, on a threshold inquiry: whether a court or regulator can identify a responsible person behind the protocol. Contrary to a widespread assumption in the industry, the absence of a central operator does not eliminate legal exposure. It redistributes it – across developers, governance token holders, deployers and, in some regimes, the front-end interface provider. The applicable legal regime varies by jurisdiction, but the conceptual challenge is the same everywhere: fitting a technology built to evade capture into a legal order built on identifiable obligors.
This analysis maps the competing legal theories, the cross-border dimension, and the structural choices that shift – or concentrate – that exposure. It is designed to help general counsel, founders and institutional participants understand where liability lands before a crisis forces the question.
The Core Problem: Decentralisation as a Legal Category
Decentralisation does not exist in law as a defined concept; it exists as a spectrum of technical and governance facts that courts must translate into familiar legal categories. A protocol sitting at the far end of that spectrum – no controlling entity, no identifiable development team, no formal governance structure – presents genuine attribution difficulties. Most commercial DeFi deployments sit far closer to the other end.
In our cross-border practice, we observe that the first question any regulator or litigant asks is whether a person or entity exerted meaningful control over the protocol's parameters, fees, upgrade path or user-facing interface. Control is the doctrinal pivot. Where it exists, the case for liability follows conventional paths: the controller is either a regulated entity that failed to comply, a fiduciary that breached its obligations, or a common enterprise that attracted securities law scrutiny.
The Travel Rule (the obligation, under FATF Recommendation 15, to pass originator and beneficiary data with a virtual asset transfer) illustrates the point precisely. FATF and the regulators that implement its standards – including ESMA under MiCA, the FCA under the Money Laundering Regulations, and MAS under the Payment Services Act – expressly contemplate that a virtual asset service provider may be operating even where technology performs the matching or execution function. The entity that deploys, maintains or profits from that technology is the candidate VASP. The code alone is not.
The mis-classification risk runs in both directions. A team that structures aggressively around decentralisation may still find itself subject to regulatory action if a regulator determines that the founders retained de facto control. Conversely, a team that fails to plan the governance structure at all may inadvertently concentrate liability in a general partnership – a result with severe personal consequences for the individuals involved.
Are Protocol Developers Personally Liable?
Developer liability is the most acute concern in early-stage DeFi projects, and the answer depends on the theory of liability being advanced and the jurisdiction in which it is asserted. Under a tort or negligence theory in most common-law jurisdictions, a developer who writes and deploys code that causes foreseeable financial harm to identifiable users carries real exposure – particularly where the developer received compensation, retained administrative keys or continued to update the codebase post-launch.
The general-partnership theory is the most dangerous trap for unstructured development teams. Where two or more individuals carry on a business for profit without incorporating, most common-law and civil-law regimes will treat them as partners, jointly and severally liable for obligations arising from that business. A protocol that generates fees, even if those fees flow automatically to a treasury controlled by governance token holders, may constitute a business. Operators we advise routinely underestimate the severity of this risk in the pre-DAO formation period.
Securities law adds a further dimension. In the United States, the SEC and CFTC have both taken enforcement positions that treat protocol governance tokens as potentially constituting securities or derivatives, with the consequence that those who distributed them may have offered unregistered securities. The Howey test – whether there is an investment of money in a common enterprise with an expectation of profit from the efforts of others – has been applied to token distributions in a manner that has surprised many development teams. The "decentralisation" of a project at the time of sale does not, on its own, satisfy the analysis.
In our practice, we assess classification against the substance of rights conferred on the token holder, not the marketing label on the whitepaper. A token described as a "governance token" that confers pro-rata economic rights over protocol revenues will be examined differently than one that carries only a vote on fee parameters. The distinction matters enormously and cannot be settled by labelling alone.
The cross-border complication is that a single token distribution may simultaneously engage the securities laws of the United States, the MiCA regime in the European Union, and the MAS Payment Services Act in Singapore, depending on where the buyers are located and how the token is structured. There is no international safe harbour; each regime applies its own threshold test.
For a scoped assessment of your protocol's developer liability exposure – including the securities classification question and the general-partnership risk – contact OBOLUS at info@oboluslaw.com. The process above describes the standard analytical path. Your facts – the token structure, the development team's retained roles, the user base – change the analysis materially.
How Does a DAO Structure Affect Legal Liability?
A DAO – a decentralised autonomous organisation (a governance structure in which protocol parameters are controlled by token-weighted votes executed automatically through smart contracts) – creates a governance layer, but not automatically a liability shield. The legal question is whether the DAO has been wrapped in a recognised entity form that separates the obligations of the organisation from those of its members.
Without a legal wrapper, a DAO is almost certainly a general partnership or unincorporated association in any jurisdiction that examines the substance of the arrangement. That means every token holder who participates in governance – potentially thousands of individuals worldwide – is exposed to joint and several liability for the DAO's obligations. This outcome has been reached in at least one major US enforcement context, and regulators in leading hubs increasingly expect a formal legal entity to underpin any DAO that provides services to users or manages assets.
The available wrappers vary by jurisdiction. The most commonly considered structures in our advisory work are:
- A limited liability company in a jurisdiction that has enacted specific DAO-LLC legislation, providing that token-holder governance votes are binding on the entity and that members are not personally liable for entity obligations;
- A foundation structure in a civil-law jurisdiction such as Switzerland or Liechtenstein, which separates the protocol's governance from the commercial operations, holds the intellectual property, and employs the development team through a subsidiary;
- A Cayman Islands foundation company, which allows non-member governance and has become a common structure for protocols seeking an offshore holding point for the treasury while maintaining credible decentralisation;
- A Marshall Islands or Wyoming DAO LLC for protocols that wish to maintain on-chain governance as legally binding.
None of these structures eliminates liability for all actors in all circumstances. A foundation that retains direct control over protocol upgrades is not more insulated than a corporation that does the same. The structure reduces exposure for passive token holders, but it does not eliminate the exposure of those exercising meaningful control. The forensic question a regulator or litigant will ask is always the same: who decided, and when?
In a recent matter, we advised a protocol development team that had launched a DAO without formalising the governance structure as a legal entity. When a dispute arose with a liquidity provider, the absence of a legal person meant there was no counterparty capable of entering a settlement agreement and no clear authority to execute it. We worked through the post-hoc formation of a foundation structure and the migration of governance rights into it – a process that, while achievable, was materially more complex and expensive than upfront structuring would have been. The lesson, which we now incorporate into every early engagement, is that governance architecture should be settled before the first token is distributed.
Who Bears Liability When a Smart Contract Fails?
When a smart contract executes in a manner that causes financial loss, the liability question branches depending on whether the failure was a bug (a technical defect in the code), an exploit (deliberate manipulation by a third party), or a design error (the code performed as written but the economic design was flawed). Each branch attracts a different legal analysis.
A smart contract (self-executing code deployed on a blockchain that enforces predetermined conditions without intermediary intervention) is increasingly recognised as capable of forming a legally binding contract in most common-law and civil-law systems. Where it does, the question of who bears the loss from a malfunction turns first on the terms of any off-chain agreement between the parties and second on general contractual and tort principles: was there a warranty as to fitness? Was there negligence in the code's preparation? Was the exploit foreseeable?
The cross-border dimension here is acute. A smart contract bug that drains a liquidity pool may harm users in thirty jurisdictions simultaneously. Each user's claim is governed by its own applicable law, typically determined by where the user is located and whether any governing-law clause in the protocol's terms of service (if one exists and if it is enforceable) overrides that default. In practice, most DeFi protocols publish terms of service that disclaim all warranty for the code and specify an exclusive jurisdiction clause – but the enforceability of those terms against retail users is contested in multiple jurisdictions.
Under MiCA, a crypto-asset service provider that provides custody or exchange services is subject to specific rules on liability for loss of client assets, regardless of whether that loss was caused by a technical failure. The fact that a protocol is automated does not, of itself, relieve the operator of that statutory obligation. Regulators in the leading hubs – including ESMA and the FCA – have signalled that they will apply functional analysis: if an entity acts like a CASP, it will be regulated as one.
Audit reports have become a standard component of liability management. A protocol that publishes a clean audit from a recognised security firm, and that discloses any findings from that audit and the remediation steps taken, is in a materially better position in a later negligence claim than one that deployed unaudited code. That said, an audit does not transfer liability to the auditor, and auditors routinely limit their liability in their engagement terms to a figure well below the protocol's total value locked.
Is the Front-End Interface Operator Exposed?
Front-end operators occupy an often-overlooked but increasingly regulated position in the DeFi stack. A front-end website that provides a user interface to an otherwise decentralised protocol may itself constitute the operation of a virtual asset service, depending on the jurisdiction and the specific functions offered. This matters because the front-end is usually the most identifiable actor: it has a domain name, it is operated by a legal person, and it may have accepted the user's data and payments.
In the United States, FinCEN's guidance on money services businesses has been interpreted to cover entities that provide a user-facing service for virtual asset transfers even where the underlying matching or settlement occurs on a decentralised protocol. NYDFS's BitLicense regime takes a similar functional approach. In the EU, the MiCA CASP definition refers to entities that provide services "on behalf of clients" – a formulation that a front-end operator offering transaction routing may struggle to exclude itself from.
Operators we advise in this position typically face a choice between two structural approaches. The first is to obtain the relevant VASP or CASP authorisation and operate the front end as a regulated service. The second is to design the front end in a manner that genuinely does not constitute the provision of regulated services – for example, by limiting it to a read-only dashboard that links out to existing regulated interfaces. The second path is technically and commercially demanding; most front-end operators who attempt it find that the commercial proposition they want to deliver requires functionality that crosses the regulatory line.
Geo-blocking is a related instrument. A front-end operator that restricts access by users in jurisdictions where it is not licensed does reduce its regulatory exposure in those jurisdictions, but does not eliminate it. A regulator may take the view that the protocol itself – even without the front end – was accessible from its territory, or that the geo-block was easily circumvented and therefore not a meaningful restriction.
Cross-Border Liability: A Decision Matrix by Operator Profile
Liability exposure in decentralised systems does not aggregate neatly to a single risk figure; it depends on the profile of the operator, the structure of the protocol, and the jurisdictions engaged by the user base.
Profile A: Development team, no legal entity, token distributed globally. This is the highest-risk profile. General-partnership liability attaches to all active team members. Securities laws in the US, the EU and Singapore may treat the token distribution as an unregistered offering. The absence of a formal entity means there is no limited-liability shield. The indicative risk is personal liability of the founding members for all protocol obligations. The governing instrument to address this is immediate entity formation and a retrospective securities analysis.
Profile B: Cayman foundation holding the IP, DAO LLC handling governance, regulated front-end in a CASP jurisdiction. This structure separates the passive treasury function (the foundation), the active governance function (the DAO LLC) and the user-facing service (the regulated entity). Liability for regulatory failures concentrates in the regulated entity; the foundation and DAO LLC are insulated from claims that do not engage them directly. The residual risk is that a regulator determines the regulated entity has insufficient oversight of the protocol's actual operation. Timeline to implement this structure varies but is typically a matter of several months.
Profile C: Institutional DeFi – a bank or asset manager deploying tokenised assets through a permissioned protocol. Here the institution is already a regulated entity; the protocol is an infrastructure choice, not a regulatory category. The liability question shifts to the tokenisation framework – under MiCA, a token representing a real-world asset must be structured to satisfy either the ART (asset-referenced token) or the e-money token regime, or to fall outside both – and to the smart contract audit standard. Cross-border risk concentrates in the recognition of the token by foreign regulators. ESMA, the FSRA in ADGM and MAS each have guidance on the applicable tests.
Profile D: Aggregator or yield optimiser, no direct custody, operating across multiple protocols. This profile faces accumulation risk: exposure to the failures of underlying protocols compounded by its own potential VASP classification. In our cross-border practice, we have seen regulators treat yield optimisers as collective investment schemes, as CASPs and as money-service businesses – often in the same product. The key structural question is whether the aggregator holds client funds at any point in the transaction flow. If it does, the regulatory exposure is substantially higher.
If a prior compliance structure was built without reference to the specific regulatory exposure your protocol creates, a second-read analysis can surface the gap and map the route to a defensible position. Write to OBOLUS at info@oboluslaw.com.
Token Classification and the Liability It Creates
Mis-classifying a token can convert a product launch into an unregistered securities offering – a regulatory outcome with material civil and criminal consequences that no marketing label can undo after the fact. This is perhaps the most immediate liability trigger in the industry, and it is one that teams repeatedly underestimate because they conflate intent ("we did not intend to issue a security") with legal analysis ("the rights conferred on the holder created an investment contract").
The token classification question is a functional one in every major regime. The United States applies the Howey test; the EU MiCA regime distinguishes between asset-referenced tokens, e-money tokens and "other" crypto-assets, with each category attracting different disclosure and authorisation requirements; Singapore's MAS applies the securities laws to tokens that constitute "capital markets products"; Hong Kong's SFC applies a similar analysis under its own securities legislation.
A common assumption in the industry is that a utility label on a whitepaper settles the legal classification. It does not. Regulators assess the substance of the rights conferred. A token that grants holders a share of protocol fees, buybacks funded by protocol revenues, or a claim against a treasury is providing economic rights that courts in multiple jurisdictions have been willing to treat as investment interests. The label on the document does not change that analysis.
The cross-border dimension multiplies the exposure. A team based in Switzerland, distributing tokens to holders in the EU, the UK and the United States, must satisfy the token classification tests of FINMA, the relevant MiCA NCA, the FCA and the SEC simultaneously. These tests are broadly consistent in principle – substance over form – but differ in the specific criteria and in the remedial posture of the relevant regulator if a misclassification is detected.
In our advisory practice, the classification analysis is always document-based and prospective: we review the rights attached to the token as they will be structured, not as they are currently described in marketing materials. Where a structure creates genuine securities risk, the options are to restructure the token's rights to remove the investment-contract characteristics, to seek an exemption or no-action position in the relevant jurisdiction, or to proceed under the applicable securities regime with full regulatory compliance. Each path has different cost and timeline implications. None of them is available retrospectively once a challenged distribution has already occurred.
A Common Assumption: Decentralisation Means No Regulated Party
A common assumption among founders is that if the protocol is sufficiently decentralised at launch – no multisig, no admin key, no upgradeable contracts – there is no regulated party and therefore no liability. This assumption has not held in practice, for three structural reasons.
First, "sufficient decentralisation" is not a defined legal standard in any major jurisdiction. It is an enforcement discretion concept developed in the context of US securities law commentary. A regulator in the EU, Singapore or Hong Kong is not bound by it and may apply entirely different criteria to determine whether a protocol is operated by an identifiable entity.
Second, most protocols described as "fully decentralised" in fact retain upgrade paths, fee-switch mechanisms or oracle dependencies that give a small set of actors material control. Regulators and litigants are adept at identifying these control points; they have been the basis for enforcement action in multiple jurisdictions.
Third, even a genuinely autonomous protocol can give rise to liability claims from users. The theory of liability shifts from regulatory non-compliance to tort – negligent design, failure to audit, misrepresentation in the documentation – but the risk does not disappear. Under the applicable VASP provisions in the UK, the EU and Singapore, the entity providing access to the protocol is the primary regulatory target, not the underlying code, which means the front-end operator or the entity that marketed the product remains exposed even if the underlying protocol is genuinely autonomous.
Regulators in the leading hubs increasingly expect a legal entity behind any protocol that manages user assets, regardless of how the governance is structured. Where one does not exist, they have shown a willingness to attribute responsibility to the individuals they can identify – typically the developers and the holders of large governance-token positions.
Related at OBOLUS
- DeFi, Tokenization and Smart-Contract Law – our core practice covering protocol structuring, token classification and smart-contract governance across jurisdictions.
- Real-World Asset Tokenization for Regulated Entities – structuring tokenised RWA instruments under MiCA, ADGM and MAS frameworks.
- Corporate Tax Residency Planning in the Czech Republic – cross-border tax residency considerations for digital-asset holding structures in Central Europe.
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. Digital assets are the whole of our practice. We assess token classification against the substance of rights conferred, not the marketing label – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when a recovery clock is running. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology and DeFi Counsel – specialising in smart-contract governance, protocol liability analysis and token classification across multi-jurisdictional deployments.
FAQ
Can a DeFi protocol be regulated?
Yes. Regulation attaches to persons, not code. Regulators in the EU under MiCA, in Singapore under the Payment Services Act, and in the UK under the Money Laundering Regulations apply a functional test: if an entity operates, controls, deploys or provides access to a protocol that performs regulated activities, that entity is a regulated party regardless of how the underlying technology is structured. A protocol without any identifiable operator is theoretically beyond reach, but most commercial DeFi deployments retain control points that satisfy the functional test.
What legal wrapper suits a DAO?
The choice depends on the DAO's activity, user base and governance design. A Cayman foundation company is widely used for treasury-holding and passive governance functions. A Wyoming or Marshall Islands DAO LLC is suited to protocols that want on-chain votes to bind the entity as a matter of law. A Swiss or Liechtenstein foundation can separate IP holding from commercial operations. Without any wrapper, a DAO is typically treated as a general partnership in common-law jurisdictions, exposing all active members to joint and several liability. The appropriate structure should be selected before the first token is distributed.
Who is liable when a smart contract fails?
Liability depends on the nature of the failure and the identifiable actors in the deployment chain. Where a developer wrote, audited and deployed the contract, negligence and contractual warranty claims are possible. Where a front-end operator provided access to the contract, they may face regulatory liability if the activity constitutes a regulated service. Where no identifiable party exists, affected users face significant recovery difficulties. A clean security audit, transparent disclosure of known risks, and well-drafted terms of service all reduce – but do not eliminate – exposure across these scenarios.
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.