Smart contract security is the work of keeping on-chain code from losing the funds it holds. This article covers why contracts need stricter security than other software, the OWASP Smart Contract Top 10 for 2026, real exploits for several classes of bug, what an audit catches and misses, and the controls that matter after launch.
Why smart contract security is different
Three properties make mistakes in smart contracts costly:
- Immutability. Nobody can edit deployed bytecode. Upgradeable proxies exist, but each upgrade adds its own risk and needs governance.
- Public, hostile execution. Anyone can read the code and call any public function, in any order, with any input. Attackers often write contracts built only to exploit one target.
- Composability. A contract calls tokens, oracles and protocols that other teams wrote. A flash loan can give an attacker a huge amount of capital for the length of one transaction.
Past incidents show specific failure classes:
- In 2016 The DAO lost a large share of its ETH to a reentrancy bug, which led to Ethereum's hard fork.
- In 2017 a user accidentally destroyed a Parity multisig library, which froze the funds in every wallet that depended on it.
- In 2022 Nomad's bridge was drained after an upgrade set a value that let any message pass verification.
- In 2023 Euler Finance lost about $197 million despite several audits. The flaw was in a donation function added in a later code change, and the attacker later returned most of the funds.
The OWASP Smart Contract Top 10 for 2026
OWASP, the Open Worldwide Application Security Project, publishes a Smart Contract Top 10. The 2026 edition ranks risks using incidents and practitioner surveys from 2025. The data covers 122 separate incidents with about $905 million in losses, after duplicates were removed.
| Rank | Risk | What goes wrong |
|---|---|---|
| SC01 | Access control vulnerabilities | An unauthorized caller reaches an admin, governance or upgrade function |
| SC02 | Business logic vulnerabilities | Lending, AMM, reward or governance logic lets an attacker extract value while low-level checks pass |
| SC03 | Price oracle manipulation | An attacker moves a weak price feed to borrow, liquidate or swap at a false price |
| SC04 | Flash loan–facilitated attacks | A large loan inside one transaction turns a small bug into a large drain |
| SC05 | Lack of input validation | Unchecked user, admin or cross-chain inputs corrupt state |
| SC06 | Unchecked external calls | The contract does not handle a failed call or a callback safely |
| SC07 | Arithmetic errors (rounding and precision) | Rounding in share, interest or AMM math leaks value |
| SC08 | Reentrancy attacks | An outside call re-enters the contract before state updates finish |
| SC09 | Integer overflow and underflow | Arithmetic wraps around and breaks the contract's accounting |
| SC10 | Proxy and upgradeability vulnerabilities | An attacker takes over an implementation or re-initializes critical state |
Compared with the 2025 list, business logic moved up to second place, reentrancy dropped to eighth, and proxy and upgradeability risks entered at tenth. The full list and definitions are on the OWASP Smart Contract Top 10 page.
Smart contract vulnerabilities in recent exploits
Two exploits from 2025 show how small math bugs become large losses:
- Cetus (May 2025). The Cetus exchange on Sui lost about $223 million. A helper function meant to prevent overflow used a wrong threshold, so an attacker deposited a tiny amount and received a huge liquidity position.
- Balancer v2 (November 2025). Attackers drained more than $100 million across several networks. The bug was a calculation that rounded in the wrong direction, and repeated swaps inside one transaction made the small error large.
Operational failures also cause large losses. In February 2025 attackers stole about $1.5 billion in ETH from the Bybit exchange, a theft the FBI attributed to North Korea. The attackers manipulated the signing process of a multisig wallet, and the wallet's audited contracts had no bug.
What auditors look for
| Category | Examples |
|---|---|
| Access control | Missing onlyOwner checks, unprotected initializers, admin roles with too much power |
| Reentrancy | Outside calls before state updates, including read-only and cross-function reentrancy |
| Oracles and prices | Spot AMM prices used as a price feed, stale feeds, no sequencer-uptime check on L2s |
| Math and precision | Wrong rounding direction, mismatched decimals, share-inflation attacks on ERC-4626 vaults |
| Business logic | Liquidation edge cases, fee bypasses, wrong state transitions |
| Signatures | Replay across chains or contracts, malleable signatures, missing EIP-712 domain separation |
| Upgradeability | Storage collisions, uninitialized implementations, unsafe upgrade paths |
| Token integration | Fee-on-transfer and rebasing tokens, missing return values, ERC-777 hooks |
| Denial of service | Unbounded loops, griefing, blocked withdrawals |
| Centralization | Single keys that can pause, mint or drain funds, recorded as trust assumptions |
Tools find known patterns, but business logic bugs need a reviewer who knows what the protocol is supposed to do and can see where it does something else.
How a smart contract audit works
- Scoping. The team shares the repository, the files in scope and the documentation. The auditor estimates effort from code size and complexity.
- Code freeze. The team picks one commit hash for the audit and stops changing that code. A review of changing code leaves gaps.
- Automated analysis. Static analyzers such as Slither, fuzzers such as Echidna or Foundry invariant tests, and sometimes symbolic tools flag common issues.
- Manual review. Two or more reviewers read the code line by line, model how value moves, and try to break the invariants. This step is most of the work.
- Formal verification (optional). For critical parts, tools such as the Certora Prover prove that stated properties always hold.
- Report. Findings are ranked as critical, high, medium, low or informational, each with an explanation and a fix.
- Fix review. The team fixes the issues, and the auditor checks the fixes, because fixes often add new bugs.
- Publication. The final report names the reviewed commit hash, so users can check what was reviewed.
Firms usually price an audit by reviewer-weeks. Code size, new mechanisms, outside integrations, test quality and urgency move the price most. The smart contract audit guide covers costs, providers and deliverables.
Competitive audit contests take another approach: many independent researchers review the same code at once for a prize pool. Contests often find more issues, but they also produce more invalid or duplicate reports to sort through. Sherlock and Cantina run contests. Code4rena, one of the first contest platforms, states on its site that it is winding down and finishing its active competitions. Many high-value protocols use a private audit, then a contest, then a standing bug bounty.
Why audited code still gets hacked
- Changes outside the audit. The deployed code differs from the audited code, or a later upgrade was never reviewed.
- Composition risk. A contract is safe alone but fails when combined with a new token or protocol.
- Economic attacks. The code does what it says, but an attacker abuses the incentives, for example through a takeover of governance or oracle manipulation in a market with little trading.
- Operational failures. Stolen keys, malicious front ends and social engineering, as in the Bybit theft.
- Time limits. An audit lasts a fixed number of hours, so it lowers risk but does not remove it.
Security controls after launch
- Bug bounty. A public bounty, often hosted on a platform such as Immunefi, gives researchers a legal, paid way to report bugs. Size the rewards to the funds at risk. A small reward for a critical bug in a large protocol gives a researcher a reason to sell the bug instead.
- On-chain monitoring. Watch for large withdrawals, admin function calls, oracle deviations and sudden changes in collateral ratios. Alerts must reach someone who can act at any hour.
- Pause and rate limits. A guardian role that can pause deposits or borrowing gives the team time during an incident. Rate limits on withdrawals or bridge transfers cap the loss from an unknown bug.
- Incident response plan. Decide in advance who can pause the protocol, how the team communicates, and which security firms and exchanges to call. Write down who holds which key before an incident starts.
- Timelocked governance. A delay on upgrades and parameter changes gives users and monitors time to react to a bad proposal.
- Dependency tracking. Subscribe to security advisories for the libraries, oracles and protocols you integrate. A bug in a dependency is a bug in your system.
- Key security. Protect admin keys with a multisig or MPC and timelocks, because an audit cannot protect a leaked key.
Security needs for dApps, DeFi and enterprise ledgers
Consumer dApps and NFT projects
Contracts for consumer dApps and NFT projects are often simpler and built on OpenZeppelin libraries. The main risks sit in minting logic, access control, signature-based allowlists and payment handling. A focused audit and careful reuse of standard libraries usually match the risk. The NFT smart contract guide covers common patterns.
DeFi protocols
DeFi needs the strictest security. Expect several independent audits, invariant fuzzing, formal verification of core math, economic modeling of liquidations and oracles, a bug bounty sized to the funds at risk, and monitoring with pause controls. The DeFi smart contract guide covers design for review.
Enterprise and permissioned ledgers
On Hyperledger Fabric or a private EVM network, every participant is known. The main threats are therefore insiders, weak access control, data leaks and integration bugs. Chaincode still needs review for determinism and authorization checks, and identity and key management need the same attention as the code. The Hyperledger Fabric explainer describes how Fabric handles identity and chaincode.
Frequently asked questions
What are the most common smart contract vulnerabilities?
The OWASP Smart Contract Top 10 for 2026 ranks access control flaws first, then business logic flaws, price oracle manipulation and flash loan attacks. Reentrancy is still on the list, at eighth place.
Does an audit guarantee that my contract is secure?
No. An audit is an expert review with a fixed time limit, and it lowers risk. Combine it with testing, a bug bounty, monitoring and good key management.
When should I schedule the audit?
Schedule the audit when the code is feature-complete and tested, with enough time left to fix findings before launch. Book early, because established auditors often have waiting lists of several weeks.
Do I need an audit if I only use OpenZeppelin contracts?
The OpenZeppelin libraries are well reviewed, but your configuration and any custom logic are not. A lighter review still makes sense if the contract holds value.
Do upgrades need a new audit?
Yes. Every change to deployed logic needs a review, and so does the upgrade process itself.
Where can I read more about smart contract security?
The ethereum.org smart contract security page, the OWASP Smart Contract Top 10 and the OpenZeppelin Contracts documentation are primary starting points.