Civil Law and Crypto Asset Smart Contract Exploit Claims in Europe

1. Introduction

Crypto-asset smart contract exploit claims arise when a vulnerability, coding error, oracle manipulation, access-control failure, re-entrancy attack, private-key compromise, or other technical weakness in a blockchain-based smart contract causes users or investors to lose crypto-assets.

Typical disputes include:

DeFi protocol hacks;

token theft;

re-entrancy attacks;

flash-loan manipulation;

oracle-price manipulation;

unauthorised withdrawals;

defective smart-contract code;

compromised administrator keys;

faulty upgrade mechanisms;

bridge exploits;

loss caused by automated liquidation;

DAO governance attacks;

failures of custodial interfaces.

The European legal problem is difficult because code may execute automatically, while civil liability still requires identifying a legally responsible person or entity.

The EU's MiCA framework now provides a major regulatory framework for crypto-assets and crypto-asset service providers, although its scope has important exclusions and does not simply convert every DeFi smart contract into a regulated service. MiCA has applied generally since 30 December 2024, with the stablecoin provisions applying from 30 June 2024. (EUR-Lex)

2. What Is a Smart Contract Exploit?

A smart contract is software deployed on a blockchain that automatically performs transactions when programmed conditions are satisfied.

An exploit occurs when someone takes advantage of a weakness in that software or its surrounding infrastructure.

Common vulnerabilities identified in European regulatory analysis include:

mathematical errors;

programming or logic errors;

configuration mistakes;

weak access controls;

re-entrancy;

inadequate input validation;

oracle failures;

Layer-2 vulnerabilities;

compiler problems;

vulnerabilities inherited from interconnected or forked protocols. (ESMA)

Simple example

A DeFi lending protocol contains a faulty price oracle.

An attacker manipulates the price of Token X.

The smart contract believes Token X is worth €100 instead of €10.

The attacker borrows €50 million against the artificially inflated collateral.

The protocol automatically executes the transaction.

Users lose their funds.

The legal question becomes:

Who, if anyone, is civilly liable for the loss?

3. Difference Between Blockchain Error and Legal Wrong

A crucial distinction is:

Technical failure

The code did something unintended.

Legal breach

A person or organisation violated a legally enforceable duty.

A smart contract executing exactly according to its code does not necessarily mean that no legal claim exists.

Conversely, an undesirable economic result does not automatically establish civil liability.

The court must identify:

duty → breach → causation → damage → defendant → remedy.

4. European Legal Framework

Several legal regimes may overlap.

A. MiCA

Regulation (EU) 2023/1114 — Markets in Crypto-Assets Regulation (MiCA) regulates covered crypto-assets and crypto-asset services.

It contains provisions concerning:

crypto-asset issuers;

crypto-asset service providers;

market conduct;

investor protection;

information;

conflicts of interest;

custody;

complaints;

operational requirements.

MiCA expressly contains civil-liability provisions for misleading information in certain crypto-asset white papers. For example, Article 52 provides liability for issuers of e-money tokens where required white-paper information is incomplete, unfair, unclear or misleading and the statutory conditions are met. (ESMA)

5. MiCA Does Not Cover Everything

MiCA's scope must be examined carefully.

It excludes, among other things, crypto-assets that qualify as:

financial instruments;

deposits;

funds, subject to the specific e-money-token framework;

certain insurance products;

pension products.

It also excludes crypto-assets that are unique and non-fungible. (ESMA)

Therefore, a smart-contract exploit may instead fall primarily under:

national contract law;

tort/delict law;

property law;

unjust enrichment;

consumer law;

product liability;

financial-services regulation;

data-protection law.

6. DORA and Operational Resilience

For financial entities within its scope, the Digital Operational Resilience Act (DORA) is also relevant.

Smart-contract or blockchain infrastructure failures may raise questions concerning:

ICT risk management;

incident reporting;

third-party ICT providers;

operational resilience;

cybersecurity;

testing;

governance.

DORA has applied since 17 January 2025. (Finance)

7. Contractual Liability

A smart-contract transaction may involve several legal layers:

Legal agreement

Terms of service

Protocol documentation

Smart-contract code

Blockchain transaction

The court may need to determine which layer constitutes the legally binding agreement.

A developer or protocol operator may therefore face contractual liability where it expressly promised:

security;

custody;

correct execution;

asset protection;

accurate pricing;

reliable services.

8. Code Is Not Necessarily the Entire Contract

A central civil-law question is:

Does the computer code itself constitute the entire contractual agreement?

In some situations:

Code = contractual mechanism

while in others:

Legal agreement + code = contractual relationship.

For example, a platform may state:

