The bounty programme that closed because reading got more expensive than writing

In January 2026 the curl project ended its bug bounty after years of running one of the most respected disclosure programmes in open source. The reports had not stopped coming. That was the problem.

Half a day to disprove a paragraph

Imagine you triage security reports for a widely used library. A submission arrives. It is well structured. It cites the right function in the right file, describes a plausible integer handling error, includes a proof of concept that looks like every proof of concept you have ever read, and explains the impact in confident, competent prose. Nothing about it is obviously wrong.

So you do the work. You read the function. You read the callers of the function. You check the bounds logic, then you check it again because you assume you have missed something, because the report was confident and you are tired. You write a test to reproduce it. The test passes, which is to say the bug does not exist. You reread the report to see whether you misunderstood the claim. You had not. The line numbers were invented. The function does not do what the report says. The proof of concept never ran anywhere.

You have spent four hours. You write a polite reply. Then you open the next report, which is also well structured, also cites the right file, and also may or may not be describing something real.

Now scale that. The people doing this on most open source projects are volunteers, and there are very few of them. The maintainer of curl described exactly this dynamic, publicly and repeatedly, before concluding at the start of 2026 that the programme's economics no longer worked and shutting it down (The Register; BleepingComputer). Not because the reports were worthless. Because determining whether any given one was worthless had become the most expensive thing the project did.

What actually happened, and the fact that complicates it

The curl decision is worth stating precisely, because it has been reported in two incompatible ways and only one of them is right.

The wrong version is that AI generated security research is worthless and a famous project proved it. The right version is narrower and more interesting. The project had, since around May 2025, been operating a policy of banning reporters whose submissions it judged to be machine generated noise. That policy was itself an admission that the volume had become unmanageable. By January 2026 the maintainer concluded that running the programme cost more in triage attention from a very small team than it returned in genuine findings, and ended it (The Register; BleepingComputer; The New Stack).

Here is the fact that complicates any tidy narrative, and it deserves to sit right next to the first one rather than buried below it: over the same period, HackerOne reported a large year over year increase in valid vulnerabilities found with AI assistance. Secondary coverage puts that increase at around 210 percent for 2025, and the precise figure should be treated as directional since the underlying methodology is not public, but the direction is not in dispute. The same technology is producing genuine findings and unmanageable noise at the same time, through the same intake channel.

Any framing that treats AI assisted security research as simply illegitimate is factually wrong and will be dismissed by the researchers who are using these tools well. The tools find real bugs. They also let anyone generate a report that costs a stranger four hours. Both things are true, and the second one is what broke the programme.

Why did the economics break?

A bounty programme is an unusual economic arrangement and it is worth naming what makes it unusual, because that is where the failure is.

Almost every transaction has a cost on both sides. A bounty programme deliberately does not. It is an open call: anyone in the world may submit, submission is free, and the recipient is obliged to evaluate. That asymmetry is the entire point, because it is what lets a talented stranger in a country you have never shipped to tell you about a flaw you would never have found. The programme is a subsidy from the maintainer's attention to the world's curiosity, and for two decades it was one of the best trades in software. Research panels that pay for responses hit the identical wall, described in a third of your survey responses may not be from people.

That trade was priced against an implicit constraint nobody wrote down: writing a plausible vulnerability report was hard. It required reading code, understanding a memory model or a protocol state machine, and constructing something that at least appeared to work. The barrier was not moral, it was cognitive, and it did most of the filtering.

Fluency raises triage cost

Here is the counterintuitive part, and it is the most important idea in this post.

You would expect that better written reports are cheaper to triage. The opposite is true. An obviously bad report is cheap: it is incoherent, it cites a file that does not exist, it describes an impact that makes no sense, and a triager closes it in ninety seconds. A plausible but wrong report is expensive precisely because it is plausible. Every detail that makes it look credible is a detail the triager must go and check. Fluency is not a signal of quality. Fluency is a bill. This is the same dynamic that has appeared across every open intake channel in the last two years, catalogued in the Identity Failure Map.

So the cost of producing a report fell to approximately zero, and the cost of evaluating one rose. Not stayed flat: rose. That is the whole crisis in one sentence, and it explains why programmes are closing rather than merely slowing down.

The analogy that gets it across: imagine a restaurant that lets anyone send back a dish claiming it is undercooked, and the kitchen must cut open every returned dish to check. That works while sending a dish back requires walking in, sitting down, and ordering. It stops working the moment anyone can send one back from their phone, for free, from anywhere, in numbers. The kitchen is not failing at cooking. It is drowning in verification.

What are the remedies that do not need identity?

An honest post has to go through these first, because several of them are good and one of them is probably better than anything identity technology offers.

Require a working proof of concept

This is the strongest non identity answer and it should be said plainly rather than skipped over on the way to a product pitch. If a programme requires a reproducer that actually runs, in a specified environment, producing a specified observable outcome, then fabrication becomes expensive again. You cannot hallucinate a crash. The requirement restores the cognitive barrier that used to do the filtering, and it does so without asking anything about who the reporter is.

