The term smart contract was coined in 1994 by a computer scientist writing about the automation of agreements, fifteen years before there was a machine that could run one. That gap matters, because it explains the mismatch in the name. What the 1994 essay described was a class of arrangements that execute themselves: vending machines, car leases with automatic repossession, financial instruments that settle without a lawyer in the room. What the blockchain industry built is narrower and more specific: a program that runs on a shared computer, with a state that everyone can read and nobody can quietly edit.
The difference between those two things is not academic. A written contract is a set of promises that a human institution will interpret, and the interpretation is where most of its value lives. A program is a set of instructions that a machine will follow, and no institution interprets anything. Reading one as the other explains both the enthusiasm and the failures: enthusiasm because a program settles without asking permission, and failures because almost everything people assume a contract will do for them when things go wrong is provided by the interpretation layer that a program does not have.
Who writes the terms, and what ambiguity produces
In a negotiation, the wording is the battleground. Two parties argue over definitions because a competent agreement has to cover the cases nobody expects, and the residual ambiguity is deliberate: words like reasonable, material and commercially impracticable are left open so that a later dispute can be resolved by people who know the facts. A contract that tried to specify every case would take a decade to draft and would still fail at the same point.
A program has the opposite property. Instructions cannot be ambiguous, because a machine has no way to choose between readings, so every ambiguity becomes a bug. That sounds like an improvement over wordy agreements, and it is one until the program encounters the case its author did not consider, at which point the outcome is whatever the code happens to do rather than whatever the parties would have agreed. The absence of drafting latitude is the same property that makes it fast and cheap to run.
There is a third difference hidden in the same row. A written contract can be breached, and the breach is a fact that a court establishes and then prices. A program cannot be breached, because there is no obligation to violate: it either runs to completion or it stops. This is not a semantic quibble. It is the reason a lender can negotiate with a borrower whose loan is underwater, and the reason nothing negotiates with the lending protocol that holds the same position.
The cases a program has no category for
Three examples show how much work the missing layer normally does. A factory cannot ship because a port closed after a storm, and a supply agreement with a force majeure clause suspends performance rather than penalising it. A borrower misses a payment because the bank processing it failed, and a court distinguishes that from a borrower who chose not to pay. A currency is redenominated overnight and a contract denominated in it is adjusted by law rather than by the parties.
A program cannot express any of those adjustments, because each one depends on a fact about the world that is not in its state, and on a decision that is made after the fact by an institution with the power to make it. Every one of those three scenarios can be replicated on a chain only by introducing exactly the thing the design was meant to remove: someone, or something, with the authority to change the record.
The industry calls that something an oracle when it supplies facts and a governance process when it changes parameters, and both are honest names for the same admission. The moment a program needs to know what the weather did, or what a court decided, or how a constitution defines the currency, it depends on an external party whose report the program accepts.
Who holds the money, and what the code decides about it
Escrow is the part of contract practice that looks most like automation, and the difference is instructive. A conventional escrow holds funds with a third party who releases them on documented conditions, and if the conditions turn out to be unclear the third party asks the parties and, failing that, asks a court. A program that holds funds releases them on conditions it checks itself, and if the conditions are wrong there is nobody to ask.
The history of this specific arrangement is unusually well documented. In 2016 a fund structure known as a decentralised autonomous organisation was drained because an external call was made before the internal balance was updated, which allowed the recipient of that call to re-enter the function and repeat the withdrawal. Roughly three and a half million units of the network’s currency were taken, and the eventual remedy was not a legal procedure but a coordinated change to the chain to move the funds, which split the network into two chains that both exist today.
The following year produced two further lessons in the same category. A widely used multi-signature wallet contract was drained of about 150,000 units through a flaw in how the ownership list was initialised, and a few months later the shared library that contract depended on was triggered into a self-destruct state by an unrelated user, permanently freezing roughly 513,000 units held in hundreds of wallets that had done nothing wrong. Neither loss involved a broken signature scheme. Both were programs behaving exactly as written.
The pattern across those three episodes is the one this article keeps returning to. The engineering failure in each case was ordinary, and the extraordinary part was the absence of any mechanism to unwind it: no trustee with discretion, no regulator with a seizure power, no court with jurisdiction over a contract that has no legal person behind it.
Who resolves a dispute, and what the absence costs
Programs do have a kind of dispute resolution, and it is worth being precise about its limits. Upgrades are possible if the author put a mechanism in place: a proxy contract can be pointed at new logic, a governor can vote on parameter changes, and a pause switch can stop a function while an incident is investigated. Every one of those mechanisms converts immutability into trust, because the party able to point the proxy at new logic can also point it at logic that takes the money.
That trade is not hypocritical and it is frequently the right one. A lending market that can pause during an exploit loses some of its censorship resistance and gains a way to respond to the kind of failure that cannot be reversed afterwards. What matters is that holders read which arrangement they are in, because the marketing language is identical in both cases: a protocol with a governance token and a pause guardian is a different instrument from one whose code can never change, and the interface will not say so.
A handful of jurisdictions have enacted statutes recognising blockchain records, and none of them turns a program into a contract with remedies attached. At most they confirm that a record kept on a distributed ledger can satisfy a writing requirement. The question of who is liable when a program transfers value it should not have is being answered case by case, in ordinary courts, applying ordinary law to arrangements that were designed to avoid the need for both.
All or nothing, and the cost of the attempt
Atomicity is the technical name for the property that makes composability possible. A single call either writes every change it makes or writes none, and because it writes none when it fails, one program can safely call another inside the same transaction without worrying about leaving the second in a strange state. That is what allows a swap, a loan and a transfer to happen in one operation with no settlement window between them, and it is the single feature that conventional back-office systems spend the most engineering to imitate.
The cost is charged separately and is easier to miss. The work performed is paid for whether or not it produced a result, so a failed attempt is an expense rather than a non-event. That detail is why a program with a bug can drain a user’s balance in fees while returning an error, and why the economics of writing a contract are inseparable from the economics of calling one. The meter runs for the attempt, not for the outcome.
What programs do that documents cannot
Set against all of that, the capabilities are real and specific, and a fair reading of the comparison needs them listed with the same precision. A program executes without a venue: there is no opening or closing time, no counterparty credit check, no intermediary to coordinate, and no possibility that the operator declines to process a transfer. It composes with other programs by default, because a call is a function name rather than an integration project. Its rules are public, so anyone can verify what it does before trusting it with value, and its record is public, so anyone can verify what it did after.
Those properties are worth a great deal in settings where the alternative is worse. A collateralised loan that liquidates automatically has no workout negotiation, which is harsh, and it also has no discretion about who gets liquidated first. A settlement that happens because the program says so does not depend on a bank being open in both jurisdictions. An instrument that anyone can audit does not require trusting a custodian’s statement about what it holds.
The honest way to state the trade is that a program substitutes determinism for discretion. Determinism is valuable when the parties want the same outcome in every state of the world, and dangerous when the state of the world is what determines whether the outcome is fair. Most of the hostility in this debate comes from each side evaluating the substitution in settings where the other property dominates.
Where the two are already stitched together
The current state of the art is neither pure code nor pure paper, and the interesting engineering is in the seam. A lending protocol holds collateral under a legal agreement in some jurisdictions and under code in all of them, and the enforceable part is the agreement. A stablecoin is a contract with an issuer and a program on a chain, which is why the holder’s claim lives in a document and their ability to move the balance lives in code. An institutional tokenised security is a ledger representation of an asset whose legal home has not moved, with a transfer agent or depository in the loop precisely because a court will need someone to address. Every serious tokenisation mechanism running today keeps a regulated entity inside the loop, and the reason is not conservatism.
What emerges from the seam is a division of labour that neither side of the argument predicted. Code handles execution, custody during the life of an arrangement, atomic settlement and public verification. Documents handle interpretation, remedies, the treatment of outside events, and the ranking of claims when a party fails. Projects that describe themselves as replacing the second with the first are describing an aspiration, and projects that describe the first as unnecessary are describing a cost centre.
What the machine underneath actually holds
Four parts of a running program decide what it can and cannot do, and the vocabulary is worth having because most arguments about smart contracts are really arguments about which part a problem belongs to. The first is storage, which is a persistent key-value space attached to the contract’s address. Reading from it is cheap, writing to it is among the most expensive operations the network prices, and its contents are shared: every caller sees the same values, and a change made by one is visible to the next.
The second is execution, which is a sequence of instructions run by every validating machine. A call from one program to another transfers control rather than sending a message into a queue, so the called code runs inside the same transaction and can call back. That design is what makes composition possible and it is also the origin of the most famous class of bug in the field, because the calling program may be halfway through its own bookkeeping when control returns.
The third is the event log, which is an append-only output that programs cannot read. Events exist so that outside observers can index what happened without replaying the whole chain, and treating them as state is a common mistake: a program that needed to know what another had logged would have to ask a separate system, which reintroduces exactly the trusted intermediary the design avoids.
The fourth is the value attached to a call. A program can hold assets of its own, which is what makes it a counterparty rather than a calculator, and the assets it holds are controlled by its code. There is no account officer, no signing authority and no spending limit written anywhere except in the instructions, which is why the question “who can move this money” has a purely technical answer.
Read together, those four parts explain the shape of everything that has been built. Storage is expensive, so designs minimise it and lean on computation. Execution is shared, so a program that behaves badly slows down everyone using it. Events are observable but not readable, so any coordination between programs happens through calls rather than through notices. And value sits inside programs, so the risk of a bug is measured in money rather than in downtime.
Standards are the closest thing to regulation
There is no supervisor for this ecosystem, and there is something that functions in a narrower way: interface standards that every wallet, exchange and lending market agrees to support. A token that does not implement the widely used fungible-token interface cannot be listed by most infrastructure; a non-fungible token that ignores a different interface cannot be displayed by marketplaces; an approval pattern that does not match the common one cannot be revoked by the tools users have.
Standards of that kind are proposals rather than laws, and their authority comes from adoption rather than from enforcement. A developer who ignores them is not penalised; they simply do not interoperate, which in a system whose value comes from composition is a severe penalty in practice. That gives the ecosystem a form of discipline that is weaker than regulation and faster than it: a widely used standard can be adopted in months without a legislature, and it can be broken by a new design that offers something better.
Two limits are worth stating plainly. Audits are opinions about specific code at a specific time, not guarantees, and the field has a long record of audited programs being drained afterwards. And formal verification proves that a program satisfies a specification, which is only as good as the specification: a contract can be proven correct and still be wrong, because the property that mattered was not the one that was proven.
Three failures, and what each one changed
The history of contract security is short and unusually well documented, and each era ended with a pattern rather than with a patch.
| Period | What broke | What became the standard practice |
|---|---|---|
| 2016 | A program updated its own record after handing control to another, and the other came back for more before the update landed | Write state before making external calls, and add a guard against re-entry |
| 2017 | Two separate flaws in widely used multi-signature code: one in how ownership was initialised, and one that let a shared library be disabled by a stranger | Initialisation guards, and treating shared code as a dependency with its own audit trail |
| 2020 onward | Contracts that read a price from a single venue could be pushed by a very large, very short-lived loan taken inside one transaction | Multiple independent price sources, time-weighted averages, and deliberate delays before a price can be acted on |
The pattern in that table is the one worth remembering about programs in general. Each failure was an ordinary engineering mistake, each fix was a specific technique, and the accumulated techniques are now part of what a competent developer is expected to know. Nothing in the sequence required a regulator, and nothing in it produced a mechanism for compensating the people who lost money.
The distinction worth keeping
A smart contract is a program that holds and moves value according to rules anyone can read. It is not a contract, it has no remedies, and it cannot be breached. That sentence is not an attack on the technology; it is the specification of what the technology is good for. Programs are extraordinarily good at the parts of an agreement that can be reduced to rules and checked by a machine, and those parts are a large fraction of what financial plumbing does all day.
The cases that require judgement are the cases where the money goes missing. A judge can order a transfer back, freeze an account, examine intent, and weigh the consequences of alternatives on parties who did not foresee the situation. A program does none of that, and the reasonable expectation is not that it will learn to, but that the arrangements built on top of it will continue to put entities with legal personality at the boundaries, exactly where every working deployment already has them. The interesting question for the next decade is not whether code replaces contracts. It is which parts of an agreement each side should hold, and whether anyone building knows which side they are standing on.
[…] forecloses at the threshold because it cannot distinguish temporary difficulty from terminal. A program has no category for the cases that make negotiation valuable, and in a falling market that absence is felt as speed rather than as […]