Legal Contract Formation in Smart Contracts

In most civil and common law legal systems, a "contract" may be summarized as any legally enforceable agreement between two or more parties. Smart/Ricardian contracts and traditional contracts may be used in tandem to provide deterministic execution alongside legal enforceability and remedies, while leaving flexibility for sensitive "meatspace" terms and mutual amendments in the parties' preferences. The fundamental underpinnings of contract law present some questions on when, or whether, the formation of a legally recognizable contract, or element thereof, is evidenced by the express or implied intent of a smart contract's code, or more granularly by changes in state or other operations on the permissionless execution layer, such as the Ethereum blockchain.

Why does this matter? With identifiable parties using smart contracts to remove intermediaries in their agreements, and without explicit code deference, the presence of a legally enforceable contract may be a determinant for meatspace legal remedies (beyond the programmatic), including when on-chain execution affects an unconscionable outcome, or for a mismatch with off-chain intent or concepts of good faith. Even in the absence of a legal contract's formation, other meatspace obligations such as promissory estoppel or restitution may arise.

Commercial law has long recognized some ability to form a legal contract with mutual assent even in the absence of a written agreement. For example, for a contract of sale of goods, "conduct by both parties which recognizes the existence of a contract is sufficient to establish a contract for sale although the writings of the parties do not otherwise establish a contract."¹ This article examines some elements of legal contract formation within a blockchain/smart contract context, primarily from the perspective of US law and the Uniform Commercial Code (“UCC”), where the basic formula for legal contract formation is:

Offer + Acceptance + Consideration = Contract

Offer

An offer is the manifestation of willingness to enter into a bargain, so as to justify another actor in understanding that their assent to that bargain is invited and will conclude the bargain.² If a participant is able to exchange value with or interact via a smart contract (i.e. public or external functions without restrictive modifiers, or with such a restriction for which an offeror is whitelisted, etc.) and assent may be given through the offered interface, this could be deemed an open offer. If the smart contract whitelists a counterparty's address for interaction or requests signature from a counterparty's address, that smart contract may constitute an offer solely to that counterparty.

An interminable smart contract may be analogized to a unilateral contract's offer: when one party makes a promise to do something if the other party performs a certain act, noting that the offeree is under no duty to perform such act.

Contract law and UCC specialists will find much to deliberate on concepts such as whether an analogous digital “firm offer” (a signed offer that gives assurance it will remain is irrevocable for a lack of consideration during the time stated or for a reasonable time) can conceivably exist in a time-limited and consideration-soliciting public permissionless smart contract function, or how immutability or upgradeability jives with provisions on amendments, offer revocations, etc.

Acceptance

Generally, a valid acceptance is made (i) to one intended by the offeror to have the right to accept and (ii) during the time in which the offeree still has the power to accept. By private key signature or indicating acceptance by calling a function / sending value to a smart contract (subject to some commercial law limitations/qualifications on the type of implied contract at issue), the counterparty may indicate acceptance to the agreement as an analog to commonly accepted centralized electronic signatures (i.e. in the US, those in compliance with the Uniform Electronic Transactions and E-Sign Acts) or tendered performance. The law tends to recognize rather broad methods of acceptance given an offer’s facts and circumstances, including offers which invite “acceptance in any manner and by any medium reasonable in the circumstances."³

For unilateral contracts, acceptance can sometimes be completed by merely tendering the invited performance: if the offeror requests an action, acceptance may be completed by performance of such action by an intended offeree. In the context of smart contracts, permissionless non-modified public functions invite acceptance from anyone, or with such a restriction for which an intended offeree is whitelisted (see above for an example code excerpt). Smart contracts which invite interaction by external API for acceptance may restrict their intended pool of offerees to those permissioned by the applicable API/oracle mechanism and generally broaden potential methods of acceptance.

Consideration

