Oracle failures do not always look like failures. A price feed stalls, a liquidation cascade fires, and by the time counsel is engaged the loss has already settled on-chain. Under United Kingdom law, the question of who bears that loss turns on a set of overlapping analyses – contract, tort, financial regulation, and token classification – that most operators in the DeFi space have not mapped before the incident occurs. This page works through each layer in sequence, identifies the decision points that matter for a business building or integrating data-feed infrastructure in or from the UK, and closes with the practical steps counsel takes at each stage.
What is an oracle, and why does it create legal exposure?
An oracle (in the DeFi context, a system that delivers off-chain data – prices, rates, event outcomes – to an on-chain smart contract) is the point at which the legal world and the on-chain world meet most violently. The oracle is not the smart contract itself; it is the instruction the contract relies on. When that instruction is wrong, stale or manipulated, losses can be immediate and irreversible. Under English law, the entity that supplied the data, the entity that selected and integrated it, and the entity that designed the contract logic around it may each face distinct claims.
The FCA (Financial Conduct Authority) has made clear that the regulated-activities perimeter in the UK does not stop at a product's technical architecture. If the output of an oracle feeds a contract that performs a function equivalent to a regulated activity – executing orders, managing assets, providing investment advice – the oracle operator may be inside the perimeter even if no one designed it that way. That is the first liability layer. The second is common-law tort: negligent misstatement, as established in principle under English law, can attach to a party that supplies information knowing it will be relied upon, without a direct contract. The third layer is the contractual one, which turns on what, if anything, was agreed between the oracle provider, the protocol, and the ultimate user.
Mis-classifying a token can convert a product launch into an unregistered securities offering – and the same principle applies to data infrastructure: mis-classifying an oracle's function can place an operator inside a regulatory perimeter they believed they were outside. This page maps that perimeter for a UK-connected business.
How does the UK regulatory perimeter apply to data-feed infrastructure?
The FCA applies a substance-over-form test to determine whether an activity is regulated, and that test catches infrastructure providers as well as front-end operators. A business that runs a price oracle feeding a derivatives settlement contract may be performing activities that look, in substance, like market infrastructure for a financial instrument. Under the applicable provisions of the Financial Services and Markets Act regime, providing systems or services ancillary to a regulated activity can itself attract a regulated-status question. No article number is needed to understand the principle: if the oracle is integral to the execution or settlement of a transaction in a specified investment, the operator needs to have taken legal advice, not merely reviewed a technical whitepaper.
The UK's cryptoasset registration regime under the Money Laundering Regulations applies primarily to cryptoasset exchange providers and custodian wallet providers, and an oracle that does not itself hold or transfer assets may sit outside that specific registration trigger. But that finding does not end the analysis. The financial-promotion rules – which the FCA has actively enforced in the crypto sector – can apply to communications about a DeFi protocol that uses the oracle, if those communications amount to a financial promotion and are made from or into the UK. An oracle operator whose documentation describes the financial outcomes a protocol can achieve may be issuing or approving a financial promotion without a licence. These two regulatory angles – activity regulation and financial promotion – are the first pair of issues any UK-connected oracle business must address.
The process begins with a classification exercise: is the data the oracle provides linked to a specified investment, a regulated activity, or both? That classification determines which FCA regime, if any, applies. It also determines whether the business needs FCA authorisation, a s.21 financial promotion approval from an authorised person, or neither.
For a scoped classification assessment of your oracle or data-feed infrastructure, contact OBOLUS at info@oboluslaw.com. The process above describes the standard analysis. Your specific facts – what data you supply, to which contracts, and where your users sit – change the conclusion.
Does English tort law reach oracle data errors?
English tort law can reach the provider of inaccurate financial data where the elements of negligent misstatement are present. The principle, well-established in English common law, requires that the defendant assumed responsibility for the accuracy of the information, that the claimant relied on it, and that the reliance was reasonable in the circumstances. An oracle operator that markets its feed as reliable, enterprise-grade data for DeFi protocols is building exactly that factual matrix.
In our practice, we have seen operators dismiss this risk on the basis that on-chain code is "self-executing" and no one "relied" on them in a legal sense. That reasoning is not sound. English courts take a functional view of reliance. If a smart contract is designed to execute a liquidation the moment an oracle price crosses a threshold, a protocol designer who integrated that oracle has arguably relied on its accuracy in exactly the sense the tort requires. The counterargument – that reliance on an automated process is not reliance on a representation – has not been definitively tested in UK litigation in this specific context. The absence of precedent is not the same as safety.
Two structural factors amplify the risk. First, oracles are often off-chain or hybrid systems with identifiable legal persons behind them – a company, a foundation, or a DAO (decentralized autonomous organization). English law has tools to reach all three. Second, the Misrepresentation Act regime provides a statutory overlay in contractual contexts: where a protocol's terms of service create a contractual relationship with oracle providers, misrepresentation claims in contract may be easier to advance than pure tort claims. A well-drafted limitation-of-liability clause in the oracle provider's terms does not extinguish the claim; it shapes the quantum and the route, not the legal basis.
Who is liable when a smart contract failure is driven by bad data?
When a smart contract executes incorrectly because of a data-feed failure, liability may attach to the oracle provider, the protocol operator, the integration developer, or all three, depending on the contractual architecture and the facts. This is the question that DeFi legal analysis in the UK has begun to work through seriously, and operators we advise routinely face it when designing governance and liability-allocation arrangements for new protocols.
The starting point is the contract chain. Most DeFi protocol documentation includes terms of service that disclaim liability extensively. English courts will enforce clear, unambiguous exclusion clauses between commercial parties of roughly equal sophistication, subject to the reasonableness test under the Unfair Contract Terms Act regime. But that test can be demanding, particularly where the exclusion covers the provider's own negligence. An oracle provider that excludes liability for manipulation of its own feed by a third party is in a different position from one that excludes liability for errors in its own data-aggregation methodology. The distinction matters enormously in a claim.
The second layer is indemnity allocation. Protocols that integrate third-party oracles without a written data-supply agreement have no indemnity ladder at all. They carry the full loss if the oracle data causes a protocol failure, because there is nothing to assign upstream. In our cross-border practice, this gap – no written agreement between oracle and protocol, only an API integration – is one of the most common structural problems we identify at the pre-dispute review stage.
The third layer is DAO-specific. Where the protocol is governed by a DAO (decentralized autonomous organization), the absence of a legal wrapper can mean that losses caused by a protocol failure fall on individual token holders or governance participants. English law does not yet have a DAO-specific statute, but the general-partnership analogy is one that courts and regulators have applied in analogous contexts, with significant implications for personal liability.
How does cross-border structure interact with UK oracle liability?
Almost no DeFi protocol is a single-jurisdiction business. The oracle provider may be a Swiss foundation; the protocol may be governed by a Cayman DAO; the users may be predominantly in the EU; the developer team may be UK-based. English law can reach into that structure if the harm is felt in England, if the wrongful act occurred here, or if there is a submission to English jurisdiction in any contract in the chain. The cross-border reality for a UK-connected oracle business is that the FCA's regulatory perimeter and English courts' jurisdiction operate independently of where the business is incorporated.
This has direct implications for structuring. A BVI or Cayman entity operating a data-feed business with a UK-based development team, UK users, or UK-origin financial promotions is not outside FCA reach simply because the legal entity is offshore. The FCA has repeatedly signalled that it will apply its perimeter to overseas entities where UK consumers are affected. The BVI FSC and CIMA regimes provide their own registration and licensing frameworks for VASP activities, but they do not insulate a business from UK obligations where a genuine UK nexus exists.
For tax, the cross-border structure of an oracle business – where fees are paid to a foreign entity but the value-generating activity is in the UK – raises transfer-pricing questions and potential permanent-establishment exposure under HMRC's rules for digital services. The token classification of any fee token the oracle issues is a separate UK tax question. Neither analysis can be deferred until the first revenue cycle.
Banking is the third cross-border pressure point. UK banks and EMI-licensed payment institutions have become significantly more cautious about servicing DeFi-adjacent businesses since the FCA's enhanced scrutiny of cryptoasset firms. An oracle business that cannot demonstrate regulatory clarity – that it has worked through the FCA perimeter analysis and landed in a documented position – will find account opening difficult. We have seen businesses with otherwise strong commercial profiles lose banking relationships because their regulatory analysis was either absent or drafted too loosely to satisfy a bank's compliance function.
If the cross-border dimension of your oracle or DeFi structure is creating friction – regulatory, banking or tax – write to OBOLUS at info@oboluslaw.com. If a prior application stalled or an account was closed, a second read can surface the structural reason and the route forward.
How does UK token classification affect oracle and DeFi products?
Token classification under UK law determines the regulatory perimeter, the tax treatment, and the disclosure obligations for every token involved in an oracle or DeFi product. A common assumption is that attaching a "utility" label to a token in a whitepaper resolves the classification question. It does not. The FCA applies a substance-over-form analysis: what rights does the token actually confer? If those rights resemble the rights of a security – profit participation, governance entitlement, an expectation of return driven by others' efforts – the token may be a specified investment regardless of the label.
For oracle businesses specifically, the classification question arises in at least three places. First, any token used to pay for oracle services or to govern the oracle network must be classified. Second, any token the smart contract settles in – stablecoins, synthetic assets, wrapped tokens – carries its own classification question. Third, governance tokens issued to oracle operators or validators may themselves cross into the security perimeter depending on their design.
The practical consequence is that a DeFi protocol that integrates an oracle without classifying the underlying tokens is not in a position to defend a regulatory challenge from the FCA, to pass a banking compliance review, or to structure its liability framework properly. We assess classification against the substance of the rights conferred, not the marketing label – and that assessment has to precede the product build, not follow the regulator's inquiry.
What are the practical steps for managing oracle liability in the UK?
Managing oracle and data-feed liability in the UK follows a defined sequence, and the order matters because each step conditions the next.
Step 1 – Regulatory perimeter mapping. Identify every token in the structure, every activity the oracle performs, and every financial promotion the business or its integrators make from or into the UK. Plot each against the FCA's perimeter. The output is a written position paper that can be shared with banks, investors, and regulators if needed.
Step 2 – Contractual architecture review. If there is no written data-supply agreement between the oracle provider and the protocol operators, create one. It should address: data accuracy warranties (and their limits), liability caps structured to survive the reasonableness test, indemnity flows if third-party manipulation occurs, and governing law and jurisdiction. English law and the English courts are a defensible choice for this agreement, given England's developed case law on information services and financial data.
Step 3 – DAO or entity wrapper decision. If the protocol is governed by a DAO, decide whether to wrap it in a recognised legal entity. The Cayman Islands foundation company and the BVI company structures are the most commonly used wrappers for DeFi protocols with a UK nexus; the BVI FSC and CIMA frameworks each have their own compliance consequences, but both provide the legal personality that a DAO lacks. For UK-based teams, a UK company may itself be appropriate, but that decision requires the FCA perimeter analysis first.
Step 4 – AML and Travel Rule assessment. Where the oracle forms part of a transfer-of-value flow, the Travel Rule (the FATF obligation to pass originator and beneficiary data with a transfer) may apply to the protocol operator. Under the UK's implementation of FATF Recommendation 15, cryptoasset businesses are required to collect and transmit counterparty data for transfers above the applicable threshold. The oracle is not the VASP, but the protocol it feeds may be, and that determination needs to be made before launch.
Step 5 – Banking and payment-account preparation. Prepare a regulatory-clarity pack for banking: the perimeter position paper, the entity structure diagram, the FCA registration or exemption rationale, and the AML framework documentation. UK banks require this in substance even if they do not call it by that name. Businesses that approach a bank with a clean pack close accounts faster and with fewer disruptions than those that address compliance questions reactively.
Step 6 – Ongoing monitoring. The FCA's policy position on DeFi and cryptoasset regulation is active and developing. The transition from the existing regime toward potential future legislation – under the regime that the UK Treasury has been developing for the cryptoasset sector – means that a position that is correct today may require reassessment within a cycle. Build a review trigger into the compliance calendar.
A practical illustration
In a recent cross-border DeFi matter, a token-issuing company operating from a common-law offshore jurisdiction integrated a third-party price oracle into its lending protocol without a written data-supply agreement or a UK regulatory perimeter analysis. When the oracle delivered a stale price during a period of high market volatility, the protocol's automated liquidation engine fired against collateral positions that were not genuinely under-collateralised. Users in multiple jurisdictions – including the UK – suffered losses. We were engaged to conduct a rapid perimeter review and to advise on the liability allocation between the protocol operator and the oracle provider. The absence of any contractual document between the parties left the operator carrying the full exposure, with no indemnity to assign upstream. A commercial settlement was reached within the protocol's governance structure, but the absence of contractual architecture at the outset was the single most consequential structural failure. We have since advised the same operator on a redesigned data-supply agreement and a DAO-to-foundation migration. The second structure is materially more defensible.
Which operator profile needs which approach?
The right set of steps depends on the operator's profile and position in the data-feed chain.
Profile A – Pure oracle provider (no protocol operation). The key risk is negligent-misstatement liability and, where the feed touches a regulated instrument, FCA perimeter exposure. The priority is a defensible terms-of-service document, a liability-limitation structure that survives the reasonableness test, and a perimeter analysis. Timeline for a thorough written position: typically a matter of weeks depending on the complexity of the token universe and the scope of UK activities.
Profile B – Protocol operator using a third-party oracle. The priority is a written data-supply agreement upstream and a liability-capping structure in the protocol's own terms downstream. The DAO-wrapper question and the FCA perimeter question arise here as well. Where the protocol issues a governance or fee token, the classification analysis must precede any public distribution. Timeline: the perimeter analysis and contractual suite together typically take several weeks for a straightforward protocol; more complex structures with multiple tokens and jurisdictions require a longer scoping phase.
Profile C – Integrated operator (both oracle and protocol). This profile carries the broadest exposure because there is no contractual party to assign risk to. The entire liability stack sits with one entity. The FCA perimeter question is most acute here, as is the financial-promotion analysis. The priority is the regulatory classification first, then the entity and governance structure, then the contractual suite for any third-party integrators who build on the operator's oracle. Where UK users are in scope, FCA engagement or authorised-person oversight of financial promotions may be unavoidable.
Does a non-UK entity avoid UK liability?
A common assumption is that incorporating outside the UK – in the Cayman Islands, BVI, Switzerland, or elsewhere – removes a business from the FCA's reach and from English-law liability. That assumption is incorrect as a general matter. The FCA applies its perimeter to the activity, not the entity's place of incorporation. An overseas company providing data feeds to UK users, running a UK-targeted financial promotion, or employing UK-based development staff with meaningful operational responsibility may be inside the regulated perimeter regardless of where the legal entity sits. English courts similarly take jurisdiction over overseas defendants where the harm occurred in England, where a contract governed by English law is in dispute, or where a defendant can be served here. The entity structure affects the practical ease of enforcement and the insolvency consequences – it does not create a liability shield.
The more defensible position is to conduct the perimeter analysis honestly and then choose the entity structure that best manages the regulatory and liability profile, rather than choosing an offshore structure in the hope that geography will do legal work it cannot do.
Related at OBOLUS
- DeFi, tokenization and smart-contract law – our full practice overview for protocol operators and token issuers
- NFT project legal structuring for regulated entities – structuring NFT issuances within the regulatory perimeter
- Payment institution licensing in Abu Dhabi Global Market (ADGM) – licensing under the FSRA regime for payment-adjacent DeFi businesses
FAQ
Can a DeFi protocol be regulated?
Yes. The FCA applies a substance-over-form test: if a DeFi protocol performs activities that amount to a regulated function – such as executing transactions in specified investments, managing assets, or facilitating payment services – it may fall within the regulatory perimeter regardless of its technical architecture. The fact that the protocol is automated or on-chain does not, by itself, place it outside FCA oversight. Whether a specific protocol is regulated depends on what it does and who its users are.
What legal wrapper suits a DAO?
The choice depends on the DAO's activities, its governance model, and where its members and users are located. The Cayman Islands foundation company and the BVI company are the most widely used structures for DeFi protocols with international user bases. They provide legal personality, limited liability, and a governing-law framework without requiring the DAO to be treated as a general partnership. UK-incorporated wrappers are also possible but require a prior FCA perimeter analysis to assess the regulatory consequences of UK incorporation.
Who is liable when a smart contract fails?
Liability for a smart-contract failure caused by a data-feed error may attach to the oracle provider (under negligent-misstatement principles or contract), the protocol operator (under its own terms with users), the integration developer (if a technical error caused the mis-execution), or the DAO governance body (in limited circumstances). The contractual architecture between those parties determines how liability is allocated and whether any of it can be assigned or capped. Where there is no written agreement, the operator closest to the user typically carries the residual loss.
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 classification against the substance of rights conferred, not the marketing label, and we structure licensing, banking and tax as one mandate rather than three disconnected workstreams. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialising in smart-contract liability, oracle infrastructure, and DeFi regulatory analysis for UK-connected digital-asset businesses.
To pressure-test your oracle or DeFi structure before you commit to a build or a launch, message us via t.me/oboluslaw or write to info@oboluslaw.com.
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.