A security practice, not a scanner with a report template
Namada audits smart contracts, tests web applications and triages bug bounty reports. The work is done by the researcher whose name is on the report, supported by deterministic engines and three narrow model passes.
Namada is a security research practice. We audit smart contracts, test web applications and APIs, and triage bug bounty reports for teams that ship continuously.
The practice is deliberately small, and it is built so that the researcher whose name is on the report is the researcher who did the work. There is no account layer between you and the person who found the finding, and no hand-off to a junior reviewer once the contract is signed.
It is also not a scanner with a report template on top. The deterministic engines do the parts of an audit a machine does better than a person, the models do one narrow job each, and a human decides what is true and what is worth your attention.
- Rule classes
- 30
- Posture checks
- 18
- Model passes
- 3
- Source retained
- 0 B
How we work
Each of these changes what ends up in a report, which is the only test a principle has to pass. The middle two are the expensive ones to keep.
Honest findings over volume
A longer report is not a better one. Padding a document with candidates a reader has to dismiss themselves buries the findings that matter, so three findings we can stand behind are worth more than thirty we cannot. When the honest answer is that nothing high-severity turned up, the report says that plainly.
A finding a client cannot reproduce is not a finding
Every reported finding ships with the steps to demonstrate it against a running target — a failing test, a transaction trace, a request and response. If we cannot make it happen ourselves, it does not appear in the report as a finding. It becomes an appendix observation, or it is dropped.
Refutation before reporting
The first pass over every candidate does not ask whether the finding is real. It asks the opposite: prove this is unreachable. That pass looks for the guard, the modifier or the branch that makes the candidate a false positive, and only what survives the argument is carried forward.
Written to be acted on
Every finding names the asset, the impact and the fix, in that order. A report that needs its author in the room to be understood has not finished its job, and the engineer who inherits it six months later is the one who pays for that.
Where the human sits in a human-led practice
The method is an argument about who does what. Each part is given the work it is actually better at, and the part that ends up in your report is never delegated.
Exhaustive, repeatable work. Thirty rule classes — fifteen Solidity, eight Vyper, seven Rust and Anchor — hold every line against a known failure mode, and a CVSS v3.1 vector is computed to the integer rather than estimated. The web scanner runs eighteen posture checks and is a labelled simulation: it derives a report from the target name and sends no traffic. Machines are better than people at being thorough and consistent, so we let them be both.
Three narrow jobs rather than one general instruction to review the code. The refutation pass runs on the frontier tier — Claude Mythos 5.1 where the deployment is admitted to Anthropic’s Cyber Verification Program, Claude Fable 5.1, the same core model under general-release safeguards, everywhere else — and returns a verdict only; it is not permitted to write code. Claude Opus 5.5 runs only over the survivors, writing the smallest change that closes each one and a test that fails before it and passes after. Claude Sonnet 5.5 reads an inbound bug report against the vector the engine derived and judges what arithmetic cannot: impact the reproduction steps do not support, evidence asserted but not attached.
A person reproduces every surviving finding before it reaches your report, sets its severity, decides what is worth reporting and puts their name on it. A model can argue that a candidate is unreachable; it cannot know that a finding matters to your deployment, and it is not asked to. The judgement in the report is human, and so is the responsibility for it.
Where the method comes from
Most of the work of an audit is not finding candidates — any scanner produces those in seconds. It is discarding them: reading each one, working out whether it is reachable in this particular deployment, and throwing away the ones that are not. That is the expensive, unglamorous half of the job, and it is the half a report full of false positives quietly skips.
The engines here are built around that observation. The rule pack proposes, the refutation pass argues each proposal down, and a person only ever looks at what is left. It is a slower first pass and a much faster second one, and the report that comes out is shorter and true.
That is the whole of it. There is no story here beyond the method — the practice is the method, applied carefully, by people whose names are on the reports.
Run the method before you take our word for it
The sandbox on the overview page runs the same deterministic rule pack and triage engine described here, on code you paste — no account, and the source is discarded with the response.