For protocol teams
Private audits of your smart contracts.
I pin your code to a commit, try to break the invariants it depends on, and report only what I’ve proven with a test against your real contracts.
Available now
What I review
Deepest
- Solidity
- Vyper
- EVM chains
Also
- Rust: Solana, NEAR
- Move: Sui
- Cairo: Starknet
Protocols
- Lending
- Vaults and yield
- Stablecoins
- AMMs and hooks
- Staking
- Bridges
- Governance
- Oracles
How an audit runs
From a pinned commit to a reviewed fix.
Five steps. Each one ends in something you can check.
-
Pin the scope
Repo, commit and file list, agreed in writing. If you’re live, I read each contract’s implementation on chain and flag any that differs from that commit.
You get: Scope sheet, deployed-code check
-
Read what is already known
Prior audits, open issues, your tests and docs. A fork is diffed against its upstream, so the hours go to the code you changed.
You get: Known issues, never re-reported
-
Model the protocol
Where value sits, who can move it, and the invariants that must hold. Every claim in your docs becomes something to try to break.
You get: Invariant list
-
Attack it two ways
A fuzz harness written for your code runs while I check every function’s assumptions by hand. A harness counts only once it catches a bug I plant.
You get: The harness, yours to keep
-
Prove, challenge, report
Each finding gets a PoC on your real entry points, passes realism-gate, and survives the strongest case against it. Then I review your fixes.
You get: Report, then a fix review
ToolsetFoundryEchidnaMedusaHalmosSlitherSemgreprealism-gate
How I use AI. Models help me read and find leads. One argues a candidate is a bug, another argues it isn’t. Plain checks and I decide.
- A model may
- read code with me, suggest leads, and argue for or against a candidate.
- A model never
- confirms a finding, sets a severity, writes your report or sends anything.
What you get
Every finding proven. Every gap named.
Findings follow one standard. The rest of the report shows where the review went.
- Coverage mapWhat was fuzzed, what was read, and what the review did not reach.
- Ruled-out leadsEvery serious lead that died, with the reason it died.
- The fuzz harnessYour invariant tests, ready to run in CI.
- Root causeWhy the bug exists, at the exact line and commit.
- PreconditionsWhat must be true, and who can make it true.
- Attack pathEach call, by which account, in which transaction.
- Broken invariantThe property that fails, from the invariant list.
- Impact and likelihoodSeverity argued, with only demonstrated amounts.
- Proof of conceptA test on your code that asserts the full balance change.
- FixThe smallest safe change, plus a regression test.
To start
Send me five things.
That’s enough for me to say yes, no, or what I’d need to quote.
- What to review (repo link)
- Commit or tag
- Deployed addresses, if live
- Docs, prior audits and known issues
- When you need it
Questions
The short answers.
- Who does the work?
- Me. One researcher, no subcontractors. Tools and models assist; every finding is mine.
- What does it cost?
- Quoted per scope, once I’ve read the code.
- What if you find nothing?
- I say so plainly, and you still get the coverage map and the ruled-out leads. I don’t pad a report.
- Will my protocol be named here?
- No. The disclosure policy keeps every program and finding off this site.
Protocol team?
Let’s talk about your code.
Send the repo, the commit and your deadline. I answer every message myself.
Request a review