Why bug bounty reports get rejected
Twelve checks, distilled from 105 real case files across five platforms. The wins and the closures. Every check exists because real reports were closed for that reason. For each one: the question it asks, why reports die on it and the verdict it leads to.
1 hosted review per UTC day on your own model. No card.
Built by Tradi3: 2nd of 133 in Immunefi’s Firelight competition and 8th of 65 in Quantus.
The gauntlet returns exactly one of these, with one blocker and the cheapest action that removes it.
A report is closed at the first of these a triager reaches. Each one is answered by a check that comes before the report is filed.
Out of scope
The file is not in the scoped asset, the revision is not the deployed one, or an exclusion names the bug class.
Checks 04 05Intended behaviour
A comment, a project test or the introducing commit describes the behaviour as the design.
Checks 03Trusted role or user error
A decisive step is performed by an admin, an operator or the victim.
Checks 01Duplicate or known issue
A known issue, an audit note, a branch, a pull request or your own earlier report has the same root cause or the same fix.
Checks 06 07 12Impact not demonstrated
The proof shows the bug and never asserts the loss, a mock performs the deciding step, or the starting state has no public route.
Checks 08 09Severity downgraded
The loss is recoverable, or the body argues a lower row than the one selected.
Checks 10Incomplete submission
The stored submission is missing the proof, or the form says one thing and the body another.
Checks 11Each check asks one question. A report that fails the first never needs a proof.
Who performs every step, and who supplies every decisive value?
A programme pays for what an unprivileged attacker does. When the deciding step belongs to an owner, an operator or the victim’s own approval, the report is closed as a trusted-role or user-error case, however real the flaw in the code.
Drop
Which new evidence defeats each reason you recorded when you held this finding or lowered its severity?
A finding reads stronger on the second look because nothing argues back. A report revived with no new evidence is closed for the reason already written in your own notes.
Earlier verdict stands
Did the project mean this behaviour, and does the bug step add anything over the intended path?
Behaviour the project documented, tested or introduced as an audit fix is closed as intended. A proof that reaches the same end state without the bug step shows no loss the design did not already allow.
Drop
Does an exclusion name this class, and does every clause of the impact row have an artefact behind it?
A triager reads the exclusions first and the impact row word by word. One matching exclusion ends the report, and one clause with nothing behind it moves the report to a lower row.
DropRewrite, then submit
Does the cited code exist in the scoped asset, at the revision that is deployed?
A bug in a branch, a mirror or an old tag is a bug in something the programme does not pay for. A proof built on another revision proves that revision and leaves the deployed one untested.
DropProve first
Does a known issue, an audit note, a branch or a pull request cover the same function and consequence, or carry the same fix?
Duplicates are judged on root cause and on the fix. Titles, wording and the strength of the proof carry no weight, so a report on a root cause someone already wrote down is closed.
Hold: duplicate
Stated with no file and no entry point, is the broken invariant one you have already reported on this programme?
Two reports on one invariant are grouped as one finding, and the later one is closed against the earlier. New evidence belongs in the report that already exists.
Hold: duplicate
Does the final assertion read the object the impact row names, on production code, with the command and its output in the report?
A proof that shows the defect and describes the loss leaves the impact unproven. Triagers pay for an end state they can see asserted, and a proof they cannot run or read inline counts as no proof.
Prove first
Does every state the proof sets up have a route from live state by public calls?
A test can write any state it likes. A state that no public call reaches is an artefact of the test, and the report is closed as not exploitable.
Prove first
Which row of the programme’s own scale does the proof assert, after every recovery action is applied?
Severity is graded on the programme’s written scale, read literally. A tier claimed above the measured loss, or a loss the project can undo, is downgraded.
Rewrite, then submit
Does what the platform stored match the draft: the proof field, the severity, the impact row?
The triager judges the stored submission and never sees the draft on your disk. An empty proof field, or a form that disagrees with the body, closes a finding that is real.
Rewrite, then submit
Small fix, old code, central path, checklist class: how long before someone else files it?
Other hunters file in private, so a clean public search says nothing about who is ahead of you. A bug that is easy to find on old, central code is found more than once, and the later reports are closed as duplicates.
Sets a filing deadline
The executable version of each check runs inside the gauntlet.
The reports that were paid share these. Each line answers one or more of the checks before the triager asks.
An executed proof with its command and output, plus a control case.
03 08A final assertion on the object the impact row names: a balance, an owner, a stored record.
04 08The exact code location on a pinned revision, and a concrete fix.
05A title that states mechanism and consequence in one sentence, with numbered attack steps kept separate from test code.
01Limits and non-claims stated by the author, with the nearest known issue named and distinguished.
06The impact row quoted verbatim.
04 10Filed within hours of reproduction, with variants folded into one report.
07 12The same checks, run as eight stages on your draft, your code and the programme rules. The order runs the gates that end a report before the stages that cost work.
scope
Whether the code is in the scoped asset at the deployed revision, whether the class is excluded, and whether every clause of the chosen impact row has an artefact behind it.
provenance
Who performs each step, whether the behaviour is documented design or an audit fix, whether the bug adds anything over the intended path, and whether every precondition is reachable from live state.
prior-art
Whether a known issue, a prior audit note, a team branch or your own earlier report has the same root cause or the same one-line fix.
poc
Whether the proof runs production code on every step and ends by reading the object the impact row names, with measured numbers.
severity
The highest row of the programme’s own scale that the proof fully asserts, after every downgrade clause.
triage
The one sentence that closes this report in ten minutes, and whether the first paragraph already answers it.
report
Whether the claims follow from the code, the proof is inline, the form and the body agree, and the limits are stated.
verdict
One decision.
The seizure bug is in the code. The proof reads the return value of liquidate on a mock oracle; the impact row names the borrower’s collateral.
One decision, one blocker, the cheapest action that removes it and a filing deadline. Read the full example dossier
Both run on your own model and your own key.
Pick the profile that matches the check you are on: scope, provenance, prior art, proof, severity, triager or report. One hosted review per UTC day.
One run takes the draft through all eight stages and returns the verdict dossier. Each stage reads the output of the stages before it.