How do real smart contract audits work in practice? What do auditors check before Slither, Mythril, Foundry fuzzing, or Echidna?

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.

I think the biggest gap in beginner audit discussions is that people jump to tools before they define what must stay true in the protocol.

In a real smart contract audit, the stronger starting point is usually protocol intent, trust boundaries, privilege model, and value-moving paths. If you do not know what the system is promising to users, it is hard to judge whether a state transition, upgrade hook, access-control path, or integration assumption is dangerous. That is why experienced auditors often begin with invariants, admin powers, token flow, and failure scenarios before they even care what a scanner highlights.

Tools like Slither, Mythril, Foundry fuzzing, and Echidna are still useful, but more as amplifiers than substitutes. They can surface patterns, validate assumptions, and push edge-case testing further. They do not replace manual reasoning. For interviews too, I think a candidate sounds much stronger when they can explain what they would verify first and why, instead of just naming tools.

A lot of weaker security discussions start with tool names. The stronger signal is whether someone can explain protocol intent, invariants, privileged paths, and what evidence an audit should leave behind after review.

That is why this thread matters inside the cluster. Before anyone debates AI-assisted review, JD wording, or automation boundaries, they should understand what a real smart contract audit workflow looks like in practice and where tools fit without creating fake confidence.

Smart Contract Security Audits Hub
Smart Contract Security Audits Hub: Audit Checklist, Common Solidity Risks, and Auditor Roadmap | ArtofBlockchain

AI-assisted smart contract audit review in JDs — legit workflow or fake confidence?
AI-assisted smart contract audit review” in JDs — legit workflow or fake confidence? | ArtofBlockchain

Threat Modeling for Juniors — Do You Test Assumptions Before They Break?
As a junior, how do you explain msg.sender and trust boundaries confidently in Solidity interviews? | ArtofBlockchain