The Code

The instruction waits beside the money. If the agreed signal arrives, release the funds; if it does not arrive by the deadline, return them. Once this arrangement is properly funded and operating, the payer need not make a fresh decision at the moment of payment. A specified step of performance has been placed in the machinery. The attraction is immediate: fewer reminders, less delay, and less opportunity to withhold an already promised transfer. Yet the machine acts on a description of the event, through a system someone has chosen and maintained. Its reliability depends on what it is able to control. The code can move the asset entrusted to it. The quality of a delivered service, the meaning of a disputed promise, and the accuracy of an outside report may remain questions elsewhere.

Automatic performance and a legally binding agreement need not have the same boundaries. The Law Commission's 2021 advice on England and Wales distinguished an agreement written in ordinary language but performed through software, a hybrid whose terms occupy both language and code, and an agreement expressed wholly in code. The distinction concerns the role the program plays. In the first arrangement it carries out obligations stated elsewhere; in the others it also helps define them. The report treated automation as a spectrum and adopted a definition that did not require a distributed ledger.¹ That way of asking the question is useful beyond a particular platform. Before deciding whether the program has fulfilled the agreement, we need to know where the agreement is recorded and what authority it gives the program's output. A successful computation establishes one fact; the contractual significance of that computation requires another inquiry.

Suppose the payment depends on a delivery reaching a warehouse. A program can receive a message from a carrier, a sensor, or an authorized inspector. Such an external source is commonly called an oracle. The name does not confer certainty. A scan might record the wrong parcel; a sensor might fail; a trustworthy inspector might apply a different understanding of what counts as delivery. The parties must choose which report matters, what happens when reports conflict, and who bears the consequence of a late correction. The Law Commission identified the reliability of these inputs as a distinct design problem.² The promise has acquired a faster path from evidence to payment, but someone still determines what counts as evidence. Trust now includes the people, devices, and procedures through which the outside world is represented to the program.

Consider the costs through a deliberately spare comparison. One thousand claims each require an ordinary review costing four, for a total of four thousand. An automated process costs one per claim, but in ten cases an erroneous decision causes a further resource loss of two hundred. Its total is then three thousand: one thousand for processing and two thousand for error. Reduce the error count to zero and the total becomes one thousand. Raise it to twenty and the total becomes five thousand, above the original review cost. Speed and uniformity can be valuable without deciding the comparison on their own. The result depends on the cost of mistakes, the frequency of those mistakes, and the alternative process. It also depends on whose costs are counted. A procedure that saves the operator time while shifting loss to a claimant may look economical from only one side.³

Safeguards can change those numbers, though they change the character of the commitment too. A waiting period permits a disputed signal to be checked before funds move. An emergency stop can contain a discovered defect. An independent reviewer can decide a question that was difficult to specify as a fixed instruction. Each arrangement locates a power to delay or redirect performance. The parties must then consider who holds that power and how it might be used. A payer able to stop every inconvenient transfer has recovered the discretion that automation was meant to constrain. A system that cannot stop an obvious mistake may preserve certainty about execution at the expense of the intended exchange. The relevant comparison is between concrete arrangements for performance and correction. There is no single amount of discretion that suits every obligation.⁴

A completed transfer also need not settle the parties' remaining entitlements. The program might implement the wrong instruction, rely on a false input, or perform exactly as written while the surrounding agreement has a separate defect. The Law Commission expressly distinguished reducing nonperformance from eliminating defective performance, and examined remedies in that setting.⁵ The practical work of correction remains consequential. Even where a recipient owes a return, obtaining it requires an identifiable person, reachable assets, or some other effective arrangement. Conversely, an automated refund can resolve a routine failure without any court being asked. The code changes which steps happen immediately and which require further action. It does not follow that every legal and factual question has been answered merely because a ledger now records the movement of an asset.

The volume began with the authority that gives a promise force. It ends with a machine that can carry out a specified performance without waiting for a new command from the promisor. Between those points lie the same enduring questions: what has been promised, what makes the promise credible, who identifies the relevant event, and how a failure is corrected. Code can answer part of this institutional problem with exceptional precision. Its contribution becomes clearest when that part is identified. The next volume turns to The Money, in which so many of these obligations are measured and discharged. Before a program can pay, before a court can award a sum, before a promise can name its price, there must be an account in which that sum has meaning.