“In June 2016 an attacker drained $50 million in Ether from The DAO and an open letter purportedly from the attacker defended the exploit on the ground that the code's rules had been followed exactly as written. The Ethereum community's hard fork to reverse the theft acknowledged the uncomfortable truth: when the stakes are high enough, human decisions override code.”
By Chanté Eliaszadeh | September 6, 2026
“Code is law.” This ethos, popular in the early Ethereum community, promised to replace messy human legal systems with immutable, self-executing smart contracts. No lawyers, no judges, no ambiguity—just deterministic code enforcing agreements with mathematical certainty.
Then came The DAO hack. In June 2016, an attacker exploited a vulnerability in The DAO’s smart contract code and drained $50 million in Ether. An open letter, purportedly from the attacker, offered a controversial defense: the code’s rules had been followed exactly as written. If “code is law,” the exploit was perfectly legal.1
The Ethereum community’s response—a controversial hard fork to reverse the theft—acknowledged an uncomfortable truth: when the stakes are high enough, human decisions override code. The “code is law” fantasy died that day.
Nearly a decade later, smart contracts secure roughly $88 billion in DeFi total value locked and automate complex financial transactions.2 Yet fundamental questions about their legal enforceability remain unanswered. When does a smart contract constitute a legally binding agreement? Can code bugs be treated as mutual mistake? Who bears liability when oracles provide bad data?
This article examines smart contract enforceability through the lens of traditional contract law, explores emerging legal frameworks, and provides practical guidance for developers and businesses deploying smart contracts in legally defensible ways.
Key Takeaways
-
Code is not law: The DAO hack showed that when enough is at stake, human decisions override code, and neither contract law’s remedies nor criminal law yield to what the code says.
-
Off-chain dependencies are legal exposure: oracle failures need explicit disclosure and risk allocation, and so does any admin key that can change contract behavior.
-
Bugs raise mutual-mistake questions: and a Ricardian contract that pairs prose with code, with prose governing on conflict, is the most defensible structure for high-value transactions.
-
Arbitration clauses do the work code cannot: crypto-friendly governing law, expert arbitrators, and emergency relief procedures.
-
Wyoming’s DUNA is an early recognition framework: the direction is convergence between legal frameworks and smart contract design, not replacement.
Traditional Contract Formation Meets Blockchain
Contract law developed over centuries to address human agreements. Smart contracts—deterministic code executing automatically on blockchains—challenge every assumption underlying this framework.
The Four Essential Elements
Under common law, contract formation requires a bargain in which there is a manifestation of mutual assent to the exchange and a consideration; courts analyze that bargain through four familiar elements:3
- Offer: One party proposes specific terms
- Acceptance: The other party agrees to those terms
- Consideration: Both parties exchange something of value
- Mutual assent: Each party’s words or conduct manifests assent to the exchange
Applying this framework to smart contracts raises immediate questions:
Offer and Acceptance: When Alice interacts with a DeFi protocol smart contract, has she “accepted” an offer? The Restatement asks not for a subjective meeting of the minds but for a manifestation of mutual assent; a party’s unexpressed reservation does not impair the obligation the party purports to undertake.3 Smart contracts execute on function calls, and the question is whether a function call manifests assent to any terms at all.
The Ninth Circuit’s Patrick v. Running Warehouse decision provides guidance: an online agreement binds a user on an inquiry-notice theory only if the website gives reasonably conspicuous notice of the terms and the user takes some action that unambiguously manifests assent.4 For smart contracts, this means:
- Terms must be human-readable and disclosed before interaction
- User interface must clearly communicate the legal nature of the transaction
- Users must take affirmative action demonstrating assent (beyond merely calling a function)
Consideration: Most smart contract interactions satisfy this requirement easily. Trading tokens for tokens, paying gas fees for service execution, or depositing collateral for loans all constitute valid consideration.
Mutual Assent: Here’s where smart contracts struggle most. Traditional contracts assume parties negotiate, understand, and agree to terms. Smart contracts are typically:
- Immutable once deployed
- Written in code few users can read
- Offering no negotiation opportunity
- Executed automatically without human intermediaries
Whether a user’s interaction with a smart contract manifests assent may turn on whether the interface gave reasonably conspicuous notice of the terms.4 The question sharpens when the code’s behavior differs from what the interface described.
Smart Contracts Under the UCC
The Uniform Commercial Code governs sales of goods and commercial transactions across U.S. jurisdictions. The 2022 amendments add a framework for digital assets held as controllable electronic records.
UCC Article 12: Controllable Electronic Records
In 2022, the Uniform Law Commission and the American Law Institute adopted Article 12, introducing “controllable electronic records” (CERs)—records stored electronically that can be subjected to “control.”5 Article 12 turns on whether a record can be subjected to control under its § 12-105, not on the technology used to exercise that control; the act never mentions smart contracts.
Key implications (from the 2022 amendments):5
- A security interest in a controllable electronic record may be perfected by control or by filing (U.C.C. §§ 9-107A, 9-312, 9-314)
- A security interest perfected by control has priority over one perfected by another method (U.C.C. § 9-326A)
- Control functions as the equivalent of possession for a controllable electronic record, which has no physical form to possess
However, Article 12 governs property rights in digital assets—not the enforceability of the underlying agreements. A smart contract may successfully transfer a CER while the underlying transaction remains unenforceable for other reasons (fraud, mistake, unconscionability).
State Smart Contract Legislation
Multiple states have enacted laws explicitly recognizing smart contracts:
- Illinois Blockchain Technology Act: Provides that a smart contract, record, or signature may not be denied legal effect or enforceability solely because a blockchain was used to create, store, or verify it, bars a court from excluding such evidence on that ground alone, and lets a blockchain record satisfy a writing or signature requirement6
- Arizona and Tennessee: Statutes providing that smart contracts “may exist in commerce” and that a contract may not be denied legal effect, validity, or enforceability solely because it contains a smart contract term (Arizona) or is executed through a smart contract (Tennessee); Nevada includes a blockchain within its definition of an electronic record, and Ohio treats a blockchain-secured record or signature as an electronic record or signature, neither naming smart contracts7
These statutes create no separate law of smart contracts—they confirm that blockchain-based records and signatures are not invalid for their medium, and in Illinois that a blockchain record can satisfy a writing or signature requirement. Smart contracts must still satisfy traditional contract formation requirements.
The DAO Hack: Lessons in Legal Versus Code Execution
The DAO incident remains the defining case study for smart contract legal limits.
What Happened
The DAO was a decentralized autonomous organization launched in April 2016 via a token sale, raising over $150 million worth of Ether. The organization’s governance and fund disbursement ran entirely through smart contracts. The DAO’s own terms declared the code the controlling authority—any explanatory descriptions were “merely offered for educational purposes.”8
On June 17, 2016, an attacker used a recursive call exploit in The DAO’s smart contract to withdraw funds repeatedly in a loop, draining 3.6 million Ether, then worth approximately $50 million.9
The Attacker’s Legal Theory
An open letter, purportedly from the attacker, claimed the funds were obtained legally according to the smart contract’s terms. Since The DAO’s terms made the code the controlling authority, the letter argued, the withdrawal was a legal transaction—the code permitted the action, therefore it was allowed.10
This raised profound questions: If parties agree that code governs their relationship, can exploitation of coding errors constitute legal performance rather than breach or theft?
Why “Code is Law” Failed
The DAO hack exposed fundamental incompatibilities between “code is law” philosophies and legal reality:
1. Contracts Already Have “Escape Hatches”
Traditional contract law includes extensive remedies for errors and unforeseen circumstances:
- Mutual mistake: When both parties are mistaken about a basic assumption on which the contract was made and the mistake materially affects the agreed exchange, the contract may be voidable by the adversely affected party11
- Unilateral mistake: If one party is mistaken about a basic assumption, the mistake has a material effect on the agreed exchange adverse to that party, that party does not bear the risk of the mistake, and the other party had reason to know of the mistake, the contract may be voidable12
- Impracticability: When a party’s performance is made impracticable without that party’s fault by an event whose non-occurrence was a basic assumption of the contract, the duty to perform is discharged unless the language or the circumstances indicate the contrary12
- Unconscionability: A court may refuse to enforce a contract or term that was unconscionable when made12
These doctrines recognize that rigid enforcement of literal terms sometimes produces unjust results. Contract law already supplies a spectrum of remedies for errors and unforeseen eventualities, and the early promise that smart contracts would eliminate court intervention did not survive The DAO.13
2. Bugs as Mutual Mistake
The DAO’s reentrancy vulnerability was a coding error that no participant, at the time of contracting, understood the code to permit. Whether that shared misunderstanding of how the code functioned is a mistake as to a basic assumption on which the contract was made, with a material effect on the agreed exchange, is the question mutual mistake doctrine would ask; if it is, the contract is voidable by the adversely affected party unless that party bears the risk of the mistake.11
3. Criminal Law Overrides Contract Terms
Even if The DAO’s terms stated “code is law,” criminal prohibitions against theft apply regardless of contract language. What the code states is not the whole of what a court weighs; intent and the system’s normal function matter too. If the attacker’s conduct constituted unauthorized access to a computer system or theft, the argument that the code permitted it is not a defense.14
Legal Precedent Status
Notably, the attacker’s “code is law” theory was never tested in court in The DAO’s own case:
- The Ethereum community hard-forked to reverse the theft
- The hard fork, not the attacker, restored the funds to investors; the attacker kept the tokens on the Ethereum Classic chain9
- We are aware of no criminal charge that adjudicated the attacker’s theory
- We are aware of no civil litigation over the exploit that proceeded to judgment
However, the incident profoundly influenced how courts and regulators view smart contracts. The SEC later determined DAO tokens were securities, and stated that the automation of certain functions through smart contracts “does not remove conduct from the purview of the U.S. federal securities laws.”15
The Oracle Problem: Off-Chain Dependencies
Smart contracts can only execute based on information available on-chain. But most real-world agreements depend on external facts: stock prices, weather conditions, election results, delivery confirmation, insurance claims.
Oracles serve as bridges, feeding external data to smart contracts. This creates a trust problem fundamentally at odds with blockchain’s trustless design.
Legal Liability for Oracle Failures
When an oracle provides incorrect data, who bears liability?
Consider a simple example: A smart contract-based insurance policy pays out if a hurricane hits Miami. The contract relies on Oracle A for weather data. Oracle A incorrectly reports no hurricane (when one occurred), and the policy doesn’t pay. The insured suffers losses.
Potential liability theories:
1. Oracle Provider Liability
Recent legal analysis proposes a default rule under which “oracles bear primary responsibility for transaction errors arising from inaccurate data sourcing or validation failures.”16 This makes economic sense—oracles are best positioned to ensure data accuracy and maintain reliable feeds.
However, determining “oracle malfunction” versus “correct reporting of incorrect source data” creates thorny causation questions. If Oracle A correctly reports data from Weather Service B, but Weather Service B’s data was wrong, who’s liable?
2. Smart Contract Developer Liability
If oracles demonstrate they functioned correctly, liability may shift to smart contract developers, who under this framework are responsible for ensuring secure and error-free code.16 In practice, that exposure is greatest for developers who failed to:
- Select reliable oracles
- Implement redundancy (multiple oracle sources)
- Build in error checking or sanity limits
- Clearly disclose oracle dependencies to users
3. Contractual Risk Allocation
Sophisticated parties should address oracle failure in their agreements:
- Define what constitutes oracle failure
- Specify backup procedures or alternative data sources
- Allocate risk explicitly (who bears loss if oracle fails?)
- Establish dispute resolution mechanisms
The lack of established case law creates enormous uncertainty. Smart contract developers relying on oracles for material terms should consult legal counsel on appropriate disclaimers, limitations of liability, and risk allocation structures.
Code Bugs: Mutual Mistake or Caveat Emptor?
The Parity multi-sig wallet incidents illustrate how code bugs create legal ambiguity.
Parity Wallet Freeze Incident
On November 8, 2017, a user exploited a vulnerability in Parity’s multi-sig wallet library contract, leaving over $150 million in Ether inaccessible absent a hard fork of the Ethereum blockchain.17 Unlike The DAO hack, no one was enriched; the loss followed from a code oversight in a shared library.
The library contract had never been initialized, allowing any user to call the initialization function and subsequently self-destruct the library—bricking all dependent wallets.
Legal Analysis: Bug as Mutual Mistake?
Under mutual mistake doctrine, contracts may be voidable when both parties share a mistaken belief about a basic assumption on which the contract was made, and the mistake materially affects the agreed exchange.11
Applying this to the Parity incident:
- Shared mistaken belief: Both developers and users believed the wallet would function as intended (securely holding funds)
- Basic assumption: The smart contract code correctly implemented wallet functionality
- Material effect: The bug rendered millions in funds inaccessible
However, software typically comes with warranty disclaimers. Parity’s wallet software was licensed under the GNU General Public License v3.0, which provides the software “as is” and broadly disclaims warranties and developer liability.17 Whether such disclaimers defeat a mutual-mistake theory in the smart contract context is, in our assessment, untested in court.
Key distinction: Parity (unlike The DAO) involved a bug causing loss to users, not an attacker enrichment. Courts may view passive loss differently than active exploitation when applying equitable doctrines.
Lessons for Developers
The Parity incidents raised questions regarding liability for software oversights:18
- Can open-source license disclaimers shield developers from negligence claims?
- Does deploying immutable financial software create higher duty of care?
- Should users expect buyer beware or reasonable security assurance?
Risk mitigation strategies include:
- Multiple independent security audits before deployment
- Bug bounty programs incentivizing vulnerability discovery
- Phased rollouts limiting initial value at risk
- Upgrade mechanisms or pause functions (trading immutability for security)
- Explicit user warnings about novel technology risks
Dispute Resolution: Arbitration and Jurisdiction
Traditional contracts specify governing law and dispute resolution mechanisms. Smart contracts executing on blockchains without clear jurisdictional nexus create unique challenges.
Jurisdictional Uncertainty
Smart contracts operate via distributed nodes potentially located worldwide. This raises questions:
- Which jurisdiction’s law applies?
- Where can litigation be brought?
- Can courts compel performance or rescission of on-chain transactions?
The Van Loon v. United States Department of the Treasury case illustrated these challenges. The Fifth Circuit held that Tornado Cash’s immutable smart contracts are not “property” within the meaning of IEEPA or OFAC’s regulatory definition, because they are not capable of being owned—no one can exclude anyone else from using them—and that OFAC therefore exceeded its statutory authority.19 If smart contracts cannot be tied to a legal actor, enforcement—both private and regulatory—becomes extremely difficult.
Arbitration as Preferred Solution
Arbitration offers several advantages for smart contract disputes:20
Certainty: Parties specify:
- Governing law
- Seat of arbitration
- Arbitrator qualifications (need blockchain expertise)
Enforceability: Arbitration awards are enforceable abroad under the New York Convention, though an arbitration agreement embedded in or incorporated by code may not satisfy the Convention’s writing requirement.20
Confidentiality: Arbitration is not confidential by default in every jurisdiction, so the parties should expressly agree to confidentiality to limit disclosure of proprietary smart contract details.20
Expertise: Parties can select arbitrators with technical blockchain knowledge rather than generalist judges.
Best Practices for Arbitration Clauses
Effective smart contract arbitration provisions should specify:21
- Governing law and seat: Choose the same jurisdiction for both to avoid conflicts; in 2018, Arizona, Tennessee, and Delaware were regarded as the friendliest governing-law choices for smart contract enforcement21
- Arbitration rules: Adopt rules written for smart contract disputes22
- Arbitrator qualifications: Require blockchain/smart contract expertise
- Discovery limits: Control costs by limiting document production22
- Injunctive relief procedures: Address urgent matters (oracle failures, security breaches)22
JAMS has issued specialized Smart Contract Rules, provided in draft for review and comment, governing disputes arising out of smart contracts and recognizing their distinctive technical considerations.22
Wyoming DUNA: Smart Contract Legal Recognition
Wyoming’s Decentralized Unincorporated Nonprofit Association (DUNA) Act gives DAOs a state-law entity form whose governance can run through smart contracts.23
Key Features
Enacted in March 2024 (effective July 1, 2024), the DUNA Act allows DAOs to organize as legal entities with:23
- Legal entity status: Can own property, enter contracts, sue and be sued
- Limited liability: Members enjoy corporate-style liability protection
- Smart contract governance: Governing principles can be embedded directly in on-chain smart contracts
- Operational flexibility: Token votes and smart contract proposals legally bind the organization
For our purposes, the critical innovation is formal legal recognition of smart contract governance. A DUNA “may provide for its governance, in whole or in part, through distributed ledger technology, including smart contracts,” so on-chain code can carry the association’s governing rules with statutory backing.23
Implications for Smart Contract Enforceability
The DUNA framework demonstrates that “code as governance” is legally feasible when properly structured:
- Smart contracts operate within a legal entity wrapper providing liability protection
- Human-readable governing documents complement code (not replaced by code)
- Members retain traditional legal rights (courts can still intervene for fraud, illegal activity)
- Formalities matter: Registration, annual compliance, and proper documentation required
This hybrid approach—legal entities using smart contracts for governance while maintaining legal personality—may become the model for enforceable smart contract systems.
For detailed guidance on DAO legal structures, see our article on DAO Liability After Lido: Why You Need a Legal Wrapper.
Ricardian Contracts: Bridging Law and Code
The most promising approach to smart contract legal enforceability may be Ricardian contracts—hybrid instruments readable by both humans and machines.
What Are Ricardian Contracts?
Developed by Ian Grigg and Gary Howland as part of the Ricardo payment system, and in use since 1996, Ricardian contracts are documents that:24
- Human-readable: Written in natural language (English, etc.)
- Machine-readable: Structured data format enabling automated processing
- Cryptographically secured: Digitally signed and hashed to prevent tampering
- Contract-form: Offered by an issuer to holders as a contract, and laid out so a court can be asked to accept the single document as the parties’ agreement
The fundamental advantage: If disputes arise, parties can litigate based on the human-readable prose while the machine-readable portion enables automated execution for undisputed performance.
How They Work
A Ricardian contract typically includes:
Legal prose layer:
Agreement between [Party A] and [Party B] whereby Party A agrees to
deliver [quantity] of [asset] to Party B upon payment of [price],
with delivery occurring no later than [date]. Dispute resolution via
arbitration under [rules] in [jurisdiction].
Machine-readable layer:
{
"parties": ["0x123...", "0xabc..."],
"asset": "TOKEN_ABC",
"quantity": 1000,
"price": { "amount": 50000, "currency": "USDC" },
"deliveryDeadline": "2026-12-31T23:59:59Z",
"arbitration": { "rules": "AAA", "seat": "Wyoming" }
}
Smart contract execution layer:
function executeDelivery() external {
require(block.timestamp <= deliveryDeadline, "Past deadline");
require(payment.received, "Payment not confirmed");
token.transfer(buyer, quantity);
}
Legal Enforceability Advantages
Ricardian contracts address several enforceability problems. In our assessment:
1. Disclosure and Assent: The human-readable prose, readable by machines and by people alike, satisfies disclosure requirements. Users can meaningfully understand terms before accepting.25
2. Mutual Assent: The issuer signs the human-readable offer, and a counterparty accepts by a transaction that references the document’s hash, tying assent to a specific, unalterable document rather than to a bare function call.25
3. Interpretation: When code behavior diverges from reasonable expectations, courts can interpret the natural language prose rather than attempting to discern what the code intended.
4. Gap-Filling: The legal prose can address contingencies impractical to code (force majeure, material adverse change, good faith obligations).
5. Dispute Resolution: Courts receive a familiar legal document rather than raw smart contract bytecode, which can contribute to faster resolution of disputes.25
Implementation Challenges
Despite their promise, Ricardian contracts face adoption hurdles:
- Requires both legal drafting and technical implementation (higher upfront costs)
- Human-readable and machine-readable portions must remain synchronized
- Limited tooling and standardization
- DeFi protocols resist introducing human-readable terms (perceived centralization)
However, for high-value commercial transactions, tokenized securities, and institutional DeFi, Ricardian contracts offer the most legally defensible approach.
For more on institutional-grade legal structures, see our guides on DeFi Protocol Legal Structure and Treasury Management for Crypto Companies.
Best Practices for Legally Enforceable Smart Contracts
Drawing from the analysis above, here are practical recommendations for developers and businesses:
1. Don’t Rely on “Code Is Law”
Accept that courts will apply traditional legal doctrines regardless of what your smart contract or terms of use claim. Design with this reality in mind.
2. Provide Clear Disclosures
Before users interact with smart contracts:
- Explain functionality in plain language
- Disclose risks, including bugs and vulnerabilities
- Identify external dependencies (oracles, admin keys)
- Specify governing law and dispute resolution
- Require affirmative assent beyond mere function call
3. Use Ricardian Contracts for High-Value Transactions
When stakes are significant:
- Draft traditional contract prose alongside code
- Ensure both versions cover the same terms
- Use digital signatures for both components
- Specify that legal prose governs in case of conflict
4. Address Oracle Failures Explicitly
If your smart contract depends on external data:
- Identify oracle providers and data sources
- Specify backup procedures if oracle fails
- Allocate risk explicitly (who bears loss?)
- Consider multi-oracle redundancy
- Implement sanity checks and circuit breakers
5. Include Robust Arbitration Clauses
Rather than hoping code never fails:
- Specify arbitration for all disputes
- Choose crypto-friendly governing law
- Require arbitrators with blockchain expertise
- Define procedures for emergency injunctive relief
- Make arbitration awards executable on-chain
6. Security Audits Are Not Optional
Multiple independent security audits before deployment should be non-negotiable for any smart contract handling significant value. Audits don’t eliminate bugs, but, in our view, a documented audit record is the best evidence of care a developer can offer if liability is later contested.
7. Consider Mutability Mechanisms
Pure immutability creates legal problems when bugs emerge:
- Upgradeable proxies allow bug fixes
- Pause functions prevent ongoing harm
- Admin multi-sigs enable emergency response
- Time-locks give users exit opportunities
Balance immutability benefits against legal and security risks. For guidance on governance structures enabling safe upgrades, see DAO LLC Formation Guide.
8. Form a Legal Entity
Operating smart contracts through a legal entity (Wyoming DAO LLC, Delaware corporation, Swiss foundation) provides:
- Limited liability for developers and users
- Clear jurisdictional nexus for dispute resolution
- Ability to own assets and enter off-chain contracts
- Regulatory compliance framework
For detailed entity comparison, see our article on DeFi Protocol Legal Structure: LLC, Foundation, or DAO?.
The Path Forward: Convergence, Not Replacement
The original “code is law” vision—replacing human legal systems with deterministic smart contracts—has proven unworkable. Code cannot account for every contingency, bugs are inevitable, and courts will not abdicate their authority to algorithm.
But the converse—dismissing smart contracts as legally meaningless—is equally wrong. Smart contracts offer genuine efficiencies: automated execution, reduced counterparty risk, transparent terms, and global accessibility.
The future lies in convergence: legal frameworks that recognize smart contracts as valid instruments while preserving essential protections, and smart contract designs that complement rather than replace traditional legal mechanisms.
Ricardian contracts, Wyoming’s DUNA framework, and specialized arbitration rules for blockchain disputes represent early steps toward this synthesis. As courts develop more precedent and legislators enact thoughtful frameworks, smart contract legal enforceability will become clearer.
Until then, developers and businesses deploying smart contracts should proceed with sophisticated legal guidance. The technology is ready. The law is catching up. Success requires navigating both simultaneously.
Need Smart Contract Legal Guidance?
Astraea Counsel helps DeFi protocols, DAOs, and blockchain projects structure legally enforceable smart contract systems, implement Ricardian contract frameworks, and navigate regulatory compliance. Explore our Digital Assets & Blockchain services.
Related Resources
- DAO Liability After Lido: Legal Wrapper Requirements - Entity structures for DAO smart contract governance
- DeFi Protocol Legal Structure: LLC, Foundation, or DAO? - Comprehensive entity comparison
- Token Launch Legal Checklist: SEC Compliance - Securities law for tokenized assets
- Treasury Management for Crypto Companies - Custody and operational legal frameworks
- Contact Us - Discuss your smart contract legal strategy
Disclaimer: This article provides general information for educational purposes only and does not constitute legal advice. Smart contract legal enforceability is highly fact-specific. Consult qualified legal counsel for advice on your specific smart contract deployment.
Footnotes
-
Diego Latorre, “The DAO Hack of 2016: Ethereum’s $50 Million Nightmare and Its Lasting Impact on DeFi, Law, and Policy,” Medium (Mar. 10, 2025), available at https://latorreattorney.medium.com/the-dao-hack-of-2016-ethereums-50-million-nightmare-and-its-lasting-impact-on-defi-law-and-ef0c494440d4; Gemini, “DAO Hack Explained: How a Vulnerability Split Ethereum” (updated Dec. 4, 2025), available at https://www.gemini.com/cryptopedia/the-dao-hack-makerdao (the open letter came from “the attacker—or someone posing as the attacker; it has not been verified”). ↩
-
DefiLlama, Total Value Locked, All Chains (Sept. 6, 2026) ($88.2 billion), available at https://defillama.com/ ↩
-
Restatement (Second) of Contracts § 17 & cmt. c (A.L.I. 1981). ↩ ↩2
-
Patrick v. Running Warehouse, LLC, 93 F.4th 468 (9th Cir. 2024). ↩ ↩2
-
Uniform Law Commission & American Law Institute, Uniform Commercial Code Amendments (2022) (2022) (Article 12, Controllable Electronic Records), available at https://www.uniformlaws.org/committees/community-home?CommunityKey=1457c422-ddb7-40b0-8c76-39a1991651ac ↩ ↩2
-
Illinois Blockchain Technology Act, 205 ILCS 730/1 to /20 (eff. Jan. 1, 2020). ↩
-
Ariz. Rev. Stat. § 44-7061(C); Tenn. Code Ann. § 47-10-202(c) (2018 Tenn. Pub. Ch. 591); Nev. Rev. Stat. §§ 719.045, 719.090 (blockchain defined and included within “electronic record”); Ohio Rev. Code § 1306.01(G)-(H). ↩
-
David Gerard, “The DAO: the steadfast iron will of unstoppable code,” Attack of the 50 Foot Blockchain (Apr. 22, 2017) (excerpt from chapter 10 of the book), available at https://davidgerard.co.uk/blockchain/the-dao/; The DAO, Explanation of Terms and Disclaimer (2016), archived at https://web.archive.org/web/20160622212443/https://daohub.org/explainer.html (“Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain”). ↩
-
Gerard, supra note 6 (“on 17 June, a hacker used this recursive call bug to drain $50 million from The DAO”); Latorre, supra note 1 (3.6 million Ether, approximately $50 million); Gemini, supra note 1 (the tokens remained in the attacker’s possession on the Ethereum Classic chain). ↩ ↩2
-
Gemini, supra note 1. ↩
-
Restatement (Second) of Contracts § 152 (A.L.I. 1981). ↩ ↩2 ↩3
-
Restatement (Second) of Contracts §§ 153, 208, 261 (A.L.I. 1981). ↩ ↩2 ↩3
-
Bill Marino, “Smart-Contract Escape Hatches: The Dao of The DAO,” Hacking Distributed (June 23, 2016), available at https://hackingdistributed.com/2016/06/22/smart-contract-escape-hatches/ (archived at https://web.archive.org/web/20240930205809/https://hackingdistributed.com/2016/06/22/smart-contract-escape-hatches/). ↩
-
Immunefi, “‘Code is Law’ is no Defense for Blackhat Hacking,” Medium (July 4, 2022), available at https://medium.com/immunefi/code-is-law-is-no-defense-for-blackhat-hacking-b083340446f4 (quoting Douglas Park: “‘Code is law’ is not a defense to hacks or theft”). ↩
-
SEC, Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934: The DAO, Release No. 81207 (July 25, 2017) (a report of investigation that by its terms “does not constitute an adjudication of any fact or issue addressed herein, nor does it make any findings of violations”). ↩
-
Leana Ter-Martirosyan, Note, “Smart Contract Accountability Problems: Default Oracle Liability as the Solution,” 2025 Colum. Bus. L. Rev. No. 1 (Sept. 12, 2025), available at https://journals.library.columbia.edu/index.php/CBLR/article/view/14257 ↩ ↩2
-
Wai L. Choy, “When Smart Contracts are Outsmarted: The Parity Wallet ‘Freeze’ and Software Liability in the Internet of Value,” Proskauer, Blockchain and the Law (Dec. 22, 2017), available at https://www.proskauer.com/blog/when-smart-contracts-are-outsmarted-the-parity-wallet-freeze-and-software-liability-in-the-internet-of-value ↩ ↩2
-
Choy, supra note 13. ↩
-
Van Loon v. United States Dep’t of the Treasury, 122 F.4th 549 (5th Cir. 2024). ↩
-
Norton Rose Fulbright, “Arbitrating Smart Contract disputes” (Oct. 2017), available at https://www.nortonrosefulbright.com/en/knowledge/publications/ea958758/arbitrating-smart-contract-disputes ↩ ↩2 ↩3
-
Ibrahim Shehata, “Arbitration of Smart Contracts Part 3 - Issues to Consider When Choosing Arbitration to Resolve Smart Contracts Disputes,” Kluwer Arbitration Blog (Aug. 30, 2018), formerly at https://arbitrationblog.kluwerarbitration.com/2018/08/30/arbitration-smart-contracts-part-3/ (archived at https://web.archive.org/web/20250514081211/https://arbitrationblog.kluwerarbitration.com/2018/08/30/arbitration-smart-contracts-part-3/). ↩ ↩2
-
JAMS, Rules Governing Disputes Arising out of Smart Contracts (draft provided for review and comment), available at https://www.jamsadr.com/rules-smart-contracts ↩ ↩2 ↩3 ↩4
-
Wyo. Stat. Ann. §§ 17-32-101 to -129 (Wyoming Decentralized Unincorporated Nonprofit Association Act, effective July 1, 2024), § 17-32-121(a); Latham & Watkins, FinTech and Digital Assets Blog, “Wyoming Adopts New Legal Structure for DAOs” (Apr. 1, 2024), available at https://www.fintechanddigitalassets.com/2024/04/wyoming-adopts-new-legal-structure-for-daos/ ↩ ↩2 ↩3
-
Ian Grigg, “The Ricardian Contract,” Systemics, Inc. (undated; the paper’s latest reference is dated September 19, 2003), available at https://iang.org/papers/ricardian_contract.html ↩
-
Diederick Cardon, “Ricardian contracts—legally binding agreements on the blockchain,” LTO Network (Medium) (Nov. 30, 2017), available at https://medium.com/ltonetwork/ricardian-contracts-legally-binding-agreements-on-the-blockchain-4c103f120707 ↩ ↩2 ↩3
