Fuzzsea
Autonomous smart contract security
A security review that takes six weeks and costs tens of thousands of dollars is not a control, it is a release gate teams learn to route around. Fuzzsea is our attempt to move the gate inside the development loop.
Product / Sector
Fuzzsea — our own product, smart contract security
Market
Protocol and application teams building on EVM chains
Engagement
Product strategy, agent architecture, platform engineering, brand and site
Status
In development · not yet launched · fuzzsea.com
The situation
Smart contract security today has two options and a gap between them. At one end sit manual audit firms: careful, adversarial, genuinely good at the class of bug that only a human who understands the protocol's economics will ever find. Industry practice puts a manual engagement at roughly six to eight weeks and a bill in the tens of thousands of dollars, and the firms worth hiring are booked out well before a team is ready to ship. At the other end sit static analysers such as Slither and Mythril: free, instant, and pattern-based, which is exactly why their output arrives with a false-positive rate that teams learn to scroll past.
The consequence is not that teams choose badly. It is that many teams ship unaudited, because the audit does not fit the calendar or the budget of the release they are actually trying to make. A patch that touches a fee calculation does not justify a second six-week engagement, so it goes out on the strength of a code review and a test suite. Industry reporting consistently puts the annual cost of smart contract exploits in the billions, and a meaningful share of that sits in code that was never seriously reviewed rather than in code that was reviewed and missed.
Fuzzsea is our answer to the middle of that gap, and it is our own product rather than a client engagement. The thesis is narrow and testable: an audit tool is only worth reading if its findings are true, and the cheapest way to make a finding true is to require it to be demonstrated. Everything in the architecture follows from that one rule. It is currently in development, and this case study is a description of what we are building and why, not a report on what it has found in the wild.
What made this hard
False positives are the reason security tools get ignored
A pattern matcher that flags every external call as a possible reentrancy is technically correct and practically useless. Once a team has dismissed thirty findings in a row, the thirty-first gets dismissed too, and that is the one that mattered. Any tool entering this space inherits that scepticism on day one, so the burden is not to produce more findings than the analysers but to produce a list a senior engineer will actually read to the end.
A clean testnet is the wrong environment for economic bugs
Most serious exploits are not violations of Solidity semantics, they are violations of an assumption about the world: an oracle price that can be pushed, a pool whose depth makes a swap slippage-free, a token whose supply is concentrated in one address. None of that exists on a freshly deployed test chain. A contract can be flawless against a blank slate and drainable against the chain it will actually be deployed to.
Proving an exploit is much harder than suspecting one
Suspicion is cheap and a language model will produce it endlessly. Turning a suspicion into a transaction sequence that runs, moves value in the wrong direction and can be replayed by a sceptical engineer is a different order of work. It requires an execution environment, funded actors, the right block, and the discipline to discard the suspicions that never became a demonstration.
Auditing as an event versus auditing as a habit
The report-as-PDF model treats security as a milestone that expires. The code that gets audited is not the code that gets deployed three commits later. For the tool to change anything, it has to live where the changes happen: in the pull request, in the pipeline, in a gate that can hold a merge, which means it has to be fast and quiet enough that nobody switches it off.
Claiming a low false-positive rate is easy and worthless
Every tool in this category claims accuracy. The claim is unfalsifiable unless the tool commits to something a reader can check. We had to design the product so that its central claim carries its own evidence, because a number we assert about ourselves is marketing and a runnable exploit attached to a finding is not.
How we approached it
We started from a rule rather than an architecture: if we report it, we can prove it. A finding that cannot be demonstrated as a concrete execution against real state does not get reported as a vulnerability. That rule is deliberately expensive, and it decides almost everything downstream — why analysis runs against forked live chain state instead of a testnet, why the engine is a set of specialised agents that check each other rather than one model making one pass, and why a proof-of-concept is a required attachment rather than a premium feature.
The second decision was about where the output lands. A security report that arrives as a document is read once. We built the delivery surfaces first-class alongside the engine — a dashboard that tracks vulnerabilities and audit history over time, a CLI and REST API for teams that would rather script it, and CI integrations where a critical finding can hold a merge. The engine is the interesting part; the placement is what decides whether it gets used.
The rule and the scope
We fixed the admission test before writing the engine: a finding ships with a runnable proof-of-concept or it does not ship as a finding. That immediately bounded the product. Vulnerability classes that can be demonstrated by execution became the core; classes that can only be argued, such as governance-key custody or off-chain operational risk, were scoped as advisory observations with a different label, rather than quietly mixed into the same list.
The forked execution substrate
Before any analysis, we built the environment the analysis runs in: a fork of live chain state across Ethereum, Arbitrum, Base, Polygon and further EVM chains, pinned to a specific block, with real balances, oracle readings and liquidity pool depths in place. This is the layer that makes an economic exploit expressible at all, and it is also the layer that costs the most to operate, so it was built early enough that its cost shaped later decisions instead of surprising us.
The agent set and cross-validation
We split analysis into specialised agents rather than one general pass: reentrancy, access control, flash-loan simulation, economic invariants and cross-contract flows, each looking at the contract with a narrower brief. They analyse independently and then cross-validate, so a candidate finding has to survive review by agents that were not looking for it. Suppressing false positives happens here, before anything reaches a report.
Proof-of-concept generation and replay
A surviving candidate goes to the step that either promotes or kills it: constructing a transaction sequence that runs on the forked chain and demonstrates the loss. If it executes, the exploit script and the block it was pinned to are attached to the finding so the engineer reading it can replay the same run. If it does not execute, the candidate is demoted rather than reported, which is the point at which the rule costs us findings.
Delivery surfaces and the development loop
The last phase put the output where work happens: a security dashboard with vulnerability tracking, risk scoring and audit history; threat reports with fix suggestions and compliance-ready documentation; a CLI and REST API; and pipeline integrations for GitHub Actions, GitLab CI and Bitbucket Pipelines, where a gate can block a merge on critical findings. Submission works three ways — a deployed contract address, an uploaded source tree, or a CI push.
What we shipped
Analysis engine
- Specialised agents for reentrancy and access-control analysis
- Flash-loan attack simulation against real pool liquidity
- Economic invariant checking on forked live state
- Cross-contract flow analysis across protocol dependencies
- Independent agent runs with cross-validation to suppress false positives
- Solidity, Vyper and Rust contracts accepted
Proof and evidence
- A runnable proof-of-concept exploit attached to every reported finding
- Exploits executed against forked mainnet state, not a clean testnet
- Block-pinned runs so a finding can be replayed as it was produced
- Unprovable observations labelled separately from demonstrated vulnerabilities
- Fix suggestions presented alongside the evidence, not in place of it
Chains and inputs
- Ethereum, Arbitrum, Base, Polygon and further EVM chains
- Submit a deployed contract address for an on-chain target
- Upload source for a contract that is not deployed yet
- Push through CI to audit the code in the pull request
Delivery and workflow
- Security dashboard with vulnerability tracking, risk scoring and audit history
- Threat reports with fix suggestions and compliance-ready documentation
- CLI for local and scripted runs
- REST API for teams building their own surface on top
- GitHub Actions, GitLab CI and Bitbucket Pipelines integrations
- Security gates that can block a merge on critical findings
Engineering decisions
The choices that shaped the build, and what each one traded away.
We fork live chain state instead of deploying to a clean test network
An economic exploit is only expressible if the economics are present: the oracle has a price that can be moved, the pool has a depth that makes the move affordable, the attacker can borrow enough to try. A blank testnet has none of that, so a whole class of real bugs is invisible there. Forking mainnet state solves it and charges for it twice. The first cost is RPC bandwidth — a deep fork pulls a great deal of state, and archive access is not cheap at the volume a continuous auditing product implies. The second cost is determinism: the same contract analysed at two different block heights is analysed against two different worlds, so a finding can appear on Tuesday and fail to reproduce on Thursday because a pool was rebalanced. We handle that by pinning every run to a specific block and recording it with the finding, which makes results reproducible but also means a report is a statement about a moment rather than a permanent verdict.
A finding is only a finding if an executable proof-of-concept runs
This is the rule the product is built around, and its honest cost is missed issues. Some genuinely dangerous problems cannot be demonstrated by execution on a fork: an upgradeability path that depends on who holds a multisig key, a privileged function that is safe today and catastrophic under a governance change, a design assumption that only breaks in a market condition we cannot conjure. Under a strict admission test those get downgraded from vulnerabilities to advisory observations, which is a real loss of signal for the reader who would have acted on them. We accepted the trade because the alternative failure is worse. A list that mixes proven exploits with plausible arguments is read at the trust level of its weakest entry, and the whole category has already trained engineers to assume the weakest entry is noise.
Multiple specialised agents that cross-validate, rather than one strong pass
Separate agents with narrow briefs surface more candidates than a single general analysis, and requiring a candidate to survive review by agents that were not hunting for it is our main defence against confident nonsense. The cost is direct and measurable: latency and tokens both multiply roughly with the number of agents, so a cross-validated run is substantially more expensive than a single pass, which pushes against the ambition of running on every commit. The subtler risk is correlated failure. Agents built on related models can agree with each other for the same wrong reason, and agreement then reads as confirmation when it is only correlation. That is precisely why the executable proof-of-concept sits downstream as the final arbiter: agent consensus promotes a candidate, it does not publish one.
Generated exploit code executes in isolation, and ships with its replay context
The engine writes attack code and then runs it, which is a capability that has to be contained rather than trusted. Execution happens against the forked state in an isolated environment with no route to a live network and no ability to sign against real keys, and the artefact that leaves the sandbox is the script plus the block height plus the state assumptions it depended on. The trade-off is friction: isolation costs setup time per run, and a replay bundle is only useful if the engineer can rebuild the same fork, which makes us dependent on chain data providers being available and consistent. We would rather carry that dependency than hand someone a proof they have to take on faith.
Only critical findings gate a merge, and fix suggestions stay advisory
A pipeline gate has exactly one failure mode that matters, which is being switched off. Teams disable a check that blocks releases on findings they consider arguable, and once it is disabled it stops catching the unarguable ones too. So the gate is deliberately narrow: critical severity blocks, everything else reports and lets the merge through. That makes severity classification the most load-bearing judgement in the product, more consequential than detection itself, because a misgraded critical costs a team a release and a misgraded medium costs them an exploit. For the same reason fix suggestions are labelled as suggestions and sit next to the proof rather than replacing it. An automatically generated patch that looks authoritative and is subtly wrong would reintroduce, at the remediation step, exactly the false confidence we spent the whole engine removing at the detection step.
The outcome
Fuzzsea is in development and has not launched, so what follows is a description of what stands, not of what it has achieved in the market. The shape of the product is settled: contracts enter as a deployed address, an uploaded source tree or a CI push; specialised agents analyse independently against forked live state and cross-validate before anything is promoted; and a candidate becomes a reported finding only once a proof-of-concept exploit has executed on the fork. Solidity, Vyper and Rust are in scope, and analysis runs against Ethereum, Arbitrum, Base, Polygon and further EVM chains.
The delivery layer is built around the same intent. A security dashboard holds vulnerability tracking, risk scoring and audit history so a contract has a security record over time rather than a one-off document; threat reports carry fix suggestions and compliance-ready documentation for teams who need to show their work; and the CLI, REST API and pipeline integrations for GitHub Actions, GitLab CI and Bitbucket Pipelines put the check inside the loop where code actually changes, with a gate that can hold a merge on a critical finding.
What this changes, if the thesis holds, is the unit of auditing. A six-week engagement can only be justified once or twice in a protocol's life, which leaves every release between those engagements uncovered. A run that fits in a pipeline can be justified on every change. We are not proposing that this replaces a senior human reviewing a protocol's design; we are proposing that the alternative to a manual audit is currently nothing, and nothing is a low bar to clear.
Solidity · Vyper · Rust
Languages supported
Contracts are accepted as a deployed address, an uploaded source tree, or a push through CI.
Runnable PoC
Ships with every finding
A reported vulnerability carries an exploit that executed on the forked chain, plus the block it ran against.
5
Specialised agent classes
Reentrancy, access control, flash-loan simulation, economic invariants and cross-contract flows, cross-validating each other.
3
CI systems integrated
GitHub Actions, GitLab CI and Bitbucket Pipelines, with gates that can block a merge on critical findings.
Honestly
The honest position on Fuzzsea is that its central claim is not yet proven. We have designed the product so that low false positives are a consequence of an architectural rule rather than a marketing number, and we believe that is the right way to build it, but belief is not evidence. The benchmark story still has to exist: a public methodology, a corpus of contracts with known and disclosed post-mortems, and a report of what the engine caught, what it missed and what it flagged that turned out to be nothing. Publishing the misses is the part that makes the rest credible, and we would rather commit to that now than be asked for it later.
There is also a bias we are watching in our own rule. Requiring an executable proof-of-concept selects for bugs that are provable by execution, and provable is not the same as important. The exploits that have done the most damage in this industry have often been failures of design reasoning rather than failures of code, and those are the ones a fork cannot always be made to demonstrate. If we are not careful, an engine optimised for demonstrability drifts towards a well-covered middle and leaves the hardest class of risk to the humans it was never going to replace. Saying that plainly is more useful than pretending the tool has no shape.
Everything else remains open. There is no adoption to report, no contracts scanned, no vulnerabilities found in production to point at, and the operating cost of continuous forked analysis is the constraint most likely to shape what the product can eventually charge and how often it can reasonably run. We would rather describe a product that is being built than dress a work in progress as a track record.
Frequently asked
Can an AI tool replace a manual smart contract audit?
Not for the design-level review a good audit firm performs, and we do not claim it does. What it can replace is the audit that never happens: the patch, the parameter change, the release between two engagements that currently ships on a code review alone. Fuzzsea is built to make auditing continuous rather than to make a manual audit unnecessary, and it is designed to be used before and between engagements, not instead of them.
Why analyse against forked live chain state instead of a testnet?
Because most serious exploits depend on conditions that only exist on the real chain: an oracle price that can be pushed, a pool deep enough to make a swap cheap, a token supply concentrated somewhere useful. A clean test network has none of that, so an economic vulnerability is not even expressible there. Forking Ethereum, Arbitrum, Base, Polygon and other EVM chains means analysis runs against real balances, prices and liquidity. The cost is that a run is pinned to a specific block, so a finding is a statement about a moment, which is why the block is recorded with it.
What does a proof-of-concept exploit actually add to a security finding?
It converts a claim into something the reader can check. A pattern-matching analyser tells you a line looks risky; a proof-of-concept gives you a transaction sequence that ran on a fork of the real chain and moved value in the wrong direction, plus the block it ran against so you can replay it. That is also what makes a low false-positive claim testable rather than promotional: if we report it, we can prove it, and anything we could not prove is labelled as an observation rather than a vulnerability.
Is Fuzzsea available to use today?
Fuzzsea is in development and has not launched. The product shape is settled — agentic analysis on forked state, a proof-of-concept requirement, a dashboard, a CLI and API, and CI integrations for GitHub Actions, GitLab CI and Bitbucket Pipelines — but there is no adoption or detection record to publish yet, and the benchmark work that would support any accuracy claim is still ahead of us. It is our own product, built by AirexaFlow, and fuzzsea.com is where it will launch.