We gate disclosure on a working proof
A plausible argument that something is exploitable is not a finding. It's a hypothesis. We don't send it to a client, and we don't put it in a report, until it's been turned into something that runs: a test, a script, a transaction sequence that demonstrates the impact on a fork of the real system.
This sounds obvious until you watch how much security work skips it. "An attacker could probably…" is easy to write and hard to act on. The team on the other end has to either trust it or spend their own time reproducing it — and if it turns out not to hold, you've spent their goodwill on a false alarm.
The bar
Our internal rule is simple: a finding leaves the building only when it carries a proof that someone else can run and watch fail. For a smart-contract issue that usually means a failing invariant or a forked-state script that moves value it shouldn't. For an off-chain issue it's a request sequence or a small harness. The proof doesn't need to be weaponized — it needs to be real and repeatable.
If we can't reproduce it on demand, it isn't ready to be your problem yet.
What the discipline buys
- Calibrated severity. Once you have a working proof, the impact is observable rather than argued. High stops being a rhetorical choice.
- Faster fixes. A reproduction is also a regression test. The team fixes against the exact thing, and the proof flips from red to green when they're done.
- No crying wolf. Programs and protocol teams drown in low-signal reports. Gating on proof is how we stay worth reading.
- Honest disagreement. If a proof can't be built, that's information too — sometimes the "bug" depended on an assumption that doesn't hold in the deployed system.
It also keeps us honest
The bar applies inward first. Before a finding reaches a client, someone other than the author tries to break the proof — to make the exploit not work, to find the assumption it quietly relies on. Plenty of promising leads die there, and that's the point. What survives an attempt to refute it is what we're willing to put our name on.
None of this is glamorous. It's the unflashy part of the work: write the harness, run it, watch it fail, hand it over. But it's the reason a Dakara finding tends to be one you can act on the same day you receive it.
Running a disclosure program and tired of triaging maybes? We can help with validation and write-ups, or take the review end to end.