Summary: Medusa is worth cataloging not as just another smart-contract fuzzer, but as a modern coverage-guided, stateful fuzzing system that makes the control plane of invariant testing unusually legible. Its first-party materials center random and mutated call sequences over an in-memory EVM state, with explicit worker parallelism, per-sequence state resets, coverage-indexed corpora, and configurable deployment/runtime surfaces. That makes it a useful comparison point for Echidna, Foundry invariants, and symbolic tools because Medusa’s own docs are unusually explicit about what the engine is actually optimizing for: discovering invariant violations by exploring transaction sequences and reusing coverage-increasing histories.
What it does:
Fuzzes Solidity smart contracts on a go-ethereum-based execution engine using random and mutated transaction sequences rather than only isolated function calls
Runs campaigns across multiple workers, with configurable worker reset limits to trade off speed versus memory growth
Tracks opcode-level coverage over deployed target contracts and stores coverage-increasing call sequences in a reusable corpus
Resets the blockchain back to the initial deployment state after each configured call sequence, making stateful multi-transaction testing a first-class primitive
Supports invariant-style testing, assertion/property tests, cheatcodes, shrink limits, configurable block-number and timestamp jumps, and deterministic deployment options
Exposes both a CLI workflow and a Go API for lower-level extension of testing methodology
Key claims:
The most reusable insight is Medusa’s call-sequence + corpus + reset model. Its docs explicitly frame smart-contract fuzzing as searching for invariant violations over sequences of transactions, not just mutating calldata until something reverts.
Coverage is not just a report output in Medusa; it is part of the search strategy. The tool stores coverage-increasing call-sequence prefixes in a corpus, then mutates those sequences in later campaigns to push exploration deeper.
Medusa’s architecture makes statefulness a configuration surface. Parameters like callSequenceLength, workerResetLimit, deployment ordering, sender sets, block jumps, and corpus persistence all materially shape what kinds of bugs the fuzzer is likely to find.
Compared with simpler fuzz loops, Medusa is unusually explicit about deployment topology. The docs emphasize target-contract ordering, constructor-argument wiring, predeployed addresses, and the fact that changing deployment order or sender addresses can invalidate saved corpus entries.
Its execution model is also a useful midpoint between black-box fuzzing and heavier formal methods. Medusa keeps the search automated and campaign-oriented, but still makes room for richer smart-contract-specific invariants, sequence minimization, and project-specific execution environments.
The presence of a Go extension API matters because it suggests Medusa is not only a turnkey fuzzer but also a reusable testing substrate for teams that want to alter generation, instrumentation, or campaign logic.
Medusa clears the corpus bar because it captures a distinct mechanism family: coverage-guided stateful invariant fuzzing where sequence reuse, deployment configuration, and workerized in-memory EVM execution are the real control surfaces.
Whitepaper: No formal whitepaper reviewed for this pass; the strongest first-party technical material is collected in ../whitepapers/medusa-primary-sources-2026-05-15.md.