“The protocol is entirely autonomous and users interact directly with code.”

But the same platform may simultaneously have:

a company;

website;

customer-support team;

governance structure;

fee recipient;

administrator;

identifiable developers.

A court will need to examine the substance of the relationship, rather than merely the label "decentralised."

9. Tort/Delict Liability

A claimant may argue that a developer, operator or service provider breached a general duty of care.

Possible allegations include:

negligent coding;

failure to patch a known vulnerability;

failure to warn users;

negligent oracle design;

inadequate security;

negligent custody;

negligent administration;

failure to respond to an exploit.

National European civil-law systems differ substantially regarding the precise requirements for delictual liability.

10. Product Liability

A particularly interesting question is whether smart-contract-related software can produce product-liability claims.

Modern software can form part of complex products and services.

Potentially relevant defects include:

defective software;

faulty cryptographic implementation;

defective hardware wallet;

defective security module;

faulty oracle;

defective bridge software.

The claimant must nevertheless establish the applicable statutory conditions and causal connection.

11. Unjust Enrichment

Suppose an attacker exploits a smart contract and obtains €10 million.

The claimant may seek restitution based upon:

unjust enrichment;

proprietary rights;

tracing;

constructive trust or equivalent remedies;

restitution of unjustly obtained assets.

This becomes particularly important where the attacker is unidentified.

12. Crypto-Assets as Property

The legal characterisation of crypto-assets is fundamental.

If a crypto-asset is recognised as property, the claimant can potentially seek:

proprietary injunctions;

freezing orders;

tracing;

restitution;

recovery of identifiable assets.

European courts have increasingly treated crypto-assets as capable of attracting property rights, although the exact classification differs between legal systems.

13. Cross-Border Character

Crypto transactions are naturally international.

A single exploit can involve:

victim in France;

developer in Germany;

exchange in Lithuania;

blockchain validators worldwide;

attacker in an unknown jurisdiction;

server infrastructure in Ireland.

Therefore, Brussels I bis, Rome I and Rome II may become relevant, depending upon the claim.

Questions include:

Which court has jurisdiction?

Which country's law applies?

Is there a consumer relationship?

Where did the damage occur?

Where is the crypto-asset legally situated?

Can the defendant be identified?

Can a judgment be enforced?

14. The Developer Liability Problem

One of the most difficult issues is whether developers owe duties to token holders.

Consider:

Developer A writes the original smart contract.
Developer B later maintains the protocol.
DAO C controls governance.
Company D operates the website.
Exchange E provides custody.

A hack occurs.

Who is responsible?

Potential defendants include:

developers;

protocol company;

DAO;

governance participants;

front-end operator;

oracle provider;

custodian;

exchange;

auditor;

infrastructure provider.

European courts are likely to examine actual control, conduct, representations and legal duties, rather than simply accept the label "decentralised." Comparative European legal commentary similarly notes that decentralisation does not automatically eliminate potential liability. (Global Practice Guides)

15. Case Law

Important qualification: There is still very little reported European case law directly deciding civil liability for a DeFi smart-contract exploit itself. Accordingly, the following authorities should be separated into direct cryptoasset authorities and analogous authorities concerning property, tracing, developers, online services and financial transactions.

This avoids treating ordinary crypto-fraud cases as if they were judgments on smart-contract coding liability.

Case 1 — AA v Persons Unknown

Case: [2019] EWHC 3556 (Comm)
Court: High Court of England and Wales
Classification: Direct cryptoasset authority

Facts

A company was hacked and Bitcoin was demanded as ransom. The insurer paid the Bitcoin and subsequently sought to trace and recover the cryptocurrency.

Principle

The court accepted that Bitcoin could constitute property capable of supporting proprietary remedies.

The court also granted relief directed at unknown persons and a cryptocurrency exchange.

Relevance

This is highly relevant to a smart-contract exploit because a victim may need to:

establish that stolen tokens are property;

trace them;

identify unknown attackers;

obtain freezing/proprietary relief;

approach exchanges holding the assets.

The judgment specifically involved tracing cryptocurrency after a hacking incident. (Bailii)

16. Case 2 — Tulip Trading Ltd v Bitcoin Association for BSV

Case: [2023] EWCA Civ 83
Court: Court of Appeal of England and Wales
Classification: Direct blockchain-developer authority

Facts

Tulip alleged that its Bitcoin was inaccessible following the loss or theft of private keys and argued that Bitcoin developers owed duties requiring them to take steps to help recover or safeguard the assets.

Principle

The Court of Appeal held, at the jurisdictional stage, that the pleaded case concerning possible fiduciary duties was sufficiently arguable to proceed.

