Auditor Basics

Auditing is a craft. The tools and techniques can be learned in weeks; the judgment — knowing where to look, what to question, when to stop pulling on a thread, and when to keep pulling — takes years. This section covers the foundations that underpin that judgment: the mindset, the standard toolbox, the methodologies that have proven reliable in practice, the design principles every auditor should be able to recognize on sight, and the role of inline documentation in making code reviewable.

The Auditor's Mindset

A productive auditor reads code adversarially. Every function is examined with the question "how can a sufficiently motivated, sufficiently funded attacker make this misbehave?" — not "does this look like it works?" That single shift in framing accounts for most of the difference between code review and security review.

Some habits of adversarial reading:

  • Assume every external call returns to a hostile contract. What state has already changed? What state has not yet changed? What invariants are momentarily violated?
  • Assume every input is chosen by the attacker. What happens at zero, at type(uint256).max, at boundary values, at adversarially-crafted bytes?
  • Assume every privileged actor is compromised. Owners get phished, multisigs get coerced, governance gets captured. What is the blast radius if the most-trusted address goes rogue?
  • Assume every dependency is a liability. Libraries get upgraded, oracles get manipulated, bridges get drained. What assumptions about external systems does this contract make, and what happens when they fail?
  • Assume every "obviously safe" pattern has been wrong before. ERC-20 transfers, signed-integer math, block.timestamp, tx.origin, delegatecall — all of them have produced eight- and nine-figure losses when used by people who were sure they understood them.

A good auditor maintains this stance without becoming paralyzed by it. The goal is calibrated paranoia: enough to find real issues, not so much that every line takes an hour.

What This Section Covers

The subsections that follow cover:

  • The auditor's toolbox — the IDEs, static analyzers, fuzzers, decompilers, on-chain explorers, and AI assistants that make modern auditing tractable, with notes on the strengths and pitfalls of each.
  • Methodology — a repeatable process for taking a fresh codebase from "I have no idea what this does" to a defensible set of findings, including the two-pass reading technique and the value of working from invariants outward.
  • Secure smart contract design — the principles auditors look for: minimized attack surface, well-tested libraries, layered access control, established patterns (CEI, pull-over-push, fail-loudly), and explicit failure modes.
  • NatSpec and documentation — how good inline documentation accelerates reviews, what NatSpec is, how it integrates with tooling, and what to flag when it is missing or stale.

A Skills Ladder

For readers building toward an auditing role, a rough progression:

  1. Read deeply in Solidity and the EVM. Be able to predict what any short snippet of code will leave on the stack, in memory, and in storage. Read the OpenZeppelin contracts cover to cover; read the Solidity language docs end to end.
  2. Build, break, and fix. Write the buggy contract, exploit it, fix it, exploit the fix. Solve Ethernaut, Damn Vulnerable DeFi, Capture the Ether, and the Paradigm CTFs.
  3. Read other auditors' reports. Subscribe to Solodit. Read every public report from Trail of Bits, OpenZeppelin, Spearbit, ChainSecurity, Zellic, Dedaub, Code4rena, Sherlock, and Cantina you can find. Notice what they look for and how they describe it.
  4. Audit alongside someone better than you. Most senior auditors will tell you that the biggest single leap in their skill came from co-reviewing with a more experienced auditor and seeing how they prioritized.
  5. Specialize. Pick a niche — AMMs, lending, account abstraction, ZK circuits, L2 sequencers — and develop deep, irreplaceable expertise.

The rest of this chapter, and the chapter on identifying vulnerabilities that follows, is structured to support that progression.