Civil Law – Smart Contract Failure Claims

1. Introduction

Smart Contract Failure Claims concern legal disputes arising when a blockchain-based or computer-executed agreement does not perform as intended, executes incorrectly, becomes technically defective, produces an erroneous result, or causes loss because of defective code, faulty data, oracle failure, cyberattack, programming error, or failure of a party or platform to perform its legal obligations.

A smart contract is generally a computer program deployed on a blockchain that automatically performs specified actions when predetermined conditions are satisfied. Importantly, a smart contract is not necessarily identical to a legally enforceable contract. The code may implement the performance mechanism, while the underlying legal agreement may exist in natural-language terms, platform terms, or a combination of text and code.

In India, there is presently no comprehensive statutory regime specifically governing smart-contract failures. Their legal treatment must therefore be developed principally through:

• Indian Contract Act, 1872;
• Information Technology Act, 2000;
• Bharatiya Sakshya Adhiniyam, 2023;
• Specific Relief Act, 1963;
• Consumer Protection Act, 2019;
• Sale of Goods Act, 1930, where applicable;
• law of restitution and unjust enrichment;
• tort law;
• arbitration law;
• property law concerning digital assets;
• constitutional principles where public authorities are involved.

Indian scholarship also recognises that existing contract and electronic-commerce legislation can accommodate many smart-contract transactions, but questions remain concerning code-based consent, automatic execution, mistakes, remedies and statutory compatibility.

2. What Is a Smart Contract?

A simplified smart-contract transaction can be represented as:

Agreement → Code → Blockchain deployment → Trigger → Automatic execution → Digital transfer

For example:

“If Party A delivers the verified digital asset by 1 October, release ₹10 lakh worth of digital payment to Party A.”

The smart contract may automatically verify a specified condition and execute payment.

The legal difficulty arises when:

What the code does ≠ what the parties legally intended.

That difference is the foundation of many smart-contract failure claims.

3. Meaning of Smart Contract Failure

A smart contract may “fail” in several different ways.

1. Coding failure

The programmer writes defective code.

2. Execution failure

The blockchain does not execute the intended transaction.

3. Oracle failure

The smart contract receives incorrect external information.

4. Cyberattack

A hacker exploits a vulnerability.

5. Logic failure

The code performs exactly what it was programmed to do, but the result is inconsistent with the parties' legal intention.

6. Interface failure

The user enters incorrect information through a website or application.

7. Blockchain failure

A network problem, congestion, fork or protocol issue affects execution.

8. Legal failure

The transaction executes technically but violates:

• statute;
• public policy;
• sanctions;
• consumer law;
• property law;
• regulatory requirements.

9. Immutability problem

The code automatically executes an irreversible transaction even though one party later discovers an error.

4. Central Legal Question

The central question is:

When code automatically executes a transaction, does the law enforce the code, the underlying agreement, or the legally determined intention of the parties?

The answer should ordinarily depend upon ordinary principles of contract law.

The fact that a transaction is executed by software does not automatically remove it from contract law.

5. Indian Contract Act, 1872

The Indian Contract Act provides the principal framework.

Section 2

It establishes fundamental concepts including:

• proposal;
• acceptance;
• promise;
• consideration;
• agreement;
• contract.

Section 10

An agreement becomes a contract when the statutory requirements of validity are satisfied.

Sections 11–12

Concern:

• capacity;
• competency;
• soundness of mind.

Sections 13–14

Concern:

• consent;
• free consent.

These provisions become particularly important in smart-contract disputes because a person may technically interact with code without understanding its consequences.

6. Sections 15–18: Defective Consent

Smart-contract failure may involve:

• coercion;
• undue influence;
• fraud;
• misrepresentation;
• mistake.

For example, if a smart-contract transaction was induced through fraudulent coding or a false representation about the consequences of execution, ordinary contractual remedies may become relevant.

7. Section 20: Mutual Mistake

Section 20 becomes particularly interesting where both parties are mistaken about a fundamental fact.

Example:

A smart contract automatically transfers a token believing that an external event has occurred, while both parties actually understand that event differently.

If the statutory requirements for mistake are satisfied, the underlying agreement may be affected despite technically flawless blockchain execution.

8. Section 23: Unlawful Object

A smart contract cannot become legally enforceable merely because:

“The blockchain executed it.”

If the object or consideration is unlawful, opposed to public policy, or prohibited by law, Section 23 may become relevant.

Therefore:

Blockchain immutability cannot override mandatory law.

9. Section 28: Restraint of Legal Proceedings

Smart-contract platforms frequently contain arbitration and dispute-resolution clauses.

Such clauses must comply with applicable Indian law.

A code-based mechanism cannot completely eliminate legally protected remedies merely by preventing a user from accessing a court.

10. Sections 37, 39 and 55

These provisions are relevant to performance.

Section 37

Parties must perform contractual promises.

Section 39

Deals with refusal or disabling oneself from performing.

Section 55

Concerns failure to perform at the stipulated time where time is essential.

These provisions become important where:

• the code fails;
• an oracle fails;
• a party deliberately prevents execution;
• off-chain obligations are not performed.

11. Sections 73 and 74

These provisions are particularly important for remedies.

Section 73

Provides compensation for loss caused by breach of contract.

Section 74

Deals with stipulated compensation/penalty.

Therefore, where a smart contract fails and causes demonstrable loss, the claimant may seek contractual damages, subject to ordinary principles of causation, remoteness and proof.

12. Smart Contract vs Traditional Contract

The crucial point is:

Automation changes the mechanism of performance, not necessarily the underlying legal obligations.

13. Major Types of Smart Contract Failure Claims

A. Defective Code Claim

The claimant argues:

“The program contained a defect that caused financial loss.”

Possible defendants include:

• developer;
• platform;
• deployer;
• auditor;
• service provider.

The claimant must establish the relevant legal relationship and applicable duty.

14. Oracle Failure Claims

Many smart contracts depend upon an oracle.

An oracle supplies external information such as:

• price;
• temperature;
• exchange rate;
• delivery status;
• election result;
• market event.

If the oracle provides incorrect information, the smart contract may execute incorrectly.

Potential claims include:

• breach of contract;
• negligence;
• misrepresentation;
• restitution;
• unjust enrichment.

15. Hacking and Cyberattack

Suppose a hacker exploits a coding vulnerability and drains digital assets.

Potential legal questions include:

1. Was the platform negligent?
2. Did it promise security?
3. Was the vulnerability reasonably foreseeable?
4. Did the platform breach contractual security obligations?
5. Can the stolen digital assets be traced?
6. Can restitution or a proprietary injunction be obtained?
7. Who has jurisdiction?

These issues have already arisen in cryptocurrency litigation.

16. Automated Mistake

One of the most difficult problems is:

What happens when software executes a transaction that no reasonable human would have intended?

This was directly examined in the Singapore litigation involving algorithmic cryptocurrency trading.

17. Case Law 1 – Quoine Pte Ltd v B2C2 Ltd

[2020] SGCA(I) 02

This is the leading comparative authority for smart-contract/algorithmic transaction disputes.

B2C2 and Quoine operated a cryptocurrency trading platform. Due to a technical problem, trades occurred at extraordinarily abnormal exchange rates—approximately 250 times the prevailing market rate. The transactions were automatically executed by computer algorithms. Quoine subsequently reversed the transactions.

The dispute concerned:

• contractual validity;
• unilateral mistake;
• automated contracting;
• implied contractual terms;
• breach of contract;
• unjust enrichment;
• cryptocurrency.

The Singapore Court of Appeal ultimately upheld the breach-of-contract finding against Quoine while reversing the trust aspect of the lower court's decision.

Importance

The case demonstrates that:

A computer-generated transaction does not exist outside ordinary contract law.

Courts can examine:

• contractual terms;
• intention;
• mistake;
• system architecture;
• circumstances of automated execution.

