Smart Contracts Explained

A smart contract is neither smart nor a contract. It is a program that runs exactly as written, which is a much narrower and more dangerous property than the name suggests.

What it is and is not

A smart contract is a program stored at an address on a blockchain. It has its own state, can hold assets, and executes when a transaction calls it. Every node runs the same code and reaches the same result, so its behaviour is verifiable without trusting the deployer.

What it is not:

• Not legally a contract in most jurisdictions. It is code that moves assets. Whether an enforceable legal agreement also exists is a separate question answered by ordinary law.
• Not intelligent. It has no judgement and no ability to interpret intent. It executes the written instructions, including the mistaken ones.
• Not aware of the outside world. It cannot check a share price, a delivery, or the weather without an oracle telling it, and the oracle then becomes a point of trust and attack.
• Not free to run. Every operation consumes gas paid by whoever calls it.

Immutability, and the ways around it

Once deployed, a contract's code cannot be changed. That is what makes it trustworthy: nobody can alter the rules after you have committed funds. It is also why bugs are catastrophic — there is no patch.

The industry's response has been upgrade patterns, most commonly a proxy: a permanent address that forwards calls to an implementation contract which can be swapped. This restores the ability to fix bugs and reintroduces a trusted party, because whoever controls the upgrade key can change what the contract does.

This is the single most important question to ask about any protocol holding your money: is it upgradeable, and who holds the keys? A protocol controlled by a two-of-three multisig held by pseudonymous founders is a very different risk from one that is genuinely immutable or governed by a timelocked process that gives users notice to exit.

How contracts fail

The recurring categories, most of which have cost nine-figure sums:

• Reentrancy. A contract calls an external address before updating its own state, allowing the callee to call back in and withdraw repeatedly. This was the DAO hack in 2016 and it still appears.
• Access control errors. A function that should be restricted is left callable by anyone. Several large losses have come from a single missing modifier.
• Oracle manipulation. Using a spot price from a thin liquidity pool as a price feed, which a flash loan can distort within one transaction.
• Arithmetic errors, including rounding in the protocol's disfavour and, in older contracts, integer overflow.
• Logic errors in economic design, where the code works as written and the incentives it creates are exploitable.
• Key compromise, where the contract is fine and the admin keys are stolen.

Note that most of these are not exotic cryptography failures. They are ordinary software engineering mistakes, made permanent and placed next to a large pile of money.

Assessing one before you trust it

Few users can read Solidity, and the useful checks do not require it:

1. Is the source verified? On a block explorer, verified source means the published code matches the deployed bytecode. Unverified is a serious warning sign.
2. Has it been audited, and by whom? Read the report, not the badge. Check the date, the scope, whether findings were fixed, and whether the audited version is the deployed one.
3. How long has it operated and how much does it hold? A contract securing large sums for years has survived the strongest possible incentive to attack it.
4. Is it upgradeable, and by whom? Look for a timelock and a multisig with known signers rather than a single key.
5. Is there a bug bounty? A well-funded programme is evidence the team takes security seriously.
6. What are you signing? Approving unlimited spending on a token is a standing permission. Set limits where the interface allows, and revoke old approvals.