Context
- Understand the layers of security
- Optimize code for auditor comprehension
- Pre-audit readiness checklist + internal audit with our tool
- Web3 incident response playbook
- Emergency option: SEAL 911
- Conclusion
This guide compiles the most important security materials and practical advice every Web3 protocol needs before launch.
It’s intentionally compact and designed to be applied, not just read.
Step 1. Understand the layers of security
If you are serious about the security of your project, you have to understand the layers of security.
Security isn’t a one-time fix. It’s an ongoing process: monitoring, testing, updating, adapting.
Security isn’t just about tools - it’s about your people, your processes, your mindset.
You need layers of protection. Following is the best case scenario in terms of security for a Web3 project:
- Security-first developers writing safe code
- Internal audits before any external review
- Multiple external audits before launch
- New audits after every major update
- Continuous testing and monitoring
- Bug bounty as the final safety net
Bare minimum baseline
- 1 internal audit
- 2 external audits before launch
- Audits after code changes before deploying (no matter how small these changes are)
Anything less is gambling.
Step 2. Optimize code for auditor comprehension
Code style
- Follow the Solidity Style Guide (here and here)
- Use a consistent, readable structure
- Reduce cognitive load for auditors
Clean code = faster audits = fewer missed issues.
Documentation must clearly explain
- The purpose of your protocol (token, staking, governance, etc.)
- Functional and non-functional requirements
- Design decisions, assumptions, and trust model (trusted actors, oracles, owner privileges)
- External libraries, contracts, and integration assumptions
- Edge cases and expected user behaviours
- Deployment, upgradeability, and configuration parameters
Step 3. Pre-audit readiness checklist
Project-level
- What is the exact purpose of the contract?
- Which functions are financially or system-critical?
- Have edge cases and stress scenarios been fully tested?
- What assumptions does the system rely on?
- Is upgradeability clearly defined, secured, and documented?
- What external integrations and dependencies exist?
- What is the financial and systemic impact of failure?
- Has a thorough internal security review been completed?
- Is test coverage above 95%, including critical paths?
- Is documentation complete, accurate, and up to date?
- Are deployment parameters clearly defined and validated?
- Are monitoring, alerting, and a bug bounty in place?
- Do we have a clear contingency plan for critical vulnerabilities?
For developers
- Is the codebase readable and understandable by someone who didn’t write it?
- Is code style consistent across all contracts, including edge and helper contracts?
- Are invariants clearly defined and enforced in code and tests?
- Do tests cover failure cases, adversarial behavior, and edge conditions?
- Are all external calls validated, isolated, and safely handled?
- Are dependencies pinned, reviewed, and free of known critical issues?
- Are access controls minimal, explicit, and justified?
- Are upgrade mechanisms safe, well-documented, and protected against misuse?
- Are emergency controls defined, tested, and clearly documented?
- What breaks or becomes exploitable if a trusted role or component fails?
For auditors
- What contracts and components are explicitly in scope?
- What is explicitly out of scope?
- What assets are being protected and what is the maximum acceptable loss?
- Which functions are financially or system-critical?
- What trust assumptions does the system rely on?
- What attacker models are considered in scope?
- Are there known design trade-offs or accepted risks?
- Are previous audit findings available and fully addressed?
- How should findings be classified and prioritized?
- Who has final authority to accept or reject security risks?
Internal audit
Use our pre-audit tool to prepare your Solidity project for a security audit.
It runs an 8-phase automated readiness check across your codebase and produces a scored report with actionable findings.
Supports Foundry and Hardhat projects.
More info here.
Step 4. Web3 incident response playbook
Before anything goes wrong, lock this in:
- Engage two critical partners: an incident response firm with deep expertise in blockchain forensics, digital investigations, and crisis management, as well as external legal counsel already familiar with your protocol’s governance and inner workings.
- Collaborate with these partners to create a detailed, battle-tested incident response plan covering:
- Clear communication strategies
- Defined roles and responsibilities of key stakeholders
- Precise steps to take in the event of a hack
- Pre-made decisions, such as potential asset freezing or chain halting protocols, to ensure swift and decisive action
You don’t want to debate strategy while funds are draining.
Emergency option: SEAL 911
SEAL 911 is a free, 24/7 emergency hotline for active or imminent Web3 security incidents.
If you’re exploited, message them immediately on Telegram with all relevant details:
Conclusion
Security is not about looking safe. It’s about surviving worst-case scenarios.
Teams that prepare early move faster, lose less, and keep credibility when things break.
Hope for the best but prepare for the worst.