Reading Solidity like an auditor

Application code fails and someone files a bug. Smart contract code fails and the money is gone, permanently, in front of an audience. That difference shapes everything about how the code should be read — and why the audit report matters as much as the finding.

The mindset shift

An auditor does not ask whether the contract works. They ask what an adversary with capital, a mempool view and the ability to compose transactions can make it do. The attacker controls transaction ordering within limits, can call functions in any sequence, can be another contract rather than a person, and can borrow enormous sums for the duration of a single transaction. Every assumption about who calls what, and in what order, is negotiable.

The classes that keep recurring

• Reentrancy — still, years after the pattern was named. Checks-effects-interactions and a guard are cheap; the discipline to apply them everywhere is what lapses.
• Access control — a missing modifier on an initialiser or an upgrade function. Boring, catastrophic, common.
• Oracle manipulation — a price read from a source an attacker can move within one block.
• Accounting and rounding — where fees, shares and decimals interact, and the loss is small per transaction and unbounded in aggregate.
• Upgradeability — proxy storage collisions and uninitialised implementations, which turn the safety mechanism into the vulnerability.

Tooling, and what each tool is for

Static analysis with Slither is the first pass: fast, broad, noisy, and useful precisely because it forces you to justify each finding. Symbolic execution with Mythril reaches states manual reading misses. Property-based fuzzing with Echidna is where the real value sits — you write the invariants that must never break, and the fuzzer spends hours trying to break them. Foundry ties it together, with fork testing against live state so you can reproduce mainnet conditions.

None of these replaces reading the code. They narrow where to read carefully.

The report is the deliverable

A finding that a client cannot act on is not a finding. Each entry needs a severity that reflects both likelihood and impact, a proof of concept that reproduces the issue, a clear explanation of the root cause rather than the symptom, and a remediation that fits the codebase. Auditors are judged on the report long after the engagement ends.

Write the invariants before you write the exploit. Most of the interesting bugs are found by stating what should always be true and then discovering it is not.