What Are Smart Contracts? Code That Holds Money

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.