How to Enforce a Smart Contract Under New York Law When the Code Conflicts With the Written Agreement
Under New York law, a smart contract is generally enforceable if it satisfies ordinary contract requirements—offer, acceptance, consideration, and mutual assent—even when performance is automated by code. Disputes arise when on-chain code executes one outcome while the parties’ written agreement states another. This article explains how New York courts are likely to analyze code-versus-text conflicts, what claims and remedies to plead, and how to draft to avoid the problem.
Smart contracts in New York: enforceability is contract law, not mysticism
New York has positioned itself as a leading U.S. jurisdiction for commercial contracting and complex disputes, and its courts typically treat “smart contracts” as contracts that happen to use software to perform or record obligations. In practice, the legal question is rarely whether “code can be a contract.” The more litigated issue is which instrument controls when (1) the parties sign a written agreement describing what should happen, and (2) the deployed code executes something different.
In New York, contract interpretation starts with the parties’ objective manifestations of intent. If the parties formed a contract—offer, acceptance, consideration, and mutual assent—a court will generally enforce that bargain, whether performance was manual, automated, or on-chain. The harder part is determining what the bargain actually was, and what remedies are available once an automated execution has moved assets irreversibly.
Why code and writing diverge (and why courts care)
Conflicts between smart contract code and a written agreement are not hypothetical. Common causes include:
Version mismatch: the term sheet and the deployed bytecode do not match the final negotiated version.
Parameter or oracle errors: the written agreement assumes a price feed, index definition, or time source that differs from the implemented oracle configuration.
Ambiguity in “business logic”: the writing uses commercial terms (e.g., “VWAP,” “close of business,” “material breach”) that were implemented in code as simplified proxies.
Security vulnerabilities: a reentrancy or access-control bug allows an outcome the writing never contemplated.
Admin key or upgrade mechanics: the writing says “immutable,” but the contract is upgradeable—or vice versa.
Courts care because these disputes often involve significant value, sophisticated parties, and evidentiary complexity: cryptographic signatures, wallet control, logs, and the parties’ communications about how the system was expected to work.
Step one: identify what “the contract” is
When code and writing conflict, New York practitioners should begin with a deceptively simple task: define the contractual documents and their relationship. In many transactions there is not a single contract but a stack:
(1) The written agreement: MSA, purchase agreement, loan agreement, SAFT, token warrant, or platform terms.
(2) Incorporations by reference: technical documentation, Git commit hash, ABI, deployment address, audit report, whitepaper, and oracle specifications.
(3) On-chain components: bytecode at a specific address, proxy + implementation contracts, multisig admin controls, and governance modules.
(4) Off-chain operational practices: key management procedures, whitelisting, and compliance steps (e.g., sanctions screening) that may be referenced in the writing.
The central interpretive question is whether the code is (a) the definitive statement of performance, (b) evidence of performance mechanics subordinate to the writing, or (c) an incorporated term that modifies the writing.
Integration clauses and “order of precedence” provisions
New York courts frequently enforce integration clauses and “order of precedence” provisions. If the writing says, for example, “In the event of conflict, this Agreement controls over any technical documentation or smart contract code,” that is powerful. Conversely, a clause stating “the smart contract code governs and is the definitive expression of the parties’ agreement” can shift the analysis toward the code as controlling, subject to defenses like fraud, mistake, or unconscionability.
Where the writing is fully integrated and unambiguous, the parol evidence rule will generally limit the use of extrinsic evidence to vary the terms. But parties often overlook that the code itself can be treated as part of the integrated contract if it is incorporated with sufficient specificity (e.g., by address, hash, or attached source code).
Interpreting the conflict: how New York law frames the issue
When code produces a result inconsistent with a written obligation, the plaintiff typically frames the dispute in one of two ways:
Performance breach: the defendant breached the written agreement by causing or permitting the smart contract to perform incorrectly (or by refusing to correct the outcome).
Formation/term dispute: the “real agreement” included the code logic, so the writing is incomplete, mistaken, or was induced by misrepresentation.
New York’s interpretive framework tends to ask: What did the parties objectively agree to, and what risk allocation did they choose (bugs, oracle failures, admin intervention)? The more sophisticated the parties and the more explicit the drafting, the more likely a court is to enforce that allocation—even if it produces a harsh result.
Is “code” ambiguous? Using extrinsic evidence properly
Parties often argue “the code is unambiguous; it did what it did.” Technically, bytecode is deterministic, but legal ambiguity is different. If the written agreement uses commercial terms and the code is an implementation of those terms, the question may be whether the implementation is a faithful translation.
Extrinsic evidence that commonly matters includes:
Negotiation history (redlines, emails, term sheets) to show intended economic effect.
Technical artifacts (Git history, pull requests, audit reports, test cases) to show what logic was represented to the other party.
Course of performance (how the system operated before the dispute) to inform interpretation where the writing is ambiguous.
Industry custom for specialized terms if the contract invites that context.
Primary causes of action when the written agreement should control
Breach of contract (including breach of representations/warranties)
The cleanest path is often a breach claim grounded in express obligations: deliver X tokens, pay Y consideration, apply the oracle specified, maintain immutability, or adhere to an audit standard. If the writing contains representations such as “the smart contract implements Schedule A” or “conforms in all material respects,” a mismatch can be pled as breach of warranty, reducing debate over interpretive ambiguity.
Reformation for mutual mistake or scrivener’s error
If both parties intended the written economics but the deployed code reflected a drafting/implementation error, reformation may be available under New York law upon clear and convincing evidence of mutual mistake (or unilateral mistake plus fraud). Practically, reformation is a bridge to remedies: it supports the argument that the “correct” agreement is the one the parties meant, not the one the code executed.
Fraud or negligent misrepresentation (when code behavior was misdescribed)
Where one side represented that the code did X (e.g., “caps withdrawals,” “uses Chainlink feed,” “cannot be upgraded”), but the deployed contract did Y, fraud-based claims may apply. New York courts scrutinize reliance and the boundary between contract and tort. Well-pled fraud typically requires misstatements collateral to the contract and particularized allegations, but in smart contract cases, technical representations can be the core inducement.
Unjust enrichment / restitution (especially after automated transfer)
When assets move on-chain, defendants sometimes argue “the chain is final.” Finality is a technological property, not necessarily a legal defense. If a party received a windfall contrary to the agreement, plaintiffs often plead unjust enrichment or restitution in the alternative, particularly where privity is disputed (e.g., interactions through a protocol, aggregator, or intermediary).
Remedies: what a New York court can do after the chain has executed
Money damages remain the default
Even if the smart contract transfer cannot be reversed on-chain, New York courts can award damages measured by the plaintiff’s expectancy or reliance interest. In token transactions, litigants should be prepared to address valuation date, market volatility, and whether the contract specifies a pricing mechanism.
Injunctive relief and specific performance (practical but fact-dependent)
In appropriate cases, courts may order parties to take off-chain steps that effectively unwind or mitigate the on-chain outcome. Examples include:
Order to transfer replacement assets (e.g., deliver the correct number of tokens from treasury wallets).
Order to exercise admin controls where the agreement requires correction and the defendant controls upgrade keys.
Order to refrain from dissipating assets via temporary restraining order or preliminary injunction, including directing centralized exchanges (where jurisdiction exists) to freeze identifiable accounts.
Injunction practice in New York will turn on irreparable harm, likelihood of success, and the balance of equities. Plaintiffs should be ready with on-chain tracing evidence, declarations from technical experts, and a clear narrative of control: who holds the keys, who can upgrade, who can transfer.
Constructive trust and accounting
Where identifiable property was transferred and can be traced (even across wallets), equitable remedies like constructive trust and an accounting may be pled. The feasibility depends on the facts—mixing, bridging, and privacy tools complicate tracing—but sophisticated forensic support can make these claims viable.
A concrete example: oracle mismatch in a token purchase
Assume a written token purchase agreement states: “Purchase price is the 30-day VWAP of Token T as published by Exchange A at 4:00 p.m. New York time.” The smart contract, however, uses an oracle that reports a spot price from Exchange B and updates every 60 seconds. A volatility event causes the contract to mint significantly more tokens than the writing would allow.
Under New York law, the purchaser can argue breach: the seller (or issuer) promised a VWAP-based price and warranted that the code implements that mechanism. The issuer may argue that the buyer interacted with the contract and assumed oracle risk. The outcome will heavily depend on drafting (order of precedence, risk allocation, disclaimers), disclosures (did the buyer receive