The costs are real. Some vulnerability classes are hard to demonstrate with a small reproducer, particularly logic flaws, race conditions, and issues requiring specific hardware. Some legitimate researchers report from environments where they cannot safely produce a working exploit. And building the harness to run untrusted reproducers safely is itself engineering work that small projects do not have. But for a large PSIRT, this is probably the highest leverage change available, and it should be the first thing on the list.

Reputation gating

Prioritise reports from researchers with a track record. This works, and every major platform does some version of it. The weakness is structural rather than incidental: reputation on a platform is attached to an account, accounts are free, and a reporter banned in the morning is a new reporter in the afternoon. Reputation systems only bite if there is something scarce underneath them, and an email address is not scarce. The same weakness undermines review systems, discussed in one human, one review.

Submission deposits

Charge a refundable deposit, returned if the report is valid. This directly fixes the asymmetry and it is the most economically elegant proposal on the list. It also punishes exactly the people the programme exists to reach: a student in a country where the deposit is a week's wages, a first time reporter who has never been paid for security work, a researcher without a payment instrument that the platform accepts. Deposits convert an open call into a members' club, which is a real cost that the proposal's advocates tend to understate.

Pay for triage

Fund the reading, not just the finding. This is the correct answer for well resourced vendors and it is why large PSIRTs cope better than open source projects. It is not available to a volunteer maintained library, which is precisely where the damage is concentrated, and it does not reduce the flood, it just absorbs it.

What does identity actually contribute?

Now the narrow claim, and it should be narrow, because the honest version of this argument is smaller than a vendor would like it to be.

Identity does not detect slop. It does not judge report quality. It cannot tell whether a submission was written by a person, by a model under a person's direction, or by a model with no supervision at all, and anyone claiming otherwise is selling a classifier by another name.

What it does is make reputation stick.

Every remedy above that depends on a reporter's history depends on the history belonging to a durable thing. Today it belongs to an account. Accounts are free, disposable, and per platform, which means a reputation penalty expires as soon as someone opens a new one, and a good reputation earned on one platform is worth nothing on the next. Reputation is the mechanism that would fix this, and the reason it does not work is that there is nothing underneath it to which reputation can attach.

Bind a submission to an enrolled human and three things change. A quota becomes meaningful, because it is per person rather than per account, so an unlimited flood requires an unlimited supply of people rather than an unlimited supply of email addresses. A ban becomes meaningful, for the same reason. And a track record becomes portable, so a researcher who has submitted forty valid reports across five programmes can arrive at the sixth with that history in hand, which is a benefit to the researcher rather than a burden on them. That last point matters, because a scheme that only serves programmes will not be adopted by the people it needs.

What a human bound submission looks like

POST /security/report
{
  "title": "Heap overflow in cookie parser",
  "body":  "...",
  "poc":   { "harness": "oss-fuzz", "artifact": "sha256:3f2a..." },

  "reporter": {
    "keyId":       "ed25519:c41f9b207e...",
    "quotaPeriod": "2026-09",
    "submissions": 3,
    "quotaLimit":  10
  },
  "assistance": {
    "declared":  true,
    "tooling":   "llm-assisted-triage",
    "reviewed":  true
  },
  "receipt": "https://manav.id/r/7T4pKq2M"
}

Three things in that shape are doing the work. The keyId is a public key, not a name, which is the point we will return to below. The quota is per key and per period, so it survives account creation. And the assistance block lets a researcher declare tooling honestly rather than hide it, which is the design choice that keeps the scheme compatible with legitimate AI assisted research instead of hostile to it. A declared, reviewed, machine assisted report from a researcher with a good history should be triaged ahead of an undeclared one from nobody in particular, and that ordering is only possible if declaration carries no penalty.

The anonymity objection, which is the serious one

This deserves its own section rather than a line in a limits list, because it is the argument that should determine whether any of this is acceptable.

A great deal of important security research is done by people who cannot attach their names to it. Researchers in jurisdictions where reporting a flaw has led to prosecution rather than thanks. Employees reporting bugs in software their employer sells. People whose government would treat a disclosure as an attack. Researchers who have been threatened by vendors for publishing. The history of vulnerability disclosure includes enough legal aggression toward researchers that caution is a rational response rather than paranoia.

Any intake requirement that forces a researcher to reveal who they are will lose exactly those reports, and those reports are disproportionately the ones about serious flaws in software that matters. That is not an acceptable trade, and a programme that makes it has made itself less safe while feeling more organised.

So the design constraint is absolute, and it is worth being explicit that this constrains us as much as anyone: the binding must be to a key, not to a name. A researcher enrolls, the system holds a one way key rather than an identity, and what accumulates is a pseudonymous track record. The programme learns that this is the same person who submitted the previous nine valid reports. It does not learn who they are, and neither does the intermediary. That is the same property that makes the approach usable for open source maintainers who publish under a handle, discussed in Sigstore proves the pipeline, nothing proves the person.

Even with key based enrollment, an anonymous path must remain open. Some reports will arrive from someone who will not enroll under any circumstances, and a programme that refuses them is worse off. The correct design is ordering, not exclusion: accountable submissions are triaged first, anonymous submissions are triaged after, and nothing is thrown away. A researcher who wants their report read this week has a reason to enroll. A researcher who cannot still gets read.

