Smart contracts
Programs that hold money and execute themselves. Neither smart nor contracts, and the gap between what they say and what they mean has cost billions.
A smart contract is a program stored on a blockchain. It has an address, it can hold a balance, and it runs when someone sends it a transaction. Nobody operates it and nobody can stop it.
A concrete example
An escrow contract: it accepts funds from a buyer, holds them, and releases them to a seller when a condition is met or returns them after a deadline. Written correctly, neither party can cheat and no third party is needed — the rules are the code and the code runs itself.
A contract cannot be edited once deployed. Developers who want upgradeability must build it in deliberately — usually a proxy pattern where a fixed address forwards calls to a replaceable implementation. That reintroduces an administrator who can change the rules, which is the exact thing users assumed was absent. Whether a contract is upgradeable, and who holds that power, is among the first things worth checking.
Why the name is misleading
- Not smart. There is no judgement or interpretation. Instructions execute literally, including instructions that were mistakes.
- Not contracts. A legal contract states intent, and courts interpret it when reality does not match. Here there is no interpretation and no appeal.
- No force majeure. If circumstances change, the code does not.
The phrase means outcomes are whatever the code produces, including when a flaw lets someone drain it. That position was tested directly in 2016 and the community that coined it chose, by majority, to intervene. See the DAO and the fork. What the episode showed is that code executes automatically and humans still decide what to do about the result.
How they actually fail
- Logic errors. The code does what it says and what it says is wrong. No amount of decentralisation helps.
- Reentrancy. A contract calls an external one before updating its own records, and the external contract calls back in to withdraw repeatedly. The classic exploit, and still found.
- Oracle manipulation. The contract is fine; the price feed it trusts was moved temporarily, and the contract acted on a false input.
- Access control. A privileged function left callable by anyone. Elementary, and it keeps happening.
- Key compromise. The contract is sound and whoever holds the admin key was phished.
- Composition. Two contracts each safe alone, unsafe when combined in a way neither author anticipated.
Audits, and what they are worth
A reputable audit is a serious review by people who do this professionally, and it raises the bar substantially. It is not a guarantee: audited contracts have been exploited, audits are scoped to specific code at a specific commit, and the phrase "audited" on a marketing page may refer to a cursory review by an unknown firm.
The useful questions are: by whom, of what version, were the findings published, and were they fixed.
What to actually check
- Is the source code verified and readable at the address, or only compiled bytecode?
- Is it upgradeable, and who controls the upgrade? A single private key is a single point of failure.
- Is there an admin function that can pause, drain or mint? If so, that party can take the funds, whatever the marketing says.
- How long has it held significant value without incident? Time in production is imperfect evidence and it is the best available.