01
Scoping
You send a repository and a commit hash. We count the lines in scope, read the documentation, and return a fixed fee and start date. If the code is not ready for audit, we say so here rather than taking the engagement.
1–2 days
Methodology
How an audit actually runs.
No mystery, no proprietary framework, no scoring engine. A methodology is only worth publishing if it survives contact with someone checking whether you followed it.
02
Context
We read your docs, tests and deployment scripts before the code. An auditor who does not understand what the system is supposed to do cannot tell when it does something else.
Day 1
03
Automated pass
Slither, Aderyn, an AI-assisted first pass, and the compiler’s own warnings, run first to clear the noise. Every finding any of these tools raises is manually verified before it reaches your report. This catches perhaps a fifth of what matters. We do not bill it as the audit.
Hours
04
Manual review
Line by line, function by function, against the checklist on our service page. This is where the findings that matter come from, and it is most of the engagement.
Bulk of the work
05
Testing
Foundry invariant and fuzz tests for the properties your system must never violate. Proof-of-concept exploits written for anything rated high or critical, so the finding is demonstrated rather than asserted.
Project tier and above
06
Report
Severity-ranked findings, each with location, impact, reproduction and a concrete fix. Plus an explicit list of what was out of scope.
1–2 days
07
Remediation and re-review
You fix, we verify. Included in every paid tier. We do not bill twice for the same code. If a fix introduces a new problem, that is our job to catch, not yours to discover in production.
2–3 days
08
Publication
With your written permission, the final report goes on our public register. Never without it.
Your call
How we rate severity
Severity is impact multiplied by likelihood, judged in the context of your system rather than against a generic table. We describe the reasoning in every finding so you can disagree with it.
| Severity | Meaning |
|---|---|
| Critical | Direct loss of funds or permanent freezing, reachable by any attacker without unusual preconditions. |
| High | Loss or freezing that requires specific conditions, or a break of a core protocol guarantee. |
| Medium | Limited or conditional loss, degraded functionality, or a problem that becomes serious in combination with another. |
| Low | Minor deviation from intent, unlikely to be exploited but worth correcting. |
| Informational | Code quality, gas, and documentation issues with no security impact. |
What an audit cannot do
An audit is a review of specific code at a specific commit by people with finite time. It reduces risk. It does not eliminate it, and anyone who tells you otherwise is selling something.
- It cannot cover code you changed after the review ended.
- It cannot guarantee that no bug remains, only that we did not find one.
- It cannot protect against compromised private keys, malicious insiders, or a governance vote that does something foolish.
- It cannot fully model your economics under conditions nobody has seen yet.
We put this in every report, because a client who over-trusts an audit is more dangerous to themselves than one who never had it done.
Free monitoring assessment
See the methodology applied to your code.
A free snapshot follows the same process at smaller scale. It is the cheapest way to find out whether we are worth paying.
- Reply written by the auditor who read your code
- No sales sequence, no drip campaign, no retargeting
- We’ll tell you if you don’t need a paid audit yet
- Report published only with your written permission