The Auditor Mindset

What a contract audit examines

A contract audit examines whether code behaves as intended when users, administrators, and external contracts interact with it. Reviewers check access controls, asset accounting, state changes, and dependencies.

The review should identify which code version and deployment configuration are in scope.

A deployed contract may control assets that its operator cannot recover after a faulty transfer. Upgrade and pause mechanisms can provide recovery options, but they introduce permissions that also need review.

Auditing combines code review, testing, and checks of the assumptions the protocol makes about other systems.

Web2 vs Web3 Security

Web applications and smart contracts both need access control and correct application logic. Public contracts also expose callable functions and state that an adversary can inspect directly.

Review the surrounding infrastructure too: compromised administrator keys, deployment scripts, websites, or oracle services can affect a contract even when its own functions behave as written.

The Auditor's Mindset

An auditor does not read code looking for typos. They read code adversarially. They ask: "If I were trying to steal money from this contract, how would I do it?"

1. Identify the Assets

The first step is always mapping out the value. Where is the ETH? Where are the ERC-20 tokens? Who has permission to move them?

2. Identify the Actors

Who interacts with the contract? Regular users, admins, external protocols? Test untrusted inputs and unexpected behavior from external actors, including privileged accounts that could be compromised.

3. Establish Invariants

Invariants are rules that must always be true, no matter what happens.

• Example 1: In an ERC-20 token, the sum of all individual user balances must exactly equal the totalSupply.
• Example 2: In a lending pool, Total Deposits >= Total Borrows.

Auditors look for any sequence of complex interactions that could temporarily or permanently break these invariants.

4. Analyze External Calls

Whenever a smart contract calls another smart contract, danger exists. The auditor assumes the external contract will attempt a reentrancy attack (calling back into the original contract before it finishes updating its state) or return unexpected data to crash the transaction.

The Role of the Auditor

Auditing firms (like Trail of Bits, OpenZeppelin, Consensys Diligence) are hired by protocol developers before a project launches.

The auditors spend weeks trying to break the code. They deliver a report detailing every vulnerability they found, categorized by severity (Critical, High, Medium, Low). The developers fix the bugs, and the auditors verify the fixes before the code goes live.

An audit report records findings within a stated scope and review period. Check unresolved findings, follow-up work, and whether the deployed version matches the reviewed code. A completed audit does not prove that no vulnerabilities remain.

Key takeaways

• Publicly callable functions must handle adversarial inputs and unexpected call sequences.
• Audit testing should use an authorized test environment and a defined scope.
• Invariants describe conditions that the implementation is expected to preserve.
• An audit minimizes risk but does not guarantee 100% safety.