What a Smart Contract Audit Is — and What It Is Not
A smart contract audit is an independent security review of your contract code, performed by engineers who did not write the code, looking for vulnerabilities that would allow an attacker to steal funds, manipulate state, or disrupt functionality. It is not: A code quality review (style, efficiency, readability), A test of whether the contract behaves as intended (that is what your test suite is for), A guarantee that no vulnerabilities exist (no audit can provide that guarantee), A one-time certification (each contract modification requires a new audit of the changed code).
Phase 1: Pre-Audit Preparation (Developer Responsibility)
- Internal code review. Senior engineer who did not write the contract reviews it against the specification, checks for common Solidity vulnerability patterns, and verifies that the contract's behavior matches the intended specification in all edge cases.
- Automated static analysis. Slither identifies common vulnerability patterns (reentrancy, integer overflow, unchecked return values, access control issues) across all contract functions. Mythril performs symbolic execution to identify specific execution paths that could produce exploitable states. Echidna runs property-based fuzz testing to find edge cases that violate invariants.
- Test coverage verification. Minimum 95% line coverage and 90% branch coverage. Every function tested for both happy path and failure modes.
- Freeze the code. The code submitted for audit must match the code that will be deployed. Any changes after audit submission invalidate the audit findings and require a re-audit.
Phase 2: Audit Firm Selection
- Relevant experience. An auditor who has reviewed 50 DeFi lending protocols understands the economic attack vectors specific to lending markets.
- Methodology transparency. A credible audit firm publishes their methodology — what vulnerability categories they check, how they structure their review, and what their finding severity definitions mean.
- Turnaround time. Rushed audits produce incomplete findings. A standard audit for a 2,000 LoC protocol takes 3–4 weeks from submission to final report.
- Reputation in the ecosystem. Trail of Bits, OpenZeppelin, Certik, Halborn, Spearbit, and Code4rena are recognized names in the ecosystem.
Phase 3: The Audit Engagement
Kickoff: The audit team reviews the specification, previous audit reports (if any), known issues documented by the developer, and the codebase structure before beginning their review. Manual review: Each contract reviewed line-by-line by at least two auditors. Findings documented with: vulnerability description, attack scenario, affected code location, and severity classification.
Severity classification:
- Critical: Direct theft of funds, permanent contract lock, or arbitrary state manipulation. Must be fixed before deployment.
- High: Significant financial loss under specific conditions, partial contract lock. Must be fixed before deployment.
- Medium: Protocol behavior deviates from specification in ways that could be exploited. Should be fixed before deployment.
- Low: Minor issues that do not create direct financial risk. Should be documented and addressed in the next development cycle.
- Informational: Code quality, gas efficiency, or specification clarification items. No remediation requirement.
Phase 4: Economic Attack Modeling (DeFi-Specific)
- Flash loan attack simulation: Can an attacker borrow large capital within a single block, manipulate the protocol's price or liquidity state, and repay before block end — extracting value from honest protocol participants?
- Oracle manipulation modeling: If the protocol uses spot price oracles, can an attacker manipulate the oracle price to trigger incorrect liquidations, allow undercollateralized borrowing, or drain liquidity at artificially favorable prices?
- Governance attack scenario: Can an attacker acquire temporary governance token majority and pass a malicious proposal in a single block — before the timelock activates?
- Liquidity cascade stress test: Under a 50% collateral price drop scenario, does the liquidation engine process liquidations fast enough to prevent bad debt accumulation?
Phase 5: Remediation and Re-Audit
- Remediation: The development team fixes all Critical and High findings. Medium findings are addressed or documented with explicit justification for deferral.
- Re-audit: The audit firm re-reviews all remediated findings to confirm the fix does not introduce new vulnerabilities.
- Final report: The audit firm publishes the final report including: all original findings, remediation status for each, and re-audit confirmation.
Audit Cost Reference
| Scope | Lines of Code | Typical Cost | Timeline |
|---|---|---|---|
| Single simple contract | 100–300 LoC | $5,000–$12,000 | 1–2 weeks |
| Single complex contract | 300–800 LoC | $10,000–$25,000 | 2–3 weeks |
| Small protocol (2–4 contracts) | 800–2,000 LoC | $20,000–$45,000 | 3–4 weeks |
| Mid-size DeFi protocol | 2,000–5,000 LoC | $40,000–$80,000 | 4–6 weeks |
| Large protocol with economic modeling | 5,000+ LoC | $80,000–$150,000+ | 6–10 weeks |
