Smart Contract

A smart contract is a program stored on a blockchain that runs automatically when the conditions written into it are satisfied, without either party having to take a further step. LabCFTC, the CFTC's innovation office, describes it in a 2018 educational primer as fundamentally a set of coded computer functions that may incorporate the elements of a binding contract, such as offer, acceptance and consideration, or may simply execute certain terms of a contract, and that allows self-executing computer code to take actions at specified times or by reference to the occurrence or non-occurrence of an action or event, such as delivery of an asset, weather conditions, or a change in a reference rate. The primer is an educational document and states that it is not intended to state the official policy or position of the CFTC.

The name is the first thing to set aside, and the primer says so in its own words: a smart contract may be an oxymoron. It is not necessarily smart, being only as smart as the information it receives and the code that directs it. And it may not be a legally binding contract at all. It may be a gift or another non-contractual transfer, it may be only one part of a broader agreement, and to the extent it violates the law it would not be binding or enforceable.

Three attributes do the work, and each carries its own failure mode.

Authentication. Parties identify themselves with digital signatures, private cryptographic keys used to verify participation and assent to the agreed terms. That makes the identity question a key-custody question: whoever controls the key can act as the party, and the code cannot distinguish the owner from somebody who has obtained the key.

Outside data. A contract that turns on a real-world fact needs a source for that fact, which the primer calls an oracle: a mutually agreed, network-authenticated reference data provider supplying information such as commodity prices, weather data, interest rates or whether an event occurred. This is the dependency people underestimate. The primer lists oracle failure or disruption among the technical risks, notes that an attacker may compromise an oracle, and notes that oracles may accept or distribute unexpected information or be subject to manipulation. A contract executes on what the oracle reports, not on what happened, and the two are not always the same thing.

Self-execution. The contract acts without further action by the parties, which is the source of the efficiency and of the exposure. The primer's list of operational risks is worth reading as written: a smart contract may lack adequate backup or failover, may depend on other systems whose vulnerabilities prevent it from working as intended, may sit on a platform missing critical safeguards and customer protections, and may be disrupted by a fork in the underlying chain. It adds that in the case of an operational failure, recourse may be limited or nonexistent and complete loss of a virtual asset is possible. Under technical risk it lists unintended software vulnerabilities and, in as many words, that humans make mistakes when coding.

The legal position is the part most often stated backwards. "Code is law" is a design philosophy, not a doctrine any court applies. The primer states that existing law and regulation apply equally regardless of what form a contract takes, that contracts or parts of contracts written in code are subject to otherwise applicable law and regulation, and it lists the frameworks that can reach them, including the Commodity Exchange Act, federal and state securities laws, tax law, the Uniform Commercial Code and the electronic-signature statutes, the Bank Secrecy Act and anti-money-laundering rules, and state money transmission laws. A separate subcommittee presentation to the CFTC's Technology Advisory Committee makes the practical counterpoint about the code itself: the smart contracts underlying a decentralized trading venue are, in its word, alegal, meaning they do not necessarily incorporate regulatory compliance. Both things are true at once. The obligation exists; the code does not enforce it.

Reviewability deserves a measured note rather than reassurance. Contract code deployed to a public chain is usually readable by anyone, and paid code reviews are a common practice before launch. A review is a judgment about a specific version of the code at a specific moment, by people who may not anticipate how the contract will interact with other contracts later. It reduces the chance of an obvious defect and does not convert the code into a guarantee.

A smart contract is written, then deployed to a blockchain, where it becomes a program with its own address on the ledger. From that point anyone can call it, and the network's validators run its code and record the result. Because it lives on the ledger, its logic is visible and, on most chains, cannot be altered once deployed unless the code was written with an upgrade path built in. Calling the contract costs a network fee, paid in the chain's own asset.

A hypothetical shows both the mechanism and the oracle dependency. A grower and an insurer agree on a parametric payout: if a named weather service reports fewer than 4 inches of rainfall at a specified station during June, the contract pays the grower $10,000; otherwise the insurer keeps the premium. The insurer deposits $10,000 into the contract in advance, so there is nothing to collect and no claim to file. On July 1 the contract reads the weather service's figure. If the reported figure is 3.2 inches, the $10,000 moves to the grower automatically within the same transaction; if it is 4.6 inches, the deposit returns to the insurer.

Now change one fact. The station malfunctions and reports 6 inches during a drought. The contract pays nothing, correctly, according to its own terms, because it executed on the reported figure. Recovering the $10,000 is then an ordinary legal dispute against the weather service or the insurer, conducted in the ordinary way, and the automation has bought nothing at the moment it mattered most. That is what the primer means when it says the operation is only as smart as the information feed it receives.

What smart contracts genuinely do well

• They remove the settlement step. Once the condition is met, the transfer happens without either party having to perform, which cuts the risk that a counterparty simply does not pay.
• The terms and the code are public on a public chain, so anyone with the skill can read exactly what will happen rather than relying on a description.
• Standardized code and automated execution can lower the cost of arranging and administering small or repetitive agreements.
• Compliance conditions can be built into the code itself, for example a restriction that prevents a transfer to an ineligible party.

What they do badly, or not at all

• A bug is not a customer-service problem. Code that executes as written executes its errors as written, and on most chains it cannot simply be corrected after deployment.
• The oracle is a single point of failure that sits outside the contract's own guarantees and can be wrong, disrupted, or deliberately manipulated.
• "Smart contract" does not mean "enforceable contract". It may be a non-contractual transfer, only part of a wider agreement, or unenforceable because what it does is unlawful.
• Recourse after an operational failure may be limited or nonexistent, and the primer states that complete loss of a virtual asset is possible.
• Governance is often an afterthought. A contract may need attention, action and revision, and there may be no mechanism and no responsible party to provide them.