Fuzzing — testing smart contracts by feeding them random inputs and watching for invariant violations — became a primary smart-contract-security technique between 2020 and 2025, and by ETHPrague 2026 has reached maturity in tools (Akidna/Echidna, Medusa, Wake 5.0, Foundry’s stateful fuzzer) while remaining structurally underfunded relative to its production importance. The frontier as of mid-2026 is AI-directed fuzzing: agents writing fuzzing harnesses, directing campaigns into low-coverage areas, and writing formal-verification proofs for the parts fuzzing cannot economically cover.

Key Ideas

Vocabulary

  • Stateless vs. stateful fuzzing — Stateless: one state, vary inputs (libraries, math, swap math). Stateful: track state across transactions (deposit → modify → withdraw chains). Most production smart contracts require stateful fuzzing; Foundry’s original fuzzer was stateless-only, which was a critical limitation through 2023.
  • Coverage-guided fuzzing — After each execution, distinguish whether the input explored new behavior. Without coverage feedback, you’re doing pure random fuzzing — useful for small libraries, hopeless for complex contracts.
  • Invariant-based development — Define properties that should always hold, then fuzz with assertions on those properties. This is the dominant modern style. Invariants survive code refactors better than test cases.

History per Grieco (Past/Present/Future of EVM Smart Contract Fuzzers)

  • Pre-2018 — No proper fuzzing tools. Static analysis (Securify, SmartCheck, Slither) and symbolic execution (Oyente, Mythril, Manticore, Maian) dominated, since contracts were small enough for symbolic tools to cover.
  • 2019–2020 — First industry fuzzers: Echidna (open source, Trail of Bits), Harvey (closed source, ConsenSys Diligence). Brownie’s integrated fuzz framework.
  • 2021–2022 — First Foundry release: stateless fuzzer with no coverage guidance, but mass adoption due to integrated Solidity testing.
  • 2023 — Academic papers for Echidna and Harvey. Confucious (symbolic + fuzzing hybrid); Smartian (linear-constraint solving). EFCF transpile-to-C approach for raw speed.
  • 2024 — Foundry adds stateful fuzzing (still random). Wake, Echidna, Etheno, Medusa, Etifaz expand.
  • 2025 — “the golden year” — Major production campaigns; Wake introduces manually-guided fuzzing with flow annotations.
  • 2026 — Medusa 1.0. Akidna adds HEVM-based symbolic verification on top of fuzzing. Foundry adds coverage-guided fuzzer with proper corpus management (contributed by Troy Sergeant). Wake 5.0 (Prevratil) ships with Rust core for 10–80× speedup over Python-only.

Wake 5.0: the Python-API + Rust-core pattern

Michal Prevratil’s ETHPrague workshop demonstrated Wake 5.0’s design:

  • Why Python for tests? Solidity was never meant as a testing language. Python gives unlimited-precision integers, floating-point, decimal, queues, dictionaries, default-dict — all the data structures needed for differential-testing mental models without copying solidity bugs into the test harness.
  • Differential testing as the core methodology — Maintain a Python-state mirror of the contract; after each flow, compare Python state to on-chain state. Disagreements are the bugs. This catches both contract bugs and test-code bugs (which were a meaningful failure mode in classic Foundry stateless fuzzing).
  • State machine — FuzzTest class; @flow decorators for actions; @invariant for assertions checked after every flow; pre_sequence for setup; reset between sequences.
  • Rust core via REVM — Replaces Anvil/Ganache; eliminates the inter-process bottleneck. Cheat codes (mint_erc20, account spoofing) work as expected.

The didactic example in the workshop (vault contract with hidden fee-accounting bug) made the point: bugs are found by symmetric construction of Python mirror and Solidity contract, not by trying to verify the Solidity code directly.

Turning Fuzzing into an Algorithm (Entreprenerd)

Entreprenerd’s ETHPrague talk addressed the next layer: making fuzzing systematic rather than ad-hoc. The framing: invariants are a specification, fuzzing is a discovery procedure; the ad-hoc gap between them costs every audit weeks. Algorithmic fuzzing means scaffold-generation of invariants from contract structure, plus deterministic search strategies over the action space rather than purely random walks.

