Smart contract security checklist: 12 checks before you launch

Smart contracts are unforgiving: once deployed, mistakes can be expensive and irreversible. An audit helps, but it is not a guarantee, and it works best when the code is already in good shape. Use this checklist before you book one.

Design and architecture

1. Write a threat model. List who could attack the system, what they gain and which assumptions you rely on (oracles, admins, bridges).
2. Keep it simple. Less code means fewer bugs. Remove features you do not need for launch.
3. Use audited libraries. Prefer OpenZeppelin or similar for tokens, access control and upgrade patterns instead of rewriting them.

Code-level checks

4. Access control. Every privileged function should have explicit roles. Use a multisig (such as Safe) for admin keys and consider a timelock for sensitive changes.
5. Reentrancy and external calls. Follow the checks-effects-interactions pattern and use reentrancy guards where value moves.
6. Oracles and prices. Never rely on a single manipulable spot price. Use reputable price feeds with sanity checks and staleness limits.
7. Upgradeability. If you use proxies, validate storage layouts, protect initialisers and document who can upgrade and how.

Testing

8. Unit and integration tests that cover failure paths, not only the happy path. Aim for high branch coverage on critical logic.
9. Fuzz and invariant tests. Tools such as Foundry let you assert properties like “total supply never exceeds the cap” across thousands of random inputs.
10. Static analysis and fork tests. Run tools like Slither and test against a fork of mainnet to catch real-world integration issues.

Launch and operations

11. Independent audit, then fix and re-review. Share a frozen commit, documentation and tests with the auditor. Re-audit significant changes.
12. Monitoring, bug bounty and incident plan. Set up alerts on key events, define a pause or emergency process and publish a way for researchers to report issues responsibly.

Don’t forget the front-end and keys

• Protect your domain and DNS with two-factor authentication and registry locks.
• Use a strict Content Security Policy and pin third-party scripts.
• Store deployer and admin keys on hardware wallets; never in a shared chat or repository.
• Show users exactly what they are signing, in plain language.

Pre-launch gate