Introduction to Web3 Auditing

A smart contract audit is a focused, time-boxed security review of a system's on-chain code, its surrounding off-chain components, and the assumptions that hold the two together. In Web3, code that controls money is public, immutable by default, and adversarially probed the moment it is deployed — which raises the cost of a single missed bug from "patch and move on" to permanent, irreversible loss. An audit is the structured attempt to find those bugs before an attacker does.

It is important to set expectations up front. An audit is not:

  • A guarantee. No audit proves the absence of all bugs; it only documents what was examined and what was found within a finite scope and time window.
  • Insurance. Funds lost to a vulnerability that an audit missed are still lost. An audit is one control among many (testing, fuzzing, formal verification, monitoring, incident response).
  • A substitute for a good test suite. Auditors expect to receive code that already passes a thorough test suite; the audit builds on that foundation rather than replacing it.
  • A one-time event. Codebases evolve. Upgrades, new integrations, and new market conditions all change the threat surface and warrant re-review.

What an audit does deliver is an independent, expert second opinion: a written record of what was reviewed, the methodology used, the issues identified (with severity and reproduction steps), and concrete recommendations for remediation. Used well, that record drives a feedback loop — fix, re-test, re-review, deploy — that materially reduces the chance of a costly post-deployment surprise.

What This Chapter Covers

This chapter is organized as a practical reference for both auditors and the teams that hire them:

  1. Foundations (this section) — what an audit is, who it is for, what it can and cannot achieve, and the ethical standards that govern the practice.
  2. Choices and Considerations — types of audits, the phases of an engagement, the firm/individual/contest landscape, and how to choose the right model for your project.
  3. Preparation — what a project must have in place before an audit begins, and how the kickoff sets the tone for the entire engagement.
  4. Reports — the structure of a high-quality audit report, severity rubrics, and how to interpret and act on findings.
  5. Auditor Basics — mindset, tooling, methodology, secure-design principles, and the role of NatSpec documentation.
  6. Tools — the static, symbolic, fuzzing, and formal-verification tools auditors rely on, and how they complement one another.
  7. Testing and PoCs — using unit and integration tests as both inputs to and outputs of an audit, including how to write a convincing proof-of-concept exploit.
  8. Fuzzing — stateless and stateful fuzzing with Foundry, Echidna, and Medusa, and how to identify the invariants worth fuzzing.
  9. Formal Verification — what it can prove, what it cannot, and the tools that make it tractable.
  10. EVM and Low-Level Programming — data locations, Yul/inline assembly, calldata analysis, and Huff, all from an auditor's perspective.
  11. Identifying Vulnerabilities — business logic, technical review, heuristics, and the common vulnerability classes that recur across audits.

Later sections of the chapter dive into upgradeability, MEV and front-running, cryptography and signature pitfalls, DeFi-specific audit considerations, case studies of historical exploits, and continuing-education resources.

How to Read This Chapter

Readers new to auditing should read sections 1–5 in order, then sample 6–11 as needed. Experienced auditors will find the most value in the methodology, tooling refreshes, and vulnerability sections, and in the later DeFi and case-study material. Project teams preparing for an audit should focus on sections 1–4 and the prep checklist in §3.