Practical Takeaway
Well-prepared codebases get higher-quality audits. Auditors who spend less time understanding your architecture spend more time finding vulnerabilities. This checklist gets you audit-ready.
Full Resource
A well-prepared codebase significantly reduces audit time and cost. Documentation requirements include architecture diagrams, NatSpec comments, known issues lists, and invariants. Test suite needs 95%+ line coverage, fuzz tests, and invariant tests. Code quality requires Slither and Aderyn findings reviewed, no TODO comments, and consistent naming conventions.
DOCUMENTATION (Complete Before Audit Starts)
Architecture document (required):
System overview diagram showing all contracts and how they interact
User flow diagrams for every major operation (deposit, withdraw, liquidate, etc.)
Admin operation flows (upgrade, pause, fee change)
Oracle integration documentation (which oracles, when queried, divergence threshold)
Access control matrix (who can call what)
Inline documentation (required):
Every public and external function has NatSpec (`@notice`, `@param`, `@return`, `@dev`)
Every state variable has a comment explaining its purpose and units
Complex math has inline comments explaining the formula
Non-obvious design decisions have explanatory comments
Known issues list (required):
Any design decisions that may look like bugs but are intentional
Any known limitations or edge cases you are aware of
Any components not in scope for this audit
Invariants list (strongly recommended):
Mathematical invariants that should always hold (sum of balances = total supply)
State invariants (paused = no state changes possible)
Economic invariants (share price can only increase)
TEST SUITE REQUIREMENTS
Line coverage ≥ 95% (`forge coverage --report summary`)
Branch coverage ≥ 88%
Fuzz test for every function with numerical inputs
Invariant tests for all listed invariants
Fork tests for all external protocol integrations
Edge case tests: zero values, max values, single user, empty state
Negative tests: every require statement has at least one test that triggers it
Send to auditor before engagement:
Coverage report output
List of fuzz and invariant tests with their properties described
Any failing tests and why they fail (if any edge cases are known)
CODE QUALITY CHECKLIST
All identified Slither findings reviewed and addressed (or documented as false positive)
All Aderyn findings reviewed
No `TODO` or `FIXME` comments in audited code
No commented-out code blocks
Consistent naming conventions throughout
No magic numbers — all constants are named
Latest OpenZeppelin contracts version used
Solidity version pinned (not `^`)
Ready to Prepare for Your Audit?
Let's ensure your codebase is audit-ready.