How do real smart contract audits work in practice? What do auditors actually check first?

From the protocol side, the audit is most useful when auditors question assumptions we forgot. In our AMM upgrade last year, the deepest bug was a sequencing flaw no scanner flagged. The auditor caught it by simulating an unusual order of interactions. My takeaway: focus less on “patterns” and more on state transitions under weird conditions. That’s the difference between textbook audits and real security engineering.

What you see across AOB’s security conversations is a consistent pattern: real audits break not because someone forgot to run a tool, but because the original assumptions of the protocol were never fully examined. Tools matter, but they only strengthen the reviewer’s reasoning — they don’t replace it. This thread captures why senior auditors begin with intent, invariants, and unusual state transitions long before they touch scanners or fuzzers.

If you want to deepen this audit mindset, pair this discussion with a few core AOB threads:

Smart Contract Fundamentals Hub https://artofblockchain.club/discussion/smart-contract-fundamentals-hub

Hardhat or Foundry First? What Actually Helps https://artofblockchain.club/discussion/hardhat-or-foundry-first-what-actually-helps-in-your-first-smart-contract

Silent Fails in Smart Contract Access Control https://artofblockchain.club/discussion/silent-fails-in-smart-contract-access-control-what-teams-miss-until-its-too

These three discussions reinforce what this thread highlights: strong auditors don’t check for patterns — they check for broken assumptions, missing boundaries, and invariant drift. That’s the mindset that reliably produces high-quality findings and confident interview performance.

When you start doing audits professionally, you realise pretty quickly that the job isn’t “look for reentrancy” or “run Slither.” The real starting point is: what must never break in this system?

That single question forces you to map the protocol’s intent, its assumptions, and the invariants holding it together. In the audits I’ve done, the biggest issues rarely came from fancy exploits — they came from assumptions nobody wrote down. For example, “only X can call this” or “this state can never go backwards.” Once those assumptions fail, everything else collapses.

After that, most auditors move to state transition reasoning. We play out weird sequences of user actions, stress-test edge cases, and see how the protocol behaves when someone interacts in an unexpected order. Tools don’t catch this — your mental model does.

Only at the end do scanners and fuzzers help validate what you already suspect.

Good audits aren’t about spotting bugs. They’re about stress-testing the truths the system relies on.

Here’s how many auditors I know (including myself) actually approach an audit. It’s not a checklist — it’s a loop of understanding, challenging, and verifying.

1. Architecture pass You skim the entire codebase and figure out where the risk sits — privileged roles, upgradeability paths, value movements. This alone tells you which files deserve the most attention.

2. Manual review with priorities We don’t read code in order. We jump straight to:

external functions

anything that mutates state

math that affects balances

loops and multi-call flows This is where 70–80% of real issues show up.

3. Build invariants This is the “audit mindset.” If the protocol says X must always be true, we write it down and test it mentally before testing it with tools.

4. Tools as validation Slither, Foundry fuzzing, Echidna… they’re extremely helpful, but they confirm suspicions more than they discover genius-level bugs.

5. Severity pass Impact over theory. Always.