KhomDev
Hire me

I study why security findings don't get paid, and build the AI systems that fix it.

Independent researcher in blockchain security and agentic AI engineering. Available for hire

Read on Paragraph Follow on X

111 submissions.Every one rejected.

Each square is one rejected finding from four months of bug-bounty work. I went back through every row and asked which check would have caught it first.

70.3%

78 of 111 were catchablebefore I read a line of code.

The problem was mostly targeting, not analysis, so I built tools that check the targeting first. See the dataset.

  • 41 Duplicate check: A known-issues list or public record already had it.
  • 29 Program rules: Exclusion clause, severity floor or scope tree.
  • 8 Prior audit & tests: An earlier audit or the test suite said it was known or intended.
  • 33 Only after the code: Design intent, no attacker win, realism, or the payout floor.

The ledger so far.

Both sides of one log: what was rejected, and what was accepted and paid. Each figure comes from a public repository or my public profile, and this site's build fails if one drifts from the published data.

111rows Rejections logged rejection-taxonomy 70.3%78 of 111 Catchable before code rejection-taxonomy 22with evidence Anti-patterns viability-gate 59in-sample Calibration pairs calibration.md 3MIT licensed Open repositories github.com/KhomDev Read the research Every article links the repository that proves it.

Accepted & paid

Live from my HackenProof profile, read 21 Oct 2026.

View profile
18 paid reports
High
2
Low
16
Leaderboard rank
#230
Reputation
525
Programs influenced
49

Verified at build, 21 Oct 2026. Don't trust the figures: re-hash the file.

sha256
d56552a0…1a22d56552a0932e7eb004685831910f556f40bb455f0ef946b2394200065c1d1a22

Rejections cluster. So should your checks.

Three open tools, one per failure mode. Checking a finding is one command, and none of them ships a program name, a chain or a reward table.

$ cargo install viability-gate$ vg check finding.mdviability-gate 0.4.2  —  finding.md  OUTCOME   KILL            A hard blocker fired. Do not submit as written.
v0.4.2 MIT, runs offline Source 
$ git clone https://github.com/KhomDev/rejection-taxonomy$ cd rejection-taxonomy$ python scripts/query.py --prehunt$ python scripts/query.py --triage duplicate
v0.4.0 MIT code, CC BY 4.0 data, runs offline Source 
$ git clone https://github.com/KhomDev/bounty-economics$ cd bounty-economics$ python scripts/validate.py --taxonomy$ python scripts/validate.py my-ledger.yaml --format json
v0.3.0 MIT, runs offline Source

Latest releases

  • viability-gate v0.4.2 Tracked to 111 rejections
  • bounty-economics v0.3.0 Validated against 111 rejections
  • rejection-taxonomy v0.4.0 111 logged rejections
The release log

Research so honest, it publishes its own failures.

Every article ships one number and the public repository that proves it.

The finding was real. The code did what I said it did, the proof compiled, the number was real — and the report was still worth nothing. Three findings that each died at a different checkpoint, and the gate I now run before the proof, not after. Read on Paragraph A repository is a claim about what is deployed. Here is how I now check the claim before I spend the week. Read on Paragraph A green test proves what the harness allowed it to prove. Here is how I now check what mine allowed. Read on Paragraph One question per row. I went back through every rejection and asked which check would have caught it before I spent the time. The answer is seven gates, and what each one cost me to learn. Read on Paragraph Most wasted effort is not spent on hard bugs. It is spent on findings that were dead on arrival: excluded classes, privileged-role preconditions, payout floors and duplicates, all knowable before anyone opens an editor. Read on Paragraph Three of my findings were confirmed valid by the teams that received them. Real bugs, working proofs of concept. I was paid nothing for any of them, because the reward tables had no tier at that severity. Read on Paragraph Four months ago I started hunting bugs for money and logged every single rejection. My first payout was $0.02, and most of those rejections were catchable before I read a line of code. Read on Paragraph

I tested my tool on my own rejections. The gap is the result.

Reporting either number alone would misrepresent it.

23.7% Strict: the tool named the gate that actually decided it.
76.3% Lenient: the tool named any gate-mapped reason to stop.

59 rejections matched to their original finding text, scored on whether the tool flagged the gate the program closed it on. In-sample, so closer to a ceiling than an estimate. It is good at telling you to stop and bad at telling you why. Read the method and its caveats.

An audit pipeline where the model never gets the last word.

Deterministic gates own state, severity and readiness. Model output is advisory, and nothing is ever submitted automatically.

What it catches, and what it can't

Recon

Pin the commit, transcribe the program page, map the in-scope file tree. The audit gets an identity and a manifest before anyone reads code.

Pre-hunt gates

Fork novelty, severity floor, every exclusion clause, scope tree, prior audits, test intent. A failed gate stops the hunt before money or time is spent.

Fuzz

A hand-written harness per project, plus generated invariant suites. Failing invariants become leads, never conclusions.

Hypotheses

Assumption inversion first: for every in-scope function, what does it assume about caller, ordering and external calls, and does the code enforce it?

Realism gates

Attacker model, PoC privilege audit, impact reachability, realistic configuration, deployed state, program rules, and an adversarial reviewer that writes the likely rejection.

Three ways out. None of them is "submit".

READY_FOR_HUMAN_REVIEWEvery gate passed. A person decides.
HELDMechanism real, impact not. Kept with its evidence.
ZERO_FINDINGSAfter a devil's-advocate pass on every critical function.

Frequently asked questions

Anything not covered here, ask on X or by email. Both reach me directly.

Who is KhomDev?

One independent researcher, Yuriy Khomenkov. Not a team, a firm or a lab. I hunt bugs in public bounty programs, log every outcome, and build tools from what the log teaches.

Where do the numbers come from?

From three public repositories and my public researcher profile. Every research figure is generated by a script in a repository, and the site's build fails if one drifts from the published data. Platform numbers are read from the profile each time the site builds.

Can I use the tools?

Yes. All three are MIT licensed, run offline and need no API key. They ship rules and schemas, never program data, so you point them at your own private ledger.

Do you name programs or findings?

Never next to an outcome. No program, protocol, function or finding ID, no triage quotes, nothing still awaiting a verdict. The disclosure policy has the full rules.

Read the disclosure policy

Do you take audit work?

Yes, I am available for hire: smart contract security reviews and audits. There is no client list or price sheet here yet, so send the scope and timeline on X or by email, and I will tell you plainly whether I am the right fit.

Message me on X or yuriykhomenkov@gmail.com

What's with all the squares?

Each one is a rejected finding. There are 111 of them, and 78 could have been caught before I read a line of code. That is the whole site in one picture.

Your hunt for unpayable findings ends here. Check the targeting first.

New articles, datasets and tools as they ship. I am also available for hire: for a review or audit, a message on X or an email reaches me directly.

Hire me Follow on X Read on Paragraph GitHub