The judgment recognised the unusual relationship between:

blockchain developers;

software;

digital assets;

owners of cryptocurrency.

The court also accepted that Bitcoin was property for the relevant jurisdictional analysis. (Courts and Tribunals Judiciary)

Relevance

This is one of the most important European authorities for the question:

Can blockchain developers owe legal duties to crypto-asset owners?

It does not establish that developers are automatically liable for every exploit.

Rather, it demonstrates that developer liability can present a genuine legal question depending upon the facts and alleged control.

17. Case 3 — Fetch.AI Ltd v Persons Unknown

Case: [2021] EWHC 2254 (Comm)
Court: High Court of England and Wales
Classification: Direct crypto-recovery authority

Facts

The claimants alleged that cryptocurrency had been misappropriated and sought urgent relief against unknown persons and cryptocurrency exchanges.

Principle

The court dealt with the procedural difficulties of identifying unknown crypto defendants and the need to structure claims so that:

the original wrongdoer;

persons controlling the assets;

and potentially innocent recipients

could be addressed appropriately.

Relevance

A smart-contract exploit may initially reveal only:

Wallet address → blockchain transaction → unknown recipient

Fetch.AI demonstrates how civil litigation can operate despite uncertainty concerning the identity of the wrongdoer. (rahmanravelli.co.uk)

18. Case 4 — Osbourne v Persons Unknown and Ozone Networks

Case: [2022] EWHC 1021 (Comm)
Court: High Court of England and Wales
Classification: Digital-asset/property authority

Facts

NFTs were allegedly transferred without the claimant's authorisation from her crypto-asset account.

Principle

The court accepted that there was at least a realistically arguable case that NFTs could constitute property and granted relief concerning the allegedly stolen digital assets.

Relevance

The case demonstrates how courts can adapt traditional proprietary remedies to blockchain-based assets.

The reasoning is relevant to tokens stolen through a smart-contract exploit. (Bailii)

19. Case 5 — D'Aloia v Persons Unknown Category A & Others

Case: [2024] EWHC 2342 (Ch)
Court: High Court of England and Wales
Classification: Direct crypto tracing authority

Facts

D'Aloia alleged that approximately £2.5 million in cryptocurrency had been obtained through fraud and transferred through multiple blockchain wallets and exchanges.

Principle

The court held that USDT is capable of attracting property rights and examined the principles of following and tracing cryptocurrency.

The case also demonstrates the evidentiary difficulty of proving that particular crypto-assets moved through a specific exchange wallet.

Relevance

This is highly relevant where an exploit causes tokens to move through:

victim wallet → attacker wallet → mixer/bridge → exchange → fiat conversion.

The claimant still needs sufficient evidence connecting the stolen assets to the defendant's possession or control. (Bailii)

20. Case 6 — Ion Science Ltd v Persons Unknown

Case: CL-2020-000840, judgment of 21 December 2020
Court: High Court of England and Wales
Classification: Crypto-fraud/tracing authority

Principle

The litigation concerned cryptocurrency fraud and tracing through blockchain transactions.

It is significant in the developing European cryptoasset jurisprudence because it illustrates the use of:

blockchain analysis;

proprietary claims;

tracing;

relief against unknown persons.

Relevance

Smart-contract exploit litigation similarly requires reconstruction of the transaction history to determine where the stolen tokens travelled.

The case is part of the developing line of European cryptoasset-property authorities. (orbilu.uni.lu)

21. Case 7 — Skatteverket v David Hedqvist

Case: C-264/14
Court: Court of Justice of the European Union
Classification: Direct EU cryptoasset authority, but not liability

Facts

The case concerned the exchange of Bitcoin for traditional currency.

Principle

The CJEU recognised Bitcoin transactions as involving a form of virtual currency used as a means of payment and held that specified Bitcoin-exchange services fell within the VAT exemption for currency transactions.

Relevance

Although this was a tax case, it is an important EU-level authority concerning the legal treatment of Bitcoin.

It provides context for determining how European law conceptualises cryptoasset transactions. (curia)

22. Case 8 — Lavinia Osbourne v Persons Unknown / Ozone Networks

This case is particularly useful for NFT and digital-asset recovery.

The claimant's NFTs were allegedly transferred without authorisation. The court considered proprietary relief and disclosure mechanisms against the platform.

Relevance to smart contracts

Where an exploit transfers an NFT automatically, the claimant may need:

proprietary relief;

identification of wallet holders;

disclosure from exchanges/platforms;

freezing orders.

The case illustrates how traditional equitable/proprietary remedies can operate in a blockchain environment. (Bailii)

23. Case Law Summary