The ecosystem-fragmentation tradeoff

Grieco’s most honest framing: the fuzzing ecosystem is fragmented (Echidna, Medusa, Wake, Foundry, Halmos, etc.) and that is partly a feature. Each tool has bias — Echidna’s input-generation distribution differs from Foundry’s; Medusa explores different paths. Running multiple tools on the same contract genuinely improves coverage because the bias inversion is real. The cost: nobody can fund all of them, and most academic fuzzing tools die within months of paper publication.

Funding crisis

Almost none of these tools have direct revenue. Revenue comes from audits-or-fuzzing-campaigns-as-a-service, which doesn’t sustain tool maintenance. The ETH Security Quadratic Funding round (cited by both Grieco and Prevratil) is currently keeping Wake, Akidna/Echidna, and related tools alive. This is a structural fragility: a single round of QF funding withdrawal would silently kill several pieces of production audit infrastructure.

Academia–industry break

Grieco’s bitter aside: the link between academic fuzzing research and industry tools is mostly broken. PhD students aren’t paid to maintain tools or talk to real users; papers ship with toy benchmarks (the canonical example: detectors for block.timestamp usage, useful only for lottery contracts but mandatory in papers since otherwise reviewers reject for “missing detector”). Real innovation now happens in industry tools, with academics arriving years late.

Details / Subtopics

Manually-guided fuzzing in Wake

Wake 4.x introduced manually-annotated flows: an auditor labels which preconditions characterise unexpected contract usage; the fuzzer then biases toward those branches. Not yet widely adopted but a promising primitive — it lets a senior auditor encode their suspicions as fuzzer guidance rather than as one-off test cases.

Symbolic + fuzzing hybridization

Akidna’s HEVM integration is the current production-ready instance: fuzz first, then prove specific properties symbolically on the focused functions. This should be the default architecture going forward — symbolic execution scales badly on whole-contract analysis but works well on narrow properties, where the fuzzer has already done the path-discovery.

AI-direction of fuzzing campaigns

Grieco’s upcoming work: MCP-protocol support in Akidna for AI agents to inspect coverage data and re-direct campaigns into low-coverage areas. The harness-writing problem (it’s currently the limiting friction) is on AI’s near-term roadmap — Wake’s Prevratil explicitly noted that AI-fuzzing-test-generation is the next funding milestone. The combination is potentially transformative: AI writes the harness, fuzzer explores the state space, AI explains the bug. Continuous AI fuzzing complements the continuous AI auditing in AI Smart Contract Auditing.

Past, Present, Future of EVM Smart Contract Fuzzers — full citation

Grieco’s roadmap for Akidna: (a) MCP support for AI agents directing campaigns; (b) better symbolic execution; (c) more aggressive corpus scheduling; (d) maintaining Akidna as the reference implementation in a high-level language (Haskell) for other tooling teams to learn from. Recon has already used Akidna as a reference to write their own Rust fuzzer.

Formal verification as the long-term endgame

Jacob’s Solidity talk and Prevratil’s workshop both pointed at formal verification as the “post-fuzzing” layer. With Sale (Solidity Algebraic Intermediate Language) targeted for formal verification in Lean, the path to proven-correct SC code starts becoming credible — though still 3–5 years out for production. The fuzzer’s role then shrinks to property-discovery: fuzz to find candidate invariants, then formally prove them.

Connections

Open Questions

  • The QF-funding dependency for production fuzzing infrastructure is fragile. If the next QF round shrinks, which tools die? Wake without funding might persist (commercial Argo / Akki support), but Echidna’s continuation is genuinely uncertain.
  • AI-written fuzzing harnesses are coming. Are they as good as senior-auditor-written harnesses? Prevratil’s workshop hinted: roughly. The judgment-quality gap is real but narrowing.
  • Foundry’s market position (default Solidity dev tool) means its fuzzer captures most usage by default — even when it’s weaker than purpose-built alternatives. Does this push the ecosystem to Foundry-as-monoculture, undermining Grieco’s tool-bias-is-a-feature argument?