How a finding is earned, and what we do not cover.
The detail behind the home page: who Proovant is for, the pipeline, what a passing test proves, and the supported chains, languages and limits.
Who it is for
Use it when you are preparing for an audit and want the machine-findable issues cleared first; you changed code after an audit and want the new commit checked; you have no audit budget yet and want a first independent look; or you run a bug bounty and want reproducible issues found before outside researchers find them.
Do not rely on it alone when significant user funds depend on the code, when the main risk is in cryptography or circuits, when the risk is off-chain (web apps, keepers, relayers, key management), or when your code is not Solidity.
The pipeline
- Scope and threat model (AI). Maps the codebase, finds where value moves, separates deployed code from test-only code, and writes down attacker goals before any hunting.
- Parallel hunting (AI). Eight specialist agents read the code independently: accounting, access control and upgrades, external calls, state flow, logic edge cases, oracles and economics, cross-component interactions, and an adversarial pass. A variant hunter looks for siblings of every pattern found. Leads are checked against a knowledge base of past public findings.
- Independent skeptic review (AI). A separate agent that did not write the lead re-reads the code and tries to kill it: is the path reachable, are the preconditions realistic, is it already fixed or documented, is the impact real? It also proposes a severity and compares it with past findings of the same kind.
- Proof of concept (AI). Each survivor becomes a Foundry test against your contracts. If no test can be made to pass, the lead stays Unconfirmed and is not reported as a finding.
- Review and report (human on Verified). A researcher reruns the tests, checks each finding against your latest commits and docs, and grades severity with reasoning. The Scan plan skips this and the report says so.
Two recent reviews, as examples of how much is filtered out: a staking system went from 21 leads to 4 findings, and an options protocol from 12 leads to 3.
What a passing test proves
It proves that on the reviewed commit the described steps lead to the described result, that you can reproduce it with one command, and that the stated numbers come from a real run.
It does not prove that the live deployment is exploitable (tests run on a local chain, and we never send transactions to live contracts); that a stand-in behaves like the real thing (where a token, swap venue or ZK verifier is mocked, the report says so beside the finding); how much a finding matters (severity is a judgment, with the reasoning shown); or that nothing else is wrong.
Coverage and limits
| Area | Status | Detail |
|---|---|---|
| Language | Supported | Solidity. Reviews so far used compiler versions 0.8.x. |
| Chains | Supported | Any EVM chain. We review source code, so the review does not depend on the chain. |
| Test framework | Supported | Foundry. If your repository does not use Foundry, say so in your email and we will tell you whether we can work with it. |
| Protocols reviewed so far | Experience | Sealed-bid auctions, shielded pools, staking, token launchpads, options markets and Uniswap v4 hooks. |
| ZK circuits | Limited | We check how contracts use a verifier and can run basic checks on Circom circuits. This is not a circuit audit. |
| Fork and live-chain tests | On request | Tests run locally by default. Fork tests are written only if you ask. We never send transactions to live contracts. |
| Deployed bytecode | Not checked | We review the repository at the commit you name, not what is deployed. |
| Other languages | Not offered | Vyper, Rust (Solana, CosmWasm), Move, Cairo. |
| Off-chain systems | Not offered | Web apps, APIs, keepers, relayers, indexers, key management. |
| Formal verification | Not offered | Findings are shown by tests, not proved correct. |
Strongest at logic, accounting and economic-design flaws, access-control and state-flow mistakes, and anything that a self-contained test can show. Weaker at bugs that depend on live state or real liquidity, complex interactions across several external protocols, and behaviour of third-party tokens we cannot inspect.