What Are Smart Contracts? Code That Holds Money and Cannot Be Patched

A program with a balance

Deploy code to a network that supports it, and the code gets an address like any other. It can hold funds. It runs when someone sends it a transaction, executes identically on every machine validating the network, and produces a result everyone agrees on because everyone computed it.

That is the whole idea, and its consequence is the interesting part: the rules are enforced by execution rather than by a party promising to follow them. Nobody has to trust a counterparty to release funds, because the release is a property of the code that already holds them.

Immutability cuts both ways

A deployed contract cannot be edited. That is what makes its rules credible: you can read them and know they will not change after you commit funds. It also means a bug is permanent, and the history of this field is largely a history of permanent bugs being found by people who benefit from finding them.

The industry's answer is the upgradeable proxy: a permanent contract that forwards calls to a replaceable implementation. It solves the practical problem and quietly reverses the security property, because whoever holds the key to change the implementation can change what the contract does. Many systems described as trustless have one of these at the centre.

The oracle problem

A contract can only see what is on its own chain. Anything else (a price, a match result, a shipment arriving) has to be reported by someone, and that someone becomes a trusted party in a system built to avoid them. This is not a solved problem; it is a managed one, usually by requiring several independent reporters to agree.

It is also where a large share of losses originate. Manipulating the price a contract reads is frequently cheaper than attacking the contract itself, and several of the largest incidents in decentralised finance were oracle manipulations rather than code exploits.

Upgradeable contracts, and the trust they put back

Immutability is inconvenient for anyone shipping a product, so most substantial deployments are not immutable in practice. The common arrangement splits the system in two: a small contract holding the funds and the address, and a second contract holding the logic, with the first pointing at the second. Changing the pointer changes the behaviour.

This is a reasonable engineering answer to a real problem, and it reintroduces exactly the thing the design was supposed to remove. Whoever can change the pointer can change what happens to funds already deposited. The guarantee is no longer the code you read; it is the code whoever holds that permission chooses to point at next.

Neither arrangement is dishonest, and both are visible on chain to anyone who checks. What is worth knowing is which one you are dealing with, because the question to ask differs. For an immutable contract the question is whether the code is correct, since nothing can be fixed. For an upgradeable one it is who holds the key, how many of them there are, and whether a change takes effect immediately or after a delay long enough for a depositor to leave.

Where the term came from, and why it misleads

The phrase predates blockchains by two decades, coined to describe agreements enforced by protocol rather than by courts. The vending machine was the original illustration: put coins in, receive a product, with no clerk and no contract law involved in the exchange.

Applied to deployed code the analogy holds well and the word "contract" does not. Nothing here is drafted, signed, interpreted or enforced in any legal sense, and reading the term as though it were has produced a decade of confused expectations about what happens when the code does something nobody wanted.