Six phases, in the order they happen, with what we need from you at each one. Published in full because the process is the product.
We fix a commit hash, agree the in-scope contracts and read your architecture docs, then build a threat model: who the actors are, what the trust boundaries are, and which invariants must never break. Nothing is reviewed against assumptions we have not written down.
Line-by-line review by at least two auditors working independently, focused on authorisation, accounting, upgrade paths, external integrations and the gap between what the code does and what the documentation claims it does. Most critical findings come from this phase, not from tooling.
Static analysers appropriate to the language, plus property-based fuzzing and invariant testing to push the system into states no unit test covers. Tooling is used to widen coverage, never to replace the manual pass.
Candidate findings are proven on a forked network with a working proof of concept. We report what an attacker can actually do and what it costs them, not a theoretical severity label.
Every finding gets a severity rating, reproduction steps, the affected code, the impact in concrete terms and a specific remediation. You get a draft for discussion before anything is finalised.
We re-test every remediation against the original proof of concept and check that the fix has not opened a new path. The final report is yours to publish.
| Severity | What it means |
|---|---|
| Critical | Direct loss of funds or permanent freezing of assets, exploitable by any actor. |
| High | Loss of funds or protocol insolvency under realistic conditions, or requiring a privileged actor to misbehave. |
| Medium | Broken protocol behaviour, denial of service, or value leakage that does not directly drain the contract. |
| Low | Edge-case incorrectness with limited impact, or an issue requiring implausible preconditions. |
| Informational | Code quality, gas efficiency, documentation mismatch and defence-in-depth suggestions. |
In six phases: scoping and threat modelling against a frozen commit, independent manual review by at least two auditors, static and dynamic analysis including invariant fuzzing, exploit-path simulation with working proofs of concept on a forked network, a severity-rated report you can challenge before it is finalised, and a fix-review pass after you remediate.
You get a quote within 24 hours of sending the repository. The review runs from two days for a single token contract to several weeks for a large protocol. Fix review happens after you patch, on your schedule.
A frozen commit hash, whatever specification exists, a written list of invariants that must always hold, a green test suite, and one technical contact who can answer design questions within a day.
Yes — the same day, on your channel of choice. Critical findings do not wait for the report.
Yes. You get a draft before anything is final and we will argue it out. If we still disagree, our rating stands with your position documented in the report.
Yes. Fix review is part of the engagement, not an upsell. We re-run the original proof of concept against your patched code and confirm the fix has not introduced a new path.
It is your report and your decision. Most clients publish, because a public report is a trust asset for listings, investors and users. If you need to stay private until launch, we hold it.
We stop and tell you immediately — the same day, on your channel of choice. Critical findings do not wait for the report.
Send the repository and a commit hash through the contact form, message @bugtester25 on Telegram, or book a 30-minute scoping call. 200+ protocols audited · $4B+ secured · 0 hacks post-audit. Prefer email? info@safeedges.in.