The report
EchoFuzz gives an LLM a narrow job inside a smart-contract fuzzer: decide which function sequences are worth trying next.
That matters because many contract bugs are not reachable through one isolated call. A particular balance, timestamp or internal state may have to exist first. Random mutation can spend most of its budget exploring sequences that never reach that state.
The EchoFuzz paper introduces Vulnerable Function Call Sequences, or VFCS. The system first identifies high-risk contract logic, combines that reasoning with static-analysis information from Slither, generates candidate call sequences and sends them to the fuzzer. When coverage stops improving, runtime information goes back to the LLM and another sequence is generated.
The loop is simple to describe:
contract -> high-risk logic -> static validation -> candidate VFCS -> fuzzing -> coverage feedback -> revised VFCS
The authors report 62.77% more detected vulnerabilities than MuFuzz on average across the three evaluated datasets. In the detailed medium-contract branch-coverage comparison, EchoFuzz reaches 79.1%, which the paper reports as a 29.19% improvement over MuFuzz. On large contracts it reaches 76.70%, a reported improvement of 32.24%.
The real-world dataset is the part that deserves closer attention.
The researchers say they tested a set of large contracts scraped from Etherscan and found 37 previously unknown vulnerabilities across 19 projects. Their separate public disclosure repository lists the project addresses and vulnerability classes. The reported mix includes integer over/under-flow, gasless behavior, reentrancy, timestamp dependency, unexpected or frozen Ether, dangerous delegatecall and unchecked-call findings.
Those 37 findings should not be described as 37 confirmed production zero-days.
The same disclosure repository says most affected teams could not be contacted and that CVE applications were still in progress. The currently checked source set does not independently confirm every finding through maintainer acknowledgement, assigned CVEs or third-party reproduction.
There is also a small primary-source inconsistency worth preserving rather than smoothing over. Section 5.1.2 of the paper and the public repository describe the real-world D3 dataset as 146 projects, while Table 1 lists 145.
EchoFuzz also records its own misses. The paper describes two gasless cases found by MuFuzz but missed by EchoFuzz, attributing them to insufficient cumulative seed exploration. A manually assisted LTL variant recovered those two cases in the reported experiment. Model choice matters as well: the paper reports a 94.2% usable-VFCS ratio for Claude 3.5 Sonnet on D1, versus 42.1% for LLaMA 3.1 8B.
The system is slower too. The authors report an average of 838 seconds per contract, compared with 603 seconds for MuFuzz, with LLM activity accounting for 28% of EchoFuzz execution time in that analysis.
The result is therefore narrower than an autonomous exploit story, but still significant. AI assistance is being inserted into the search stage itself: not just explaining a known vulnerability or generating a proof of concept, but deciding which state transitions a fuzzer should investigate next.
No live theft, autonomous mainnet exploitation or economic loss is established by the EchoFuzz sources.