Medusa is best understood as a coverage-guided, stateful invariant fuzzer for EVM systems, not just a generic random-input tool. The docs explicitly define smart-contract fuzzing as using random sequences of transactions to test invariants.
The central mechanism is the call-sequence lifecycle. Medusa deploys target contracts into an initial state, generates a sequence of transactions, tracks coverage while executing it, saves coverage-increasing prefixes into a corpus, then resets the chain back to the initial deployment state before starting again.
The corpus is part of the search engine rather than just an artifact store. Coverage-increasing call sequences are re-used and mutated in later iterations, which is why the docs describe Medusa as coverage-guided and mutational.
Statefulness is intentionally tunable. callSequenceLength, workerResetLimit, senderAddresses, block-number jumps, timestamp jumps, deployment order, and corpus persistence all shape what parts of the system the campaign can realistically explore.
Medusa’s docs are unusually explicit about deployment topology as part of fuzzing correctness. Target-contract ordering determines deployment order, constructor wiring can reference earlier deployed contracts, and changing deployment addresses or sender sets can invalidate saved corpus entries.
The tool is positioned between turnkey fuzzing and reusable testing infrastructure. The CLI covers normal campaigns, while the Go API and hooks point toward custom methodologies and deeper integration.
Specific source signals worth retaining
github.com/crytic/medusa: best compact statement of positioning — cross-platform go-ethereum-based smart-contract fuzzer, inspired by Echidna, with parallelized fuzz testing and a Go extension API.
secure-contracts.com/.../testing/overview.html: best concise explanation that smart-contract fuzzing is about validating invariants rather than merely forcing crashes or reverts.
secure-contracts.com/.../testing/fuzzing_lifecycle.html: strongest source for the actual control loop — deployment, call-sequence generation, coverage tracking, corpus reuse, invariant checks, and reset-to-initial-state semantics.
secure-contracts.com/.../project_configuration/fuzzing_config.html: most useful source for identifying the real control surfaces: worker parallelism, reset limits, sequence length, coverage persistence, deployment order, constructor argument wiring, sender sets, and chain-time jumps.
Why this entry belongs in the corpus
It adds a sharp comparison point for stateful invariant fuzzing rather than leaving that whole space flattened into Echidna-like testing.
It helps separate coverage-guided sequence exploration from symbolic execution, spec-language proof systems, and ordinary unit-test fuzzing.
The durable analytical question Medusa raises is which parts of smart-contract testing are governed by invariant design versus by campaign topology — deployment order, corpus retention, sender policy, state resets, and time-jump configuration.