It is one of the strongest comparative authorities for Indian smart-contract litigation.

18. Case Law 2 – B2C2 Ltd v Quoine Pte Ltd

[2019] SGHC(I) 03

The first-instance decision in the Quoine litigation is independently important.

The court considered whether automatically generated cryptocurrency trades could constitute binding contracts and whether Quoine had contractual authority to reverse them.

The court concluded that the reversal breached the contractual arrangement and awarded damages, while refusing specific performance.

Principle

A platform cannot necessarily undo an automatically executed transaction simply because it later considers the transaction commercially abnormal.

The contractual terms governing the platform remain crucial.

19. Case Law 3 – AA v Persons Unknown

[2019] EWHC 3556 (Comm)

This English High Court case concerned Bitcoin paid following a ransomware attack.

The court considered whether Bitcoin constituted property capable of supporting a proprietary injunction.

The court held that Bitcoin could constitute property for purposes of the proprietary remedy and granted relief concerning the cryptocurrency.

Importance for smart-contract claims

The case demonstrates that courts can treat digital assets as legally significant property capable of supporting traditional civil remedies.

This matters where a smart-contract failure results in:

• wrongful transfer;
• hacking;
• misappropriation;
• tracing problems.

The legal system therefore need not treat blockchain assets as legally invisible.

20. Case Law 4 – Tulip Trading Ltd v Van der Laan

[2023] 4 WLR 16 (CA)

This English Court of Appeal litigation concerned alleged duties owed by blockchain developers in relation to access to digital assets.

The dispute raised important questions concerning:

• blockchain governance;
• developer responsibility;
• fiduciary duties;
• property;
• digital asset recovery.

The case is important because it illustrates the possibility that developers and infrastructure participants may become defendants in civil litigation, although the precise legal duty depends upon the facts and applicable law.

It demonstrates that decentralised technology does not automatically eliminate the possibility of identifying legally relevant human or corporate actors.

21. Case Law 5 – Soleymani v Nifty Gateway LLC

[2022] EWHC 773 (Comm)

This English case involved an NFT transaction and an arbitration dispute.

Although not a pure smart-contract failure case, it is important for blockchain-based contractual relationships.

It concerned questions involving:

• NFT transactions;
• contractual terms;
• arbitration;
• jurisdiction;
• consumer/procedural protections.

Principle

The existence of blockchain technology does not automatically determine:

• governing law;
• jurisdiction;
• arbitration;
• enforceability.

Ordinary private-law principles continue to matter.

22. Case Law 6 – Vorotyntseva v Money-4 Ltd

[2018] EWHC 2596 (Ch)

The English High Court dealt with cryptocurrency and interim proprietary relief.

The case is important for establishing that courts can grant conventional civil remedies involving cryptocurrency assets.

Relevance

Where smart-contract execution causes an allegedly wrongful transfer, the claimant may seek:

• injunction;
• freezing order;
• proprietary relief;
• tracing;
• disclosure.

Therefore, blockchain technology does not necessarily make civil remedies impossible.

23. Case Law 7 – Trimex International FZE Ltd v Vedanta Aluminium Ltd

(2010) 3 SCC 1

This is a very important Indian analogue.

The Supreme Court recognised that a binding commercial contract can arise through electronic communications, including exchanges of communications demonstrating offer, acceptance and intention to contract.

Smart-contract relevance

A smart contract does not necessarily need a traditional paper document.

If the legal requirements of:

• offer;
• acceptance;
• consideration;
• intention;
• certainty

are satisfied, electronic communications can form a binding contract.

Principle

Electronic form does not by itself destroy contractual validity.

This provides an important foundation for recognising legally enforceable blockchain transactions in India.

24. Case Law 8 – Shakti Bhog Foods Ltd v Kola Shipping Ltd

(2009) 2 SCC 134

The Supreme Court examined contractual formation through modern forms of communication and commercial correspondence.

The decision is relevant to determining contractual intention and the circumstances in which communications can establish a binding agreement.

Smart-contract relevance

Where parties use:

• emails;
• electronic instructions;
• digital platforms;
• automated systems,

courts can examine the entire transactional record to determine whether a contract arose.

25. Case Law 9 – Anvar P.V. v P.K. Basheer

(2014) 10 SCC 473

This landmark case concerned electronic evidence under the then-existing Indian Evidence Act.

Although it was not a smart-contract dispute, it is highly relevant because blockchain litigation will depend heavily on:

• transaction records;
• digital signatures;
• electronic communications;
• system logs;
• blockchain records.

Important qualification

The Indian evidence regime has since moved to the Bharatiya Sakshya Adhiniyam, 2023.

Therefore, Anvar remains historically important but must be read together with the current statutory framework.

26. Case Law 10 – Arjun Panditrao Khotkar v Kailash Kushanrao Gorantyal

(2020) 7 SCC 1

The Supreme Court further developed the law concerning electronic records and certificates under the previous Evidence Act framework.

Smart-contract relevance

A claimant challenging or defending a smart contract may need to prove:

• blockchain transaction;
• wallet ownership;
• code;
• server logs;
• electronic communications;
• oracle data;
• digital signatures;
• exchange records.

The evidentiary foundation is therefore critical.

Again, the current Bharatiya Sakshya Adhiniyam, 2023 must now be consulted for present-day litigation.

27. Indian Case-Law Position

An important academic qualification is necessary:

India does not yet have a substantial body of Supreme Court case law directly deciding liability for failure of a blockchain smart contract.

Therefore, an academically sound answer should distinguish:

Direct smart-contract authorities

• B2C2 Ltd v Quoine Pte Ltd
• Quoine Pte Ltd v B2C2 Ltd

Closely related digital-asset authorities

• AA v Persons Unknown
• Tulip Trading Ltd v Van der Laan
• Soleymani v Nifty Gateway
• Vorotyntseva v Money-4 Ltd

Indian analogical authorities

• Trimex International FZE Ltd v Vedanta Aluminium Ltd
• Shakti Bhog Foods Ltd v Kola Shipping Ltd
• Anvar P.V. v P.K. Basheer
• Arjun Panditrao Khotkar v Kailash Kushanrao Gorantyal

This distinction is important because it avoids falsely presenting foreign smart-contract cases as Indian precedent.

28. Can a Smart Contract Itself Be a Contract?

The answer should be approached functionally.

There are at least three models.

Model 1 – Code as the entire agreement

The parties agree entirely through code.

This raises difficult questions concerning:

• interpretation;
• consent;
• mistake;
• accessibility;
• consumer understanding.

Model 2 – Legal contract + code

The parties execute a conventional agreement, while code performs some obligations.

This is legally easier.

Example:

Written agreement → payment obligation → smart contract automatically releases funds.

Model 3 – Hybrid contract

Natural-language terms govern the legal relationship, while blockchain code controls execution.

This is likely to become the most practical model.

29. Code Is Not Necessarily the Same as Legal Intention

A major legal principle should be:

“Code is evidence of contractual intention, but code should not automatically become the exclusive source of legal meaning.”

Suppose the written agreement says:

“Payment shall be released after physical delivery.”

But the smart contract mistakenly releases payment when a shipping label is generated.

The code executed perfectly.

Yet the legal obligation may not have been satisfied.

Therefore:

Correct code execution ≠ necessarily correct contractual performance.

30. Smart Contract and Mistake

Mistake can occur at multiple levels:

Level 1 – User mistake

The user enters the wrong amount.

Level 2 – Programmer mistake

The developer writes incorrect code.

Level 3 – Oracle mistake

The external information is wrong.

Level 4 – System mistake

The blockchain or platform malfunctions.

Level 5 – Legal mistake

The parties misunderstand the legal effect of the transaction.

The remedy depends upon who made the mistake, what was mistaken, whether the mistake was fundamental, and whether another party was entitled to rely upon the transaction.

The Quoine litigation is especially valuable because the courts considered these questions in an automated cryptocurrency trading environment.