The element of consideration may be satisfied within a smart contract context where each party exchanges some form of value (which could be ETH, tokens, external value transferred by oracle interaction and evidence/proof returned on chain, or arguably the mere gas cost in some instances, as examined below). "Consideration" in legal contract formation operates to evidence one of two main elements: (1) a mutual bargain between parties, and (2) a legal detriment (something one is not legally obligated to do or something one must refrain from doing that one is legally privileged to do) induced by the promise of such bargain and vice versa. The purposes of consideration include:

1. An evidentiary function: providing objective evidence that the parties intended to make a binding agreement.

2. A cautionary function: the detriment of consideration is meant to encourage parties to be cautious in their agreement entries, and discourage thoughtless or asymmetric bargains or mistakes.

3. Context for facts and circumstances in the underlying contract's interpretation, proof, deliberation, and capacity of parties.

Anyone transacting on Ethereum mainnet can readily identify with the quantifiable detriment posed by gas costs; however, the cost is not necessarily proportional to the value transferred or accessed as much as the complexity of the operation (or quality of the code), nor does the ether paid as gas directly induce the promisor counterparty (instead going to miners or, per EIP 1559, to the incinerator). Especially as scaling solutions kick in or for low-cost layer two/channels/etc., at best, gas costs might be deemed "nominal" consideration outside of especially sophisticated/high-gas operations or anticipated recurring gas costs (for example, entering a complex DeFi dApp requiring periodic harvests or unstaking/withdrawing liquidity). Certain eccentricities of smart contracts may help establish the evidentiary purpose of consideration, such as the additional step and gas expenditure to invoke a state-changing function; this more strongly implies intent than a simple key signature, which could be analogized to a clickwrap agreement in some contexts.

Further complications in the analysis abound, including party “control” of assets/the private keys involved in the agreement, as well as potential control over parameters to the applicable smart contract.

Control

'Control' of electronic and digital assets, information, and authoritative copies have broad legal implications. As a rough analog, UCC § 9-105 deals with the control of electronic chattel paper for purposes of security interest perfection, and provides that 'control' must be evidenced by a system which evidences the transfer of interests in electronic chattel paper in a manner which 'reliably' (according to general unspecified principles of uniqueness, identifiability and un-alterability) establishes that the secured party is the assignee of the electronic chattel paper, but need not be more stringent than those requirements for physical chattel paper.⁴ One might envision a future official comment that extends such uniqueness, identifiability and un-alterability requirements to mechanisms which ostensibly control private keys or IPFS hash pointers or similar, and the control thereof as being no more stringent than those requirements for electronic chattel paper. Given that UCC § 9-105(b) hasn't had significant judicial or regulatory interpretation as of the date of this writing, treatment in a blockchain context is hypothetical, but might be intuitively extrapolated to control of (or multisig requirement of) a wallet’s private key.

A pending item of contract/commercial legal framework to watch is the newly proposed article 12 of the UCC, addressing commercial transactions of "controllable electronic records" or 'CERs'. CERs are likely to include digital assets of various forms, including cryptocurrencies, hard-asset secured digital assets and many flavors of NFTs. The ongoing proposal by the Uniform Law Commission is highly encouraging (a version of which has already been passed in Nebraska), and should provide much-needed clarity and standardization of secured transactions involving CERs, thus providing a pathway for compliant and more sophisticated Ricardian contracts and agreements. The concept and interpretation of 'control' is an imperative focus to establish rules around perfection and priority of claims on CERs, and actual and constructive possession of CERs and thus involvement in such contracts.

Context is important: while the on-chain code may be carefully constructed, commented, and audited to accommodate the foregoing elements of a legal contract, a poorly designed/buggy/malicious front end, import, or other dependency could make the analysis challenging— just like a legal contract with an inconsistency in another agreement incorporated by reference.

1. UCC § 2-207(3).

2. See 2nd Restatement of Contracts § 24.

3. UCC § 2-206(1)(a).

4. UCC § 9-105, Official Comment 3.