Who Owns the Breach? Liability in Smart Contracts

A 'smart contract' is neither smart nor, in the doctrinal sense, always a contract. It is code that executes automatically when predefined conditions are met — an escrow that releases funds on delivery confirmation, a lending protocol that liquidates collateral when a price feed crosses a threshold. The appeal is obvious: no counterparty can simply decide not to perform. The code performs for them.

That certainty is also the source of the hardest legal questions this format raises. Contract law has spent centuries building doctrine around the idea that a human being makes a promise, and a human being can be asked to answer for breaking it. When execution is automatic, the promise-making and promise-keeping steps collapse into a single event, and the question of who is legally answerable when that event goes wrong — a bug, an oracle feeding bad data, an edge case nobody scoped — no longer has an obvious address.

Abstract

This piece maps three candidate liability models for smart contract failure against existing Indian contract and technology law, and argues that none of the three is currently sufficient on its own. It proposes a layered framework — separating liability for defective code, liability for deployment decisions, and liability for the platform that facilitated execution — as a more workable starting point than treating 'the smart contract' as a single liable actor.

Contract law's assumptions, tested

Under the Indian Contract Act, 1872, a valid contract requires offer, acceptance, consideration and the intention to create legal relations, formed between parties competent to contract. None of this assumes a human executes the bargain personally — the Act has never required a handshake. What it does assume is that at the point something goes wrong, a party can be identified who made the relevant promise and can be held to it.

Code complicates the second half of that assumption, not the first. A smart contract can satisfy offer and acceptance well enough — deploying a contract to a network and inviting counterparties to interact with it is not meaningfully different from publishing standard terms. The harder question is what happens when the code does something neither party intended: a rounding error drains a pool, an oracle reports a stale price and triggers a wrongful liquidation, a condition that looked airtight in testing turns out to have an edge case in production.

Three candidate liability models

1. Code-as-final-word: the outcome the code produces is the outcome the parties agreed to, full stop, because the code was the term. This model is administratively simple and almost nobody actually wants it once a six-figure bug is on the table.
2. Deployer liability: the party who deployed or configured the contract is treated as having made the underlying representations, on the theory that they chose to rely on the code to perform their obligations and bear the risk of it doing so incorrectly.
3. Layered liability: liability is split between the developer of the underlying code (for defects in the logic), the deployer or operator (for configuration and deployment decisions), and the platform or oracle provider (for the integrity of external inputs the contract relied on).

Indian courts have not yet had to choose between these models in a reported smart contract dispute, so this remains, deliberately, an analysis of where existing doctrine points rather than a summary of settled law.

Where existing law already reaches

Section 10A of the Information Technology Act, 2000, already removes the most basic objection to smart contract enforceability: an agreement is not unenforceable merely because it was concluded electronically. That clears the formation question. It does not answer the performance question — what a court does when the electronic agreement performs itself incorrectly.

On the evidentiary side, Section 65B of the Indian Evidence Act, 1872, governs the admissibility of electronic records, and the Supreme Court's ruling in Anvar P.V. v. P.K. Basheer (2014) established that a certificate under Section 65B is mandatory for such records to be admitted as evidence — a requirement that matters a great deal for smart contracts, where the 'contract' and its performance history exist only as on-chain data.

The code does not need to be perfect for the law to apply to it. It needs to be attributable to someone.

The verification gap

Most disputes will not turn on whether smart contracts can be legally binding — Section 10A settles that in the affirmative. They will turn on fact-finding: whose configuration choice, whose unaudited edge case, or whose oracle feed caused the loss. This is a verification problem before it is a doctrinal one, and it is where a layered liability model earns its keep — by giving a court a map of who was responsible for which layer of the system, rather than one undifferentiated 'the contract failed'.

A proposed framework

Treat the code, the deployment decision and the data feed as three separate sources of potential liability, each traceable to a different actor: the developer for defects in logic that a reasonable audit should have caught, the deployer for configuration choices made with knowledge of the code's limitations, and the oracle or platform provider for the integrity of the external data the contract relied on. None of this requires new legislation to begin applying — it requires courts and drafters to stop asking 'is the smart contract liable' and start asking 'which layer of this system failed, and who controlled it'.

That reframing is unglamorous. It is also the only version of this question contract law already knows how to answer.