"Code is law" is not a legal defence. It's a useful engineering principle and a poor litigation strategy. When a smart contract dispute eventually lands before an Indian court and given the pace of DeFi adoption among Indian users, it will the judge will not open a Solidity file and ask whether the code ran correctly. The judge will open the Indian Contract Act, 1872, and ask the same five questions asked of a chai-stall handshake deal: was there an offer, was there acceptance, was there consideration, did the parties have capacity, and was the object lawful.
This is the gap most Web3 teams building for Indian users don't close. They audit their code for reentrancy bugs and oracle manipulation but never map their protocol's function calls against Sections 10, 23, and 25 of a 150-year-old statute. This piece does that mapping first principles, section by section so that developers and in-house counsel know exactly what a court will actually look at.
What a Smart Contract Actually Is, Technically
Before mapping any of this onto Indian statute, it's worth being precise about what a smart contract is as a piece of technology, because the legal analysis turns on specific technical features, not just the general idea of "code that runs itself."
A smart contract is a self-executing program deployed on a blockchain a distributed, tamper-resistant ledger maintained simultaneously by a network of computers rather than a single central server. Once deployed, the smart contract's logic runs on "if/when…then…" conditional statements: if a specified condition is satisfied (a payment is received, a price threshold is crossed, a delivery is confirmed), then a predetermined action executes automatically (funds are released, collateral is liquidated, a token is transferred), without any party needing to take a further manual step. The network of computers that maintains the blockchain independently verifies that the trigger condition has genuinely been met before the action fires, which is what gives the process its "trustless" character — two parties who have never met and have no reason to trust one another can still transact, because neither is relying on the other's honesty, only on the code executing as written.
Three technical properties of this architecture matter enormously once a dispute reaches a courtroom:
Disintermediation. Because the network itself verifies and executes the conditions, a smart contract removes the need for a broker, escrow agent, or lawyer to sit between the parties and confirm performance. But it also means there is often no intermediary institution left standing to hold responsibility when something goes wrong, which is precisely the vacuum contract law is asked to fill.
Immutability and irreversibility. Once a transaction is included in a block and that block is confirmed by the network, the smart contract's execution is, by design, permanent and cannot be edited or rolled back.
Traceability. Every transaction executed by a smart contract is recorded on the shared ledger and is, in principle, visible and auditable by anyone with access to the chain. This traceability is a significant evidentiary advantage compared to informal agreements but, as Section 3 below explains, traceability of what happened on-chain is not the same thing as admissibility of that record in an Indian courtroom, which has its own separate statutory conditions.
Smart contracts of this kind became commercially significant with the emergence of programmable blockchain platforms like Ethereum, which allowed developers to write general-purpose contract logic rather than the narrower scripting Bitcoin's original chain supported, it's also precisely why the legal system now has to catch up to a category of "agreement" that didn't exist in any recognisable form when the Indian Contract Act was drafted in 1872.
When Does Code Equal Contract? The Interpretation Problem
Indian courts, unlike the flexible English common law operate within a codified statute that still assumes a "meeting of minds" expressed in terms a human can point to. A DAO governance proposal executed purely through on-chain voting and automatic treasury disbursement, with no accompanying charter or terms document, gives an Indian court very little to interpret if a dispute arises over what the parties actually intended.
Separately, Indian courts will need admissible evidence of what the code actually did. Following the Bharatiya Sakshya Adhiniyam, 2023 (which replaced the Indian Evidence Act's Section 65B regime with Section 63), electronic records including blockchain transaction logs are admissible only as secondary evidence when accompanied by the mandatory certificate confirming the lawful operation and control of the system that produced the record. Courts have continued to treat this certificate as a strict condition precedent for admissibility, not a mere formality. Protocol teams that cannot produce a certifiable, verifiable record of contract state and execution history will struggle at the evidentiary stage.
Oracles, External Data, and the Frustration Problem
Section 56 of the Contract Act renders an agreement void when, after the contract is made, an act becomes impossible or unlawful due to an event the promisor could not prevent. Oracle failure sits in an interesting middle ground. A genuine oracle outage the data feed simply stops reporting is closer to classic impossibility. A manipulated oracle (flash-loan price manipulation being the canonical DeFi example) is closer to a mistake-of-fact or even fraud scenario, because the contract executed exactly as coded, on data that was deliberately corrupted by a third party.
This distinction matters enormously for loss allocation. Force majeure clauses, which Indian courts do give effect to as a matter of contractual freedom (subject to Section 56's residual doctrine), should be drafted into the accompanying legal documentation for any smart contract with material off-chain dependencies.
Bug Liability: Who Bears the Loss When the Code Is Wrong?
There is no Indian statute that squarely allocates liability for smart contract bugs. In their absence, three existing doctrines do the work, and which one applies depends heavily on how the relationship between the parties was structured.
Mistake (Sections 20–22). If both parties entered into the agreement based on the same mistaken belief about an essential fact for example, a coding bug incorrectly calculated a token's value, the contract may be void under Section 20 of the Indian Contract Act. While the law may require the parties to restore what they received, recovering funds can be difficult in DeFi where counterparties are often anonymous.
Negligence, outside pure contract law. Where there is no direct contract between the parties, liability may instead arise under the law of negligence. A court may examine whether the protocol developers exercised reasonable care by properly auditing, testing, and securing the smart contract before deployment. This approach could apply equally to DAOs and development teams that deploy inadequately tested code.
Contractual allocation via terms of use. The best way to manage bug-related disputes is through clear terms of use accepted by users, such as through a clickwrap agreement under Section 10A of the IT Act. These terms should allocate bug-related risks, state that the code is provided "as is," and avoid excluding liability for fraud or gross negligence, as such exclusions may not be enforced by Indian courts.
Drafting Tips: Combining Law and Code
Indian courts will look at the agreement, not just the code. To improve enforceability, smart contracts should be supported by clear legal documentation. In particular:
Use written terms alongside the code. Explain how the smart contract works, how risks such as bugs or oracle failures are handled, and the rights and obligations of the parties.
Record user acceptance clearly. Use clickwrap or similar mechanisms that comply with Section 10A of the IT Act.
Maintain proper records. Keep transaction logs and system records in a form that can be produced as evidence under the Bharatiya Sakshya Adhiniyam, 2023.
Include force majeure and liability clauses. Don't rely only on technical safeguards such as pause functions.
Add governing law and arbitration clauses to help resolve cross-border disputes efficiently.
Ensure the underlying transaction is lawful. If the object of the smart contract violates Section 23 of the Contract Act or other laws such as PMLA or FEMA, the contract may not be enforceable regardless of how well the code is written.
The Bottom Line
Indian courts will not ask whether your smart contract executed correctly. They will ask whether the parties formed a valid agreement under Section 10, whether consent was free, whether the object was lawful under Section 23, and whether there's admissible evidence of what actually happened. Code that runs exactly as written is not a defence to any of those questions — it is, at best, evidence of performance of an agreement that still has to satisfy 150-year-old formation requirements. The protocols that will hold up in Indian litigation are the ones that were built with that reality in mind from the start, not the ones scrambling to retrofit terms of use after a dispute has already landed.
Navigating emerging technologies requires more than technical expertise—it requires legal foresight. At Fathom Legal, we help businesses build compliant, commercially sound blockchain and digital asset solutions that are designed to withstand both regulatory scrutiny and contractual disputes.
This article is intended for general informational purposes and does not constitute legal advice. Smart contract structures should be reviewed against the specific commercial arrangement and regulatory posture of the protocol in question.