31. Developer Liability

A developer should not automatically be liable merely because the code subsequently causes economic loss.

Liability requires a legal basis such as:

• contract;
• negligence;
• misrepresentation;
• professional duty;
• consumer law;
• fiduciary duty;
• statutory duty.

Questions include:

1. Did the developer contract directly with the claimant?
2. Was the software sold or licensed?
3. Was a warranty given?
4. Was security promised?
5. Was the vulnerability reasonably foreseeable?
6. Was there negligent coding?
7. Was there an independent security audit?
8. Was the code modified after deployment?

32. Platform Liability

A cryptocurrency exchange or smart-contract platform may face claims where it:

• reverses transactions contrary to its terms;
• negligently safeguards assets;
• misrepresents functionality;
• fails to disclose risks;
• negligently operates an oracle;
• fails to implement promised security controls.

However, the platform is not automatically responsible for every transaction executed on its system.

The contractual terms become crucial.

33. Oracle Liability

Consider:

Smart contract: “Pay ₹10 lakh if temperature exceeds 40°C.”

Oracle: mistakenly reports 45°C.

Blockchain: automatically pays ₹10 lakh.

The blockchain has functioned correctly.

The failure lies in the information input.

Potential legal claims may therefore shift toward:

• oracle provider;
• data provider;
• platform;
• developer.

This illustrates why liability cannot be determined merely by examining the blockchain code.

34. Cyberattack and Negligence

Suppose:

1. A developer knows a vulnerability exists.
2. The developer fails to patch it.
3. A hacker exploits it.
4. ₹5 crore worth of digital assets are transferred.
5. The smart contract cannot reverse the transaction.

Possible questions:

• Was there a duty of care?
• Was the vulnerability foreseeable?
• Was security promised?
• Was there negligent design?
• Was the claimant contributorily negligent?
• Can the assets be traced?
• Can an injunction be obtained?

This is where ordinary tort and contractual principles become highly relevant.

35. Immutability and Restitution

One of the greatest difficulties is blockchain immutability.

Traditional law often provides:

• rescission;
• restitution;
• injunction;
• reversal;
• specific performance.

But blockchain code may say:

“The transaction cannot be reversed.”

That creates an important distinction:

Technical irreversibility ≠ legal impossibility of remedy.

A court may potentially order:

• repayment;
• restitution;
• transfer of equivalent assets;
• freezing of other assets;
• proprietary remedies;
• damages.

The legal remedy may operate outside the blockchain, even if the blockchain transaction itself cannot be technically reversed.

36. Specific Relief

The Specific Relief Act, 1963 can become relevant depending upon the nature of the obligation.

Potential remedies include:

• injunction;
• specific performance;
• declaratory relief;
• other appropriate equitable remedies.

However, courts will consider whether monetary damages are adequate and whether the statutory requirements for specific relief are satisfied.

The Quoine litigation illustrates the distinction between establishing breach and obtaining specific performance: the first-instance court found breach but considered damages the appropriate remedy.

37. Unjust Enrichment

Suppose a smart-contract bug transfers:

₹1 crore → Person B

when B was legally entitled to only:

₹1 lakh.

B may have received a benefit exceeding the contractual entitlement.

Potential restitutionary questions include:

• Was B enriched?
• At whose expense?
• Was the enrichment unjust?
• Does B have a valid legal defence?
• Can the excess be traced?

The law of unjust enrichment can therefore supplement contract remedies.

38. Consumer Smart Contracts

Consumer-facing smart contracts create additional problems.

A consumer may not understand:

• programming language;
• gas fees;
• oracle mechanics;
• irreversible execution;
• wallet security;
• algorithmic risks.

Therefore, consumer law may become relevant to:

• unfair terms;
• misleading representations;
• hidden risks;
• deficient services;
• defective digital services.

A platform cannot necessarily avoid consumer obligations merely by saying:

“The customer clicked a blockchain transaction.”

39. Smart Contracts and Arbitration

Many blockchain platforms operate globally.

A dispute may involve:

Indian user + Singapore platform + developer in Europe + blockchain nodes worldwide.

Questions include:

• Which law governs?
• Where was the contract made?
• Which court has jurisdiction?
• Is there an arbitration clause?
• Is the arbitration clause valid?
• Can an Indian consumer be bound by a foreign arbitration clause?
• Where can an injunction be obtained?

The contractual terms therefore need careful examination.

40. Jurisdictional Problems

Smart contracts create an unusual jurisdiction problem because:

the code is everywhere, but the parties are somewhere.

A transaction may involve:

• developer in Country A;
• platform in Country B;
• user in India;
• blockchain nodes in multiple countries;
• digital asset held through a wallet with no physical location.

Courts must therefore apply ordinary private international law principles to determine:

• jurisdiction;
• governing law;
• recognition/enforcement.

41. Damages in Smart Contract Failure Claims

A claimant may potentially seek:

Expectation damages

What the claimant would have received if the contract had been properly performed.

Reliance damages

Loss incurred because the claimant relied upon the contract.

Restitution

Return of an unjust benefit.

Consequential damages

Additional foreseeable loss.

Specific relief

Where statutory conditions are met.

However, speculative cryptocurrency price increases create difficult causation and remoteness questions.

A claimant cannot automatically recover every subsequent increase in token value merely because a transaction failed.

42. Causation

The claimant must establish:

Smart-contract failure → legally attributable conduct → actual loss

Consider:

Code failure caused a token transfer of ₹10 lakh.

But the claimant later claims:

₹10 crore because the token's market price increased.

The court would need to examine:

• causation;
• foreseeability;
• remoteness;
• mitigation;
• contractual limitations.

43. Evidence in Smart Contract Litigation

Evidence may include:

• blockchain transaction hash;
• wallet addresses;
• smart-contract source code;
• bytecode;
• audit reports;
• Git repositories;
• emails;
• platform terms;
• logs;
• oracle records;
• timestamps;
• digital signatures;
• expert testimony;
• blockchain explorer records.

Indian electronic-evidence principles developed under Anvar P.V. and Arjun Panditrao provide useful analogies, although current cases must apply the Bharatiya Sakshya Adhiniyam, 2023.

44. Expert Evidence

Smart-contract disputes may require experts in:

• blockchain architecture;
• cryptography;
• software engineering;
• cybersecurity;
• digital forensics;
• token economics.

The court, however, remains the final decision-maker on legal questions.

The expert can explain:

“What did the code do?”

The court determines:

“What legal consequences follow from what the code did?”

45. Smart Contract Failure and Force Majeure

A smart-contract agreement may include force-majeure provisions.

Potential events include:

• blockchain outage;
• network failure;
• government prohibition;
• cyberattack;
• oracle failure;
• extraordinary protocol event.

But not every technical failure is force majeure.

If the failure arose from:

• negligent coding;
• inadequate testing;
• failure to patch;
• foreseeable system weakness,

the provider may not automatically escape liability.

46. “Code Is Law” – Legal Limitations

The famous technological idea that:

“Code is law”

means that software rules can regulate behaviour automatically.

But legally:

Code is not necessarily law.

A court may refuse to enforce a coded outcome where it conflicts with:

• statute;
• public policy;
• contractual intention;
• consumer protection;
• fundamental rights;
• mandatory regulatory requirements.

Therefore:

Blockchain autonomy ≠ legal autonomy.

47. Liability Matrix

This table does not establish automatic liability; the applicable legal duty must first be established.

48. Indian Legal Framework for Smart Contract Failure

A smart-contract dispute in India can potentially involve:

Contract

Indian Contract Act, 1872.

Electronic transactions

Information Technology Act, 2000.

Evidence

Bharatiya Sakshya Adhiniyam, 2023.

Consumer transactions

Consumer Protection Act, 2019.

Remedies

Specific Relief Act, 1963.

Damages

Contract and tort principles.

Arbitration

Arbitration and Conciliation Act, 1996.

Digital assets

