In simple terms — Smart contract risk is the possibility that an onchain program behaves unexpectedly, is exploited, or is changed or stopped by someone with special privileges.
A smart contract executes the code and state available on its network, but that does not make the written rules correct. An error may send assets to the wrong party, prevent a withdrawal, or let a user obtain more than intended. The risk also includes configuration and dependencies, not only what is commonly called a “hack.”
Where the risk begins
Vulnerabilities may involve access control, external calls, calculations, the order of state updates, or the handling of extreme conditions. Reentrancy, for example, uses a call to another contract to enter a function again before the original operation is complete. Behavior and protections also change across language and compiler versions, so guidance for an old contract should not be applied automatically to a newer one.
Even correct code may receive a bad price from a blockchain oracle, depend on an unusual token, or propagate the failure of a bridge. An administrative key may be able to pause functions, change parameters, or replace logic. These powers can support incident response, but they create a specific trust assumption.
Audits, upgrades and the limits of verification
An audit reviews a defined scope, version, and point in time. It can find defects, but it does not certify that no others exist and does not automatically cover the frontend, oracle, later configurations, or code deployed after the report.
Formal verification shows that a model satisfies explicitly specified properties. An incomplete specification or a dependency outside the model can leave a real risk unaddressed. “Immutable” also requires context: one contract's code may remain unchanged while a proxy directs users to a new implementation authorized by an administrator or governance process.
Observable checks before use
The deployment address, network, and verified code should match the published documentation. An audit report should identify the commit, covered contracts, date, exclusions, and whether reported findings were actually remediated. A bug bounty, monitoring, and an incident plan add defenses without becoming a guarantee.
Proxy contracts, ownership, multisigs, timelocks, pause functions, and operating limits also require examination. The amount deposited and the age of a protocol provide context, but they do not prove the security of its code or dependencies.
Sources
- Ethereum.org — Smart contract security — Covers access control, testing, audits, upgrades, recovery, and common vulnerabilities while explaining their limits.
- Solidity — Security Considerations — Collects risks and recommendations for the current version of the Solidity language.
Related entries
Blockchain oracles · Blockchain bridges · Flash loans · Decentralized finance (DeFi)