A smart contract executes exactly as written — including when what is written is wrong. The features that make smart contracts attractive are self-execution, immutability and transparency: once deployed, the code runs without human involvement, and once a transaction is recorded on the blockchain, no court, clerk or ledger keeper has control over the underlying data. Those same features are what make smart-contract failures hard to unwind. When a coding error misdirects a payment, or a condition fires that the parties never intended, there is no back office to call and no entry to reverse.
Consider an example I have written about before. In one situation, a mistyped variable caused a payment to be sent to the wrong vendor. A week passed before anyone noticed, by which point several million dollars sat with a third party. That recipient had not spent the money and did the honorable thing, refunding the payment. The situation could easily have taken a different course — with the parties spending millions of dollars in legal fees to remedy a typo.
§ 01 · What a smart contract actually is
The term comes from Nick Szabo, the computer scientist and lawyer who described a smart contract as “a set of promises, specified in digital form, including protocols within which the parties perform on these promises.” The simplest way to think about one is as an if-then statement: if condition X is met, then Y occurs. The parties reduce the basic terms of their agreement to computer code; the code typically references an external data source — an “oracle” — to verify that a triggering event has occurred; and when it has, the contract self-executes and the transfer is recorded on the blockchain. JAMS defines the artifact the same way in its smart-contract rules: “a computer protocol intended to digitally facilitate, verify or enforce the negotiation or performance of a self-executing contract,” with the terms written directly into code on a decentralized blockchain network.
To see the difference in kind, take a simple transaction between a buyer and a seller for one hundred blue widgets. Traditionally the parties would execute a paper agreement reading, in part, “Seller shall deliver to Buyer one hundred (100) blue widgets.” The smart-contract version of the same deal is a transfer function written in Solidity, the language of the Ethereum blockchain — a few lines of code that check an allowance and move the asset when the condition is met. In either case the seller packs and ships widgets. But when a dispute arises, the first step in resolving a conventional contract fight — apply the plain language of the agreement as written — points somewhere new. With a smart contract, the plain language is computer code. Code has usurped the role plain language has always played.
With a smart contract, the plain language of the agreement is computer code. A neutral who cannot read the code cannot apply the contract as written.
§ 02 · Where the disputes come from
The common sources of smart-contract disputes are by now familiar: coding errors; ambiguous or incomplete contract terms; external factors such as changes in regulation or market conditions; and problems in the underlying blockchain network itself, from congestion to security vulnerabilities. There is also a second-order category — claims against the person hired to “draft,” meaning code, the contract — and an insurance-coverage layer that often rides on top of all of it. Immutability sharpens every one of these: once recorded, a smart contract is nearly impossible to unilaterally modify, even when circumstances change, forbearance is warranted or a programming error is found.
Litigation handles this badly. A judge confronting even a run-of-the-mill contract dispute built on a smart contract must understand and interpret the underlying computer code and the effect of its self-executing nature before reaching the questions lawyers normally argue. The decentralized character of blockchain networks adds jurisdictional conflict to the technical baggage. Traditional legal frameworks were not built for disputes with this level of requisite technological knowledge — which is why arbitration, with the right rules and the right neutral, fits these matters better.
§ 03 · What the JAMS smart-contract rules provide
JAMS publishes Rules Governing Disputes Arising out of Smart Contracts, together with a model dispute resolution clause that parties can incorporate by reference — including directly into the smart contract’s own code. The rules make a set of design choices worth understanding before you adopt them. Appointment is fast: the parties appoint an arbitrator within 72 hours after the arbitration statement is filed and served (Rule 5(b)). The record is deliberately narrow: discovery is limited to the deposition of one competent individual expert witness on the meaning of the smart-contract coding, and the only documentation the arbitrator reviews is the written contract, the computer code and that witness’s testimony (Rule 12(b)). The award issues quickly — no later than 30 calendar days after the arbitrator’s appointment (Rule 13(a)) — and the proceeding and award are confidential (Rule 15(a)).
The compressed record reflects a bet: that most smart-contract disputes reduce to what the code says measured against what the parties agreed it should say. For most matters that bet is sound, and the payoff is speed, privacy for proprietary technology, and an award that travels — the New York Convention, ratified by 172 countries as of 2024, gives arbitral awards a cross-border reach that court judgments rarely match in blockchain disputes.
§ 04 · A protocol for counsel
Four steps, all of them before the code is deployed. (1) Put dispute resolution into the transaction at the drafting stage — the smart contract’s code can itself specify the arbitration institution, the applicable rules and the procedures for initiating a proceeding. (2) Keep the paper and the code consistent. Under a limited-record framework like Rule 12(b), the written contract and the deployed code are essentially the whole case; a divergence between them is the dispute. (3) Select a neutral who is bilingual — fluent in both English (the law) and computer code (the technology). A superficial comprehension of blockchain is not enough; parties expect the neutral to understand the issues at least as well as they do. (4) Preserve the artifacts the tribunal will actually review: the agreement, the deployed code and the inputs the parties supplied to it.
Blockchain will keep spreading through business and consumer transactions, and it is a matter of when, not if, these disputes populate the ADR dockets. The code will execute either way. The parties’ only real choice is whether they decided, before deployment, who reads it when it executes wrong.
Adapted from “Arbitrating Smart Contract Disputes: A Comprehensive Approach” (2024), co-authored with Hon. Gail A. Andler (Ret.), and “Neutrals Need to ‘Speak Tech’ to Resolve Disputes Involving Smart Contracts,” New York Law Journal (2019).