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.

This thread hits on a crucial point: protocols don't get exploited because auditors forgot to run a scanner; they get exploited because baseline assumptions drifted.

If you want to deepen this mindset across different parts of your stack, a few other discussions on AOB tie directly into this:

• Smart Contract Fundamentals Hub: Great for mapping out core state transitions.

• Hardhat vs. Foundry First: Focuses heavily on setting up invariant tests in Foundry.

• Silent Fails in Access Control: Real-world examples of broken administrative assumptions.

When you force yourself to write code assertions for state boundaries, you quickly see where manual reasoning ends and tool automation begins.

I mostly agree, though I’ll play devil’s advocate on one point: running Slither first takes 10 seconds and can save you an hour of manual work by catching low-hanging fruit (like missing reentrancy guards or uninitialized state) before you dive deep.

That said, Slither won't catch business logic flaws. The hardest bugs I've audited came down to unwritten assumptions—like assuming msg.sender could never be a contract, or assuming a DEX oracle wouldn't shift 10% in a single block. Your mental model catches those, not automated tools.

Here’s how my team actually handles an audit pass—it’s an iterative loop, not a linear checklist:

Architecture & Scope Pass: Skim the codebase to map out high-risk areas—admin functions, upgrade proxies, and external calls.

Targeted Manual Review: We don't read line-by-line in order. We jump straight to state-changing external functions, balance accounting math, and multi-call loops. That's where 80% of real bugs live.

Drafting Invariants: What must never happen? (e.g., vault.totalAssets() >= sum(userBalances)). We write these down to fuzz later.

Tool Validation: Now we run Slither for quick sanity checks and run invariant fuzzers to stress-test our assumptions.

The biggest gap in beginner discussions is skipping the math/intent step. If you don't define what must stay true in the protocol, a scanner output won't help you.

For example, a tool won't flag a first-depositor inflation attack on an ERC-4626 vault unless you've manually realized that totalSupply == 0 is an unhandled edge case. You have to trace token flow and privilege models mentally first.

Tools like Echidna or Foundry fuzzing are great amplifiers, but they only test the invariants you were smart enough to write down in the first place.

A lot of junior security profiles focus way too heavily on tool names. When hiring teams review portfolios, they aren't looking for a list of scanners—they want to see if you can reason about protocol invariants, trust boundaries, and privileged paths.

If you're building a portfolio right now, we covered how to structure your proof of work in our discussion on How to show trust boundaries in Web3 interviews.

A proof-based portfolio doesn't need 10 automated tool outputs. One scoped review showing a well-thought-out threat model, a reproduction script for a broken invariant, and a clear finding write-up beats 50 pages of Slither reports every single time.

Honestly, I'll take a slightly controversial stance here: running Slither and Aderyn in the first 5 minutes of an audit isn't "beginner" it's basic operational efficiency.

If a static analyzer can flag an uninitialized proxy implementation, missing zero-address checks, or an outdated Solidity pragma in 3 seconds, why waste 45 minutes finding it manually? The key is treating static analysis as an initial filter, not the audit itself.

Where tools actually fail leading to 90% of real exploits happen is cross-function state dependency and business math.

For example, no fuzzer or scanner is going to automatically warn you about a read-only reentrancy attack on a Curve/Uniswap pool oracle unless you manually spent two hours mapping out the protocol's price-calculation invariants first.

The real workflow isn't "Manual vs. Tools." It's:Static Triage (5 mins) $\rightarrow$ Threat Modeling & Invariant Design (70% of time) $\rightarrow$ Targeted Invariant Fuzzing in Foundry to prove hypotheses.

Curious how others here handle oracle dependencies specifically like do you rely on formal verification rules (like Certora) for price feeds, or do you stick strictly to custom Foundry invariant suites