Duplicates and known issues
How Proofline verifies duplicate and known-issue claims without exposing anyone else's report.
You can't avoid a duplicate that was completely private. Proofline treats it that way.
Duplicates
When a project claims your report duplicates an earlier one, the platform checks, not the project:
- the earlier report exists in the same program,
- it was submitted before yours,
- it wasn't itself closed as non-qualifying (invalid, out of scope, spam and so on).
You receive a verified attestation showing the original's fingerprint, when it was submitted, how much earlier than yours, whether the asset and vulnerability class match, and its current state. You never see the other researcher's report, and they never see yours.
| Classification | When | Effect on you |
|---|---|---|
| Private duplicate | The earlier report wasn't public when you submitted | Neutral: no reputation or accuracy penalty |
| Publicly known | The earlier report had been publicly disclosed before you submitted | Counts toward accuracy (it was knowable) |
Known issues
"We already knew about this" isn't enough. A project must have recorded a known-issue commitment before your submission:
- When a team learns of an issue, it records a hash
sha256(salt | description)with a timestamp. The description stays sealed. - To claim a known issue, the commitment must predate your report. The platform checks the timestamp.
- The project can reveal the sealed text in your Casefile. Anyone can then recompute the hash and confirm it matches the commitment, proving the description wasn't written after the fact.
A known issue you couldn't have known about is a neutral outcome, like a private duplicate.