These are not all civil-law cases in the continental European sense. The most developed European judicial jurisprudence on cryptoasset property and recovery has so far emerged from England and Wales. Continental European jurisdictions are increasingly addressing crypto disputes, but reported judgments specifically establishing liability for smart-contract exploits remain comparatively scarce.

24. Why Tulip Trading Is Particularly Important

The Tulip Trading litigation raises a question that is central to smart-contract exploit cases:

Can a person exercising substantial control over blockchain software owe duties to persons whose assets are controlled by that software?

Possible situations include:

Developers

Could owe duties if they exercise legally significant control.

DAO governors

Could potentially face different duties depending on governance arrangements.

Protocol operators

May have contractual or statutory responsibilities.

Front-end operators

Could have duties if they present themselves as service providers.

Custodians

Normally face more conventional contractual/custodial obligations.

The legal analysis must therefore examine the actual architecture.

25. Smart Contract Exploit and Negligence

A claimant might formulate the claim as:

“The defendant knew of a critical vulnerability but failed to patch or warn users.”

Potential elements include:

duty of care;

breach;

foreseeability;

causation;

damage.

Example

A developer discovers a critical re-entrancy vulnerability.

The developer has previously represented that the protocol is professionally maintained.

The developer does nothing.

An attacker exploits the vulnerability.

Users lose €20 million.

The central issue becomes whether the developer had a legally enforceable duty to act.

26. Re-Entrancy Exploit

A classic smart-contract vulnerability involves re-entrancy.

Simplified example:

Contract sends funds to attacker.

Attacker's contract calls back into the vulnerable function.

Original balance has not yet been updated.

Contract sends funds again.

Process repeats.

The technical exploit is relatively straightforward.

The legal analysis is more complicated:

Was the code defective?
Who controlled it?
Was the vulnerability known?
Was there a contractual security promise?
Was the loss foreseeable?
Did the victim accept protocol risk?

27. Oracle Manipulation

Smart contracts often depend upon external information called an oracle.

Example:

Oracle says ETH = €4,000

while the genuine market price is:

ETH = €2,000.

The smart contract automatically liquidates or lends based upon the false price.

Potential defendants could include:

oracle operator;

protocol developer;

DAO;

front-end provider;

infrastructure provider.

The central question becomes whether the oracle provider had a contractual or tortious duty concerning the accuracy and reliability of the information.

28. Flash-Loan Exploits

A flash loan permits borrowing and repayment within a single blockchain transaction.

An attacker can sometimes use temporary capital to manipulate:

liquidity pools;

token prices;

collateral values;

governance mechanisms.

The resulting loss may create claims involving:

fraud;

unjust enrichment;

restitution;

property;

negligence;

breach of contract.

However, the mere fact that an attacker used a technically permitted transaction does not automatically establish civil liability against protocol developers.

29. DAO Liability

A DAO presents an unusual civil-law problem.

Possible legal questions include:

Is the DAO a legal person?

Who is legally responsible?

Are governance participants jointly responsible?

Is there an underlying company?

Who receives protocol fees?

Who controls upgrades?

Who controls the website?

Who can change smart-contract parameters?

The label “DAO” does not by itself answer these questions.

The court must examine the actual legal and organisational structure.

30. Custodian Liability

A custodial crypto platform is legally different from a genuinely autonomous protocol.

If the custodian holds private keys, it may have conventional obligations concerning:

safeguarding;

segregation;

security;

authorisation;

execution;

record keeping.

MiCA contains specific regulatory obligations for covered crypto-asset service providers, while national civil law may supply additional contractual or delictual remedies.

31. Evidence

Smart-contract exploit cases are unusually dependent on technical evidence.

Important evidence includes:

smart-contract source code;

bytecode;

audit reports;

GitHub commits;

governance proposals;

blockchain transactions;

wallet addresses;

oracle records;

timestamps;

server logs;

private-key access records;

security warnings;

communications between developers;

bug reports;

incident-response records.

Blockchain evidence may establish what happened, but it does not automatically establish who is legally responsible.

32. Causation

Suppose a protocol contains a vulnerability but the attacker exploits a separate vulnerability in an oracle.

The developer may argue:

“Our code was not the legal cause of the loss.”

Therefore, expert evidence may need to identify:

Vulnerability → exploit → transaction → asset transfer → financial loss.

33. Contributory Negligence

A defendant may argue that the victim contributed to the loss.

Examples:

using an unaudited protocol;

ignoring security warnings;

exposing a private key;

interacting with an unverified contract;

signing a malicious transaction;

failing to activate available security measures.

The effect of claimant fault depends upon the applicable national law.

34. Smart Contract Disclaimer