What are the honest limits?

A human can sign for a machine's output. Nothing here prevents a person enrolling and then submitting forty generated reports under their own key. What changes is that the cost lands on them: the quota constrains volume, and the reputation damage is permanent rather than disposable. This raises the price of flooding from zero to something. It does not make it impossible.

Quotas punish the prolific. Some genuinely excellent researchers submit a lot. A flat quota is a blunt instrument, and any real implementation needs quota that grows with validated history, which means new researchers start constrained. That is a real cost to newcomers and it partially recreates the problem reputation gating has.

This does nothing about report quality. An accountable human can submit a badly written report about a real bug, and frequently does. Triage effort does not disappear.

Platforms have weak incentives to make reputation portable. A bounty platform's commercial position rests partly on the researcher community attached to it. A portable, researcher held reputation reduces that lock in, which is good for researchers and programmes and bad for the platform's moat. Expect this to be the hardest part of adoption, and note it is a business problem rather than a technical one.

None of this is shipped for bounty platforms. Manav provides the signing, the pseudonymous enrollment, and offline verifiable receipts, documented in the developer docs, with the human bound submission pattern demonstrated in the bot job applications lab, which is the same shape applied to a different intake. There is no HackerOne or Bugcrowd integration. Everything above about platform adoption is a proposal.

What to do this week

1. Measure your triage cost honestly. Hours spent per report, split by outcome, for the last three months. Most programmes have never calculated this and the number is usually startling.
2. Calculate your invalid report rate over time rather than in aggregate. The trend line is the thing that tells you whether you have a problem or a workload.
3. Add a working reproducer requirement for the classes where one is reasonable, and say explicitly which classes are exempt so you do not lose logic bug reports.
4. Add an assistance declaration field to your intake form, and state in your policy that declaring tooling will not count against a report. Undeclared assistance is the thing to penalise, not assistance.
5. Publish your triage ordering. If accountable or reproducer backed reports are read first, say so, because the incentive only works if reporters know about it.
6. Preserve an anonymous intake path and document it, including a route that does not require an account at all.
7. If you are on a platform, ask them what a researcher's reputation would be worth if they moved to a different programme. The answer tells you who owns it.

Frequently asked questions

Why did curl end its bug bounty? The project ended its HackerOne programme in January 2026 after a sustained volume of low quality and frequently machine generated vulnerability reports made triage unaffordable for a very small security team. The maintainer had described the burden publicly over the preceding year, including a policy of banning reporters whose submissions were judged to be generated noise.

Is AI assisted security research the problem? No. Over the same period HackerOne reported a large year over year increase in valid vulnerabilities found with AI assistance, so the tools are producing genuine findings. The problem is that producing a plausible report became free while evaluating one became more expensive, and the intake channel cannot tell the two populations apart.

Why not just detect AI written reports? Detection judges writing style, which is both unreliable and unfair. It misfires on non native English speakers and on anyone who uses a model to tidy their prose, and it says nothing about whether the underlying finding is real. A report should be evaluated on whether the bug exists, not on how it reads.

Would a submission fee fix this? It would reduce volume, and it would exclude students, researchers in lower income countries, and anyone without an accepted payment instrument. Those are disproportionately first time reporters. A deposit turns an open call into a members' club, which is a real cost that should be weighed rather than waved away.

Can a researcher stay anonymous under this model? Yes, and the design fails if they cannot. Enrollment binds a public key rather than a name, so what accumulates is a pseudonymous track record. A programme learns that this is the same person as last time without learning who that person is, and an anonymous path should remain open, triaged after accountable submissions rather than refused.

What stops someone enrolling and submitting slop anyway? Nothing stops it, but the cost changes. Volume is bounded by a per person quota rather than by how many email addresses they can create, and the reputation damage attaches to a key they cannot discard. The aim is to raise the price of flooding, not to make it impossible.

Does this help small open source projects or only large PSIRTs? It helps small projects more, because they are the ones without the budget to fund triage. A large vendor can absorb the flood by hiring. A library maintained by a handful of volunteers cannot, which is why the programme closures have concentrated there.

Sources

1. The Register, on curl ending its bug bounty programme to stop AI generated submissions, January 2026: theregister.com security
2. BleepingComputer, on the curl bug bounty shutdown following a flood of AI generated reports: bleepingcomputer.com security news
3. Daniel Stenberg, curl maintainer, writing on the project's handling of generated vulnerability reports: daniel.haxx.se/blog
4. curl project security policy and disclosure documentation: curl.se/docs/security.html
5. HackerOne, reporting on AI assisted vulnerability discovery trends: hackerone.com/blog
6. ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: iso.org
7. ISO/IEC 30111, Information technology, Security techniques, Vulnerability handling processes: iso.org
8. Regulation (EU) 2024/2847, the Cyber Resilience Act, including vulnerability handling obligations: EUR-Lex
9. CVE Program, on CNA rules and vulnerability record requirements: cve.org

The bounty model did not break because machines started finding bugs. It broke because sending a report costs nothing and reading one costs an afternoon.