Smart contract risk: what actually goes wrong in code
Defect classes, economic exploits and upgrade paths are the recurring shapes of on-chain loss, and an audit removes none of them completely.
Smart contract risk is the gap between what a program that holds assets was intended to do and what it will actually do when a motivated stranger interacts with it. The gap is rarely exotic cryptography; it is ordinary software defects operating on funds that anyone in the world can reach without permission. Because settlement is final and the code is the whole of the agreement, losses tend to be abrupt and largely unrecoverable.
Why the code is the entire agreement
A smart contract deployed to a chain running the EVM or a comparable machine executes exactly as written for every caller. There is no clerk to catch an implausible instruction, no settlement desk to reverse a transfer, and often no legal entity with an obligation to make anyone whole. Three properties make this harder than ordinary software. Anyone can call any public function, so the attacker is not constrained to a supported workflow. Contracts compose, meaning another contract deployed later can interact with this one in ways its authors never modeled. And the entire state is public in advance of execution, so an attacker can read the exact conditions required to trigger a defect and test the sequence at leisure before spending anything.
The defect classes that recur
A small set of failure shapes accounts for a large share of documented losses.
- Reentrancy. A contract makes an external call before updating its own accounting, and the called party calls back in to withdraw again against stale state. The 2016 failure of The DAO on Ethereum, which led to a contentious hard fork, is the canonical case, and the pattern still appears in new code.
- Missing or wrong access control. A function that changes ownership, mints, or moves funds is left callable by anyone, or is protected by a check that a caller can satisfy trivially.
- Arithmetic and rounding. Share accounting in a vault that rounds in the depositor's favor, or an empty-vault edge case that lets a first depositor manipulate the share price for everyone after them.
- Unsafe assumptions about other tokens. Code that assumes every ERC-20 returns a boolean, never charges a transfer fee, and never rebalances balances will misaccount for tokens that do any of those things.
- Unvalidated external data. A contract trusts a price, a signature, or a callback without checking freshness, source or bounds, which is the subject of the next two articles in this track.
- Upgrade and initialization errors. A proxy left uninitialized, an implementation contract that can be self-destructed, or a storage layout changed in an upgrade so that two variables now occupy the same slot.
Economic exploits are not bugs in the ordinary sense
In a large class of incidents the code did precisely what it was written to do, and the loss came from an assumption about markets embedded in the design. A flash loan lets any address borrow a very large amount within a single transaction provided it repays before the transaction ends, which removes capital as a barrier to manipulation. If a lending protocol values collateral using a price source that is shallow enough to be pushed, an attacker can borrow, push the price, extract, and repay inside one atomic transaction. Nothing was hacked in the everyday sense. A design assumed that manipulating a market is costly, and for that market it was not. Reviewing code alone will not catch this class; it requires reasoning about the liquidity of every asset the system trusts.
What an audit is, and what it is not
An audit is a time-boxed review of a specified commit by a specified team, delivered as a report with findings and a scope statement. It is not a warranty, not a guarantee of solvency, and not a statement about the economic design unless the scope says so. Several qualifications matter when reading one. Code deployed later, or an upgrade shipped after the review, was not audited. Findings marked acknowledged rather than fixed remain in the deployed system. Formal verification proves a program satisfies stated properties and cannot prove that the stated properties were the right ones. Bug bounties and time in production with meaningful value at stake are additional evidence, and none of these is a substitute for the others. Reports and incident history are worth reading in the original rather than as a badge on a landing page.
Upgradeability cuts in both directions
Immutable contracts cannot be patched, so a defect discovered after deployment is permanent, and users can only exit. Upgradeable ones can be fixed, which means someone holds the power to change the rules that govern funds already deposited. Upgradeability risk and admin key risk are the price of the ability to respond, and a protocol emergency pause is the same trade in miniature: the power that stops a drain in progress is also the power to freeze withdrawals. Neither configuration is safer in the abstract, and the governance article later in this track examines who actually holds these powers.
Reading exposure rather than quality
Total value locked, shown on this site as TVL, measures how much is deposited, which is a measure of what is at stake rather than of how well the code is written. A large figure indicates a large target and a long-lived one indicates time in production without a total failure, which is weak evidence and not nothing. Ratios such as market cap to TVL describe how the market prices a protocol relative to deposits and carry no information about code quality. The honest summary is that code risk is not currently reducible to a number, so it is assessed through the upgrade path, the incident record, the review history and the economic assumptions the design depends on.
The two articles that follow take the largest categories of external assumption in turn, oracles and bridges. The incidents record catalogs how these failures have actually unfolded, and TVL data shows where deposits currently sit.