A protocol might state:

“Use this protocol entirely at your own risk.”

Such language may be relevant but does not necessarily eliminate liability.

The court may consider:

whether the user was a consumer;

whether the term was transparent;

whether mandatory law applies;

whether fraud or intentional misconduct occurred;

whether the defendant made separate security representations;

whether the limitation is legally enforceable.

35. Consumer Protection

Where retail users interact with a professional crypto service, consumer legislation may become relevant.

Potential issues include:

unfair terms;

misleading statements;

hidden fees;

inadequate risk warnings;

unfair liability exclusions;

misleading marketing;

lack of information.

However, professional traders and institutional investors may receive different protection.

36. Remedies

A claimant may seek several remedies.

1. Proprietary injunction

Preventing dissipation of identifiable crypto-assets.

2. Freezing injunction

Restricting disposal of assets.

3. Tracing

Following stolen assets through blockchain transactions.

4. Restitution

Recovering unjustly obtained assets.

5. Damages

Compensation for legally recoverable loss.

6. Disclosure orders

Obtaining information from exchanges or intermediaries.

7. Declaration

Determining ownership of the crypto-assets.

8. Specific relief

Potentially requiring certain contractual or technological steps where legally justified.

37. Practical Example

Assume a European DeFi protocol contains a defective withdrawal function.

An attacker exploits the vulnerability and removes:

€25 million in ETH and stablecoins.

The victims bring proceedings.

Stage 1 — Identify the asset

Bitcoin/ETH/stablecoins are treated under the relevant national law as assets capable of legal protection.

Stage 2 — Identify the exploit

Experts establish that the withdrawal function contained a re-entrancy vulnerability.

Stage 3 — Identify responsible parties

Potential defendants:

protocol company;

developers;

DAO;

auditor;

oracle provider;

front-end operator.

Stage 4 — Establish duty

Was there:

contract?

statutory obligation?

professional duty?

duty arising from representations?

Stage 5 — Causation

Did the vulnerability cause the €25 million loss?

Stage 6 — Trace the assets

Blockchain analysis identifies:

Protocol → attacker wallet → bridge → exchange.

Stage 7 — Obtain relief

The victims seek:

freezing;

proprietary relief;

disclosure;

restitution;

damages.

38. Core Legal Formula

For examination purposes:

Smart Contract

↓

Exploit

↓

Identify Asset

↓

Identify Responsible Person

↓

Contract / Tort / Property / Regulation

↓

Breach or Defect

↓

Causation

↓

Damage

↓

Tracing

↓

Jurisdiction

↓

Applicable Law

↓

Remedy

39. Important Defences

A defendant may argue:

no contractual relationship;

no duty of care;

code operated exactly as programmed;

exploit was unforeseeable;

claimant accepted protocol risks;

third-party attacker caused the loss;

claimant failed to mitigate;

claimant contributed to the loss;

assets cannot be traced;

defendant did not possess the stolen assets;

jurisdiction is inappropriate;

contractual limitation applies.

40. Key Legal Distinction

The most important distinction is:

“The smart contract was exploited”

does not automatically mean

“The developer is legally liable.”

The claimant must connect the technical failure to a legally enforceable obligation.

Likewise:

“The blockchain transaction is irreversible”

does not necessarily mean

“The victim has no legal remedy.”

The cases concerning Bitcoin, NFTs and USDT demonstrate that courts can use traditional concepts such as property, tracing, injunctions, restitution and disclosure in disputes involving blockchain assets. (Bailii)

41. Quick Revision Table

42. Conclusion

Crypto Asset Smart Contract Exploit Claims in Europe represent an emerging area where traditional civil-law principles meet blockchain technology.

The strongest established principles are currently found in the jurisprudence concerning crypto-assets as property, tracing, fraud, unknown defendants and blockchain developers, rather than in a large body of judgments specifically deciding DeFi-code liability.

The most significant authorities include AA v Persons Unknown, Tulip Trading, Fetch.AI, Osbourne, D'Aloia, Ion Science, and the CJEU's Hedqvist decision. The particularly important development is that courts can treat crypto-assets as legally protectable property and can apply conventional remedies such as proprietary relief, tracing, freezing orders and restitution, while Tulip Trading demonstrates the unresolved but significant question of when blockchain developers may owe duties to asset holders. (Bailii)

The central civil-law formula is:

Technical exploit + legally identifiable duty + breach + causation + identifiable loss + responsible defendant = potential civil liability.

At the same time, MiCA and DORA now provide an important EU regulatory layer, meaning future European litigation will increasingly involve the interaction between smart-contract code, traditional private law and technology/financial regulation. (Finance)