Applicable property, regulatory and taxation rules depending on the asset and transaction.

49. Major Legal Challenges

1. Identifying the contracting party

Who is the counterparty?

• developer?
• DAO?
• platform?
• wallet operator?
• token issuer?

2. Determining contractual intention

Was the code itself intended to be legally binding?

3. Immutability

How can an erroneous transaction be corrected?

4. Anonymity

How can a claimant sue an unidentified wallet holder?

5. Jurisdiction

Which country's court has authority?

6. Evidence

How should blockchain records be authenticated and interpreted?

7. Oracle dependency

Who bears responsibility for incorrect external data?

8. Coding errors

When does a software bug become legal breach?

9. DAO responsibility

Can a decentralised organisation be treated as a legal person or partnership-like structure?

10. Regulatory uncertainty

How should courts deal with transactions involving regulated or prohibited assets?

50. Six Key Cases to Remember

For examination purposes, remember these six:

Additional authorities:

• Shakti Bhog Foods Ltd v Kola Shipping Ltd, (2009) 2 SCC 134
• Arjun Panditrao Khotkar v Kailash Kushanrao Gorantyal, (2020) 7 SCC 1
• Soleymani v Nifty Gateway LLC, [2022] EWHC 773 (Comm)
• Vorotyntseva v Money-4 Ltd, [2018] EWHC 2596 (Ch)

51. Analytical Test for a Smart Contract Failure Claim

A court could conceptually approach the dispute through the following sequence:

Step 1 – Identify the agreement

What did the parties agree?

Step 2 – Identify the code

What did the smart contract actually do?

Step 3 – Compare the two

Legal intention ≠ coded outcome?

Step 4 – Identify the failure

Was it:

• mistake;
• breach;
• negligence;
• fraud;
• oracle failure;
• cyberattack;
• platform failure?

Step 5 – Identify the responsible party

Who owed the relevant duty?

Step 6 – Establish causation

Did the failure cause the loss?

Step 7 – Quantify damages

What legally recoverable loss resulted?

Step 8 – Determine remedy

• damages;
• restitution;
• injunction;
• specific relief;
• declaration;
• tracing;
• arbitration.

52. Future Legal Model

The most effective legal model for smart contracts is likely to be:

Natural-language agreement + executable code + emergency override + dispute-resolution clause + audit trail + human/legal governance

A sophisticated smart contract should ideally contain:

1. clearly identified parties;
2. governing law;
3. jurisdiction/arbitration;
4. natural-language legal terms;
5. code specifications;
6. oracle mechanism;
7. error-handling mechanism;
8. emergency pause;
9. dispute-resolution mechanism;
10. liability allocation;
11. security obligations;
12. audit requirements;
13. modification procedure.

53. Conclusion

Smart Contract Failure Claims represent an important emerging area of civil law where traditional contract principles meet blockchain technology.

The fundamental legal proposition is that:

Automatic execution does not automatically determine legal validity.

A blockchain may execute code perfectly while the underlying transaction is nevertheless affected by:

• mistake;
• fraud;
• defective consent;
• breach of contract;
• negligence;
• unjust enrichment;
• unlawful object;
• consumer-law violations.

The Quoine v B2C2 litigation is particularly significant because it demonstrates that courts can apply traditional contractual doctrines to transactions generated by algorithms.

Indian law already contains substantial tools for dealing with many of these problems through the Indian Contract Act, Information Technology Act, electronic-evidence framework, Specific Relief Act, consumer law and ordinary civil remedies. Indian electronic-contract jurisprudence, particularly Trimex, provides an important foundation for recognising contractual relationships formed through electronic communications.

The principal unresolved issue is therefore not whether blockchain transactions can ever have legal consequences, but rather:

When the automated outcome of code conflicts with the parties' legally enforceable agreement, which should prevail, who bears the resulting loss, and what remedy can a court realistically provide?

That question places smart-contract failure claims at the intersection of contract law, technology law, digital-asset law, tort, restitution, evidence, consumer protection and private international law.