How smart contracts get hacked (and how audits help)
A bank vault with its blueprint posted on the front door.
Specialist · 10 min · Updated 2026-11-08
💡 The public-blueprint vault
Imagine a bank vault whose full blueprint is posted publicly, holding billions, and anyone in the world can try any door at any time — forever. Every small flaw will eventually be found. That's the security environment of public smart contracts.
Classic vulnerability families
| Type | What goes wrong | Famous case |
|---|---|---|
| Reentrancy | Contract sends funds before updating its records; attacker calls back in repeatedly | The DAO (2016), ~3.6M ETH drained, led to the ETH/ETC fork |
| Oracle / price manipulation | Protocol trusts a price that can be moved with a flash loan | Numerous lending protocol exploits |
| Access control | A function anyone can call should have been restricted | Poly Network (2021) |
| Key / infrastructure compromise | Multisig signers or front-end infrastructure compromised | Ronin bridge (2022, ~$600M+); Bybit (Feb 2025, ~$1.5B) |
| Bridge logic bugs | Cross-chain message verification flaws | Wormhole (2022) |
Defensive practices
- Checks-effects-interactions pattern and reentrancy guards.
- Time-weighted or multi-source oracles.
- Least-privilege roles, timelocks on upgrades, multisig with independent signers and hardware keys.
- Multiple audits, formal verification for critical logic, bug bounties and monitoring.
What audits can't do
Audits review a specific code version within a time box. They can miss issues, don't cover later upgrades, and don't protect against compromised keys or front-ends. Treat "audited" as one input, not a guarantee.
🧮 Practical example: reentrancy in plain English
Key takeaways
- Public code + public money = constant attack.
- Reentrancy, oracles, access control and keys are classic failure points.
- Defence in depth: patterns, multisig, timelocks, bounties.
- Audits reduce, not remove, risk.
Education only — not financial advice.