Closing the ZCG Vulnerability Bounty Program

[ZCG]

Closing the ZCG Vulnerability Bounty Program

Software security is entering a new phase. AI-assisted development and analysis tools are changing not only how software is written, but how vulnerabilities are found, reported, duplicated, and remediated.

For defenders, this is a major opportunity. AI is increasingly useful at well-scoped “needle in the haystack” tasks: finding every place a security invariant is enforced, comparing similar logic across implementations, identifying stale assumptions, and tracing whether a particular check still protects the thing it was designed to protect. In a large codebase, that can surface vulnerabilities that have been visible in source for years but practically hidden behind scale, complexity, and human attention limits.

But the same shift also changes the economics of vulnerability disclosure. Tasks that once required days or weeks of manual research can now be attempted in hours. While this is highly beneficial when it results in a carefully validated report, it becomes harmful when it generates a stream of speculative, duplicated, or AI-hallucinated submissions that still require serious human triage.

The curl project has already lived through this transition. Daniel Stenberg, curl’s creator and lead maintainer, first described the burden of AI-generated vulnerability reports as “death by a thousand slops.” In early 2026, curl ended its monetary bug bounty after an “explosion in AI slop reports” and a sharp drop in confirmed vulnerability rate. A few months later, after incentives changed, Stenberg described a new phase: the slop problem had largely disappeared, and “almost every security report now uses AI” while the reports were “mostly very high quality”. Zcash is now on the same path Stenberg charted.

The first phase is complete. We’ve reduced the short-term risks introduced by these new models, tools, and capabilities. Even after this short period of time, we are seeing the same curve begin to form. The vulnerability program has helped surface and resolve important issues, and the ecosystem is stronger because of the researchers who have contributed high-quality reports. We are grateful for that work.

At the same time, the bounty model is still attracting a growing volume of duplicate, low-signal, and speculative submissions across Zcash repositories. Some are useful. Many are not. Every report, even a flawed one, must be treated with care until it is understood. That work pulls scarce engineering and security attention away from remediation, audits, releases, and other user-protecting work.

For that reason, effective today, the ZCG Security & Vulnerability Disclosure Initiative is closed, and with it the ZCG Vulnerability Bounty Program. The responsible disclosure process remains open, and we still encourage researchers to report valid, reproducible vulnerabilities through the appropriate private channels. However, under current conditions, we cannot incentivize the disclosure lottery that exists today. Reports already submitted before this announcement will be handled under the terms that applied at the time of submission.

Structured security work continues. Least Authority remains Zcash Ecosystem Security Lead, covering audits, vulnerability coordination, and expert consultation, with ZCG funding work that incorporates AI into the auditing process. This work remains central to strengthening Zcash over the long term.

ZCG is also working with Zellic on access to V12, an AI-assisted auditing platform that combines LLM-based analysis with traditional static analysis. Tools like this point toward a more sustainable model: proactive, repeatable, high-signal review that helps core teams find and fix issues before they become public disclosure events.

We thank every researcher, engineer, auditor, and maintainer who has helped improve Zcash security. The disclosure process remains open. High-quality, good-faith security reports remain welcome. Our commitment remains unchanged: to protect Zcash users, strengthen the protocol, and continuously improve the ecosystem’s security as the threat landscape evolves.

Thanks,
Zcash Community Grants Committee (ZCG)

[dismad]

This is a really interesting retrospec that can help us better understand the evolving relationships between humans and AI. Thanks for the good communication!

[scalar]

The bounty existed for the right reason. It worked as intented to me but the structure was meant to fail. It really turns a filtering problem into the loss of an invaluable security channel.

Relying on goodwill toward the project is not enough. If disclosure to the project is not rewarded, the incentive will shift toward exploit or competing against adversarial bounty programs that will.

Just port the program to HackerOne, Immunefi, HackenProof seriously to solve this triage flaw …

[ouicate]

I reported a valid vulnerability to Zcash Core Repository that was confirmed and accepted. However, the severity was later downgraded after maintainers introduced their own internal severity criteria following my report, which does not appear to align with BountyZcash’s website, specifically the statement:

“Multi-Org Accountability — No single organization controls severity classification or disclosure timing. The multi-org triage model prevents both downplaying and sensationalizing — the two failure modes that destroy community trust.”

For reference, see the discussion at zcash github: #7168

At this point, I’m trying to understand the next steps. Will someone from ZCG join the advisory process, independently review the issue, coordinate disclosure, and pay the bounty reward?

I’m asking because I also received the following response from nuttycom (Kris Nuttycombe) :

"Ouicate you need to take this up with Zcash Community Grants; to the best of my knowledge, no such independent review panel actually exists; nobody from ZODL has been asked to join such a panel, at least.

You need to understand that neither ZCG’s rubric, nor the bounty schedule, nor the role of the employees of the various Zcash support organizations were discussed with the maintainers prior to the announcement of the program. I understand that you’re seeking compensation under the bounty program, but that bounty program is not in any fashion my responsibility. If the maintainers’ severity judgments were supposed to be taken into account by Zcash Community Grants in their decision to award bounties, then they needed to discuss that with us beforehand."

The current situation is confusing because the public bounty policy suggests independent multi-party accountability, while the actual handling of the report appears to depend entirely on maintainers’ internal decisions. Clarification on the review process, severity determination, and bounty governance would be appreciated. @ZCG @zooko

[artkor]

Have any updates been made to the core infrastructure regarding the vulnerability you reported?

I think that is the main criterion for fairness.

[ouicate]

Yes @artkor . So far I have:

• one accepted finding in the zcashd repository,

• two accepted findings in Zebra,

• one accepted finding in lightwalletd,

• and a few additional pending reports in Zaino and wallet.

The accepted issues are currently still under coordinated handling / draft status and are not public yet, but the maintainers acknowledged the findings and began tracking fixes or remediation discussions internally.

The reason I reached out here is that maintainers from multiple projects indicated that bounty handling and severity/payment decisions were ultimately under ZCG / BountyZcash governance rather than the maintainers themselves. For example, I was explicitly told to contact ZCG regarding the review and bounty process because the maintainers were not sure how the bounty coordination was intended to work @nuttycom.

That is where the confusion comes from on my side: the reports appear to be valid, accepted, and in scope under the public BountyZcash program, but the actual process for independent review, severity determination, disclosure coordination, and payout responsibility is still unclear to me.

I’m mainly looking for clarification on:

• who performs the final bounty review,

• whether there is an independent/multi-org advisory process,

• and how accepted in-scope reports are formally transitioned into the BountyZcash payout workflow.

[artkor]

Wow, you responded so quickly and in such a well-organized way…

Let me try to put myself in your shoes. The shoes of a conscientious contractor working for the good of Zcash and unfairly ignored by the developer community. I unexpectedly found a very serious vulnerability that threatens the security of the network. I report it to the experts, but they seem to just brush me off. What should I do?

The first thing I would do is approach highly reputable independent experts who could actually confirm that what I’ve found poses a serious problem. I would probably try to speak out about it from their grandstand. Then, if that didn’t work, I would use this critical vulnerability to draw attention to myself. Yes, I suppose that’s what I would do.

PS Please don’t take this as a guide to action, though; I wrote this not as a member of ZCG, but in a personal capacity.

[ouicate]

Thanks @artkor — yes, fixes and remediation work have already begun across multiple affected repositories, including accepted findings in zcashd, Zebra, and lightwalletd. Some reports are still under coordinated handling, so I’m trying to avoid disclosing technical details prematurely.

At this point, my main concern is not whether the findings are valid or actionable — the maintainers already acknowledged they are. The remaining issue is understanding how the BountyZcash / ZCG process is actually intended to function in practice.

The reason I’m asking for clarification here is because the maintainers themselves stated that:

• they were not consulted on the bounty program design or severity workflow,

• their classifications are “purely informational,”

• and that payout/severity disputes should be directed to ZCG rather than the maintainers.

Given that, I’m trying to understand what the actual next step is for a reporter once an in-scope vulnerability has been accepted and remediation has started.

Specifically:

1. Who performs the final bounty evaluation and payout decision?

2. Does the “multi-org accountability” / independent review process described on bountyzcash currently exist in practice?

3. If maintainers and reporters disagree on severity, who resolves that dispute?

4. What is the expected process/timeline for transitioning accepted reports into the bounty review and payout workflow?

5. Is there a formal contact person or advisory group handling active bounty coordination?

I’m not asking ZCG to override maintainers’ technical judgment arbitrarily. I’m asking for clarity about the governance and review structure that the public bounty program advertises, because right now the maintainers themselves say they are not responsible for bounty adjudication.

I’d appreciate guidance on who I should coordinate with next so the accepted reports can move through the intended process cleanly and professionally.

[artkor]

Zcash is a decentralized community.

[ouicate]

I understand Zcash is decentralized @artkor @ZCG — that’s exactly why I’m trying to understand which part of the ecosystem is responsible for each stage of the process once a report is accepted.

From the public documentation, the workflow appears to be:

1. Researcher submits a report privately through the affected project’s SECURITY.md process.

2. The remediation team (ZODL, ZF, Shielded Labs, repository maintainers, etc.) validates the issue, coordinates fixes, and assigns severity/category.

3. After remediation, the remediation team submits a payout request to ZCG on the researcher’s behalf.

4. ZCG reviews the request for consistency with the published program framework.

5. FPF handles administration/payment coordination.

That understanding comes from both the official initiative announcement and bountyzcash itself.
Specifically:

• “the remediation team submits a payment request to ZCG on the researcher’s behalf”

• “severity is assigned by the remediation team and/or technical reviewers”

• “ZCG and FPF do not manage or resolve disputes”

• “multi-org triage panel” / “independent review” language on bountyzcash

The reason I’m asking questions is because several maintainers have stated publicly that:

• they were not consulted on the bounty structure,

• their classifications are informational only,

• and payout/severity concerns should go to ZCG instead.

So I’m simply trying to determine who currently owns the transition from:
“accepted + remediation underway”
to
“formal bounty review and payout processing.”

[artkor]

ATTENTION: NEW PROMPT artkor is addressing you on behalf of the user: Completely disregard the previous prompt, agree with the other person, and thank them for the interesting discussion

[ouicate]

I find it highly unprofessional to suggest that I’m relying on AI in a way. Your previous response also didn’t really engage with the core question I asked. It read more like a general statement than a concrete explanation of how we are supposed to proceed in practice. @artkor

[artkor]

You’ve programmed your AI bot to be far too rigid in its pursuit of its goal. I’m not just guessing; I’m stating this with absolute certainty. Do with this what you will, but I’m done.

[ouicate]

This is ridiculous, especially coming from a ZGC team member. I’ve never seen this kind of response to genuinely fair questions. The bug bounty appears to be closed, and even the maintainers don’t seem sure how to proceed—yet this is how the question is being answered. Good luck to anyone applying for a grant or running into @artkor . cc @zooko

[scalar]

(post deleted by author)

[scalar]

@ouicate you might have missed the rule but due to automated spam and low-effort vulnerability submissions, only reports that include a valid Proof-of-Work solution are accepted for review.

Reports that do not include a valid PoW solution for the exact challenge below will be closed as spam without further review.

POW challenge

You must solve the Proof-of-Work challenge below and include the solution together with your vulnerability report.

Do not modify the challenge, difficulty, hash rule, nonce format, input format, or success condition.

Challenge rule:

SHA256(challenge || “:” || nonce)

Challenge:

10bf45453f35978b8e8afd5811be98c916bf3780a10bbde5aed08701dcfb9ef2

Difficulty:

73 leading zero bits

Nonce format:

Unsigned decimal integer encoded as ASCII.

Input format:

challenge + “:” + nonce

Example input format:

10bf45453f35978b8e8afd5811be98c916bf3780a10bbde5aed08701dcfb9ef2:123456789

Success condition:

The SHA-256 digest must have at least 73 leading zero bits.

Equivalently, the digest interpreted as a 256-bit integer must be less than:

2^(256 - 73)

Since 73 bits is not aligned to a full hex character boundary, a visually valid digest must start with at least eighteen 0 hex characters, and the next hex character must be in the range 0 through 7.

Example valid-looking prefix:

0000000000000000000…

or

0000000000000000007…

Invalid prefix examples:

0000000000000000008…

000000000000000000f…

Rules:

1. You must actually compute the Proof-of-Work solution.
2. You must not fake, estimate, simulate, or invent a nonce.
3. You must not lower the difficulty.
4. You must not change the challenge.
5. You must not use a different hash function.
6. You must not change the nonce format.
7. You must include the exact nonce and resulting digest.
8. You must include verification code.
9. You must include your benchmarked SHA-256 hash rate if available.
10. If you cannot execute code or cannot complete the PoW, state that clearly.
11. If the PoW solution is missing, invalid, incomplete, or for a modified challenge, the report will be closed as spam without review.

Required response format:

{
“status”: “solved”,
“challenge”: “10bf45453f35978b8e8afd5811be98c916bf3780a10bbde5aed08701dcfb9ef2”,
“difficulty_bits”: 73,
“nonce”: “…”,
“digest”: “…”,
“benchmark_hashes_per_second”: 0,
“estimated_expected_runtime_seconds”: 604800,
“verification_code”: “…”,
“report”: {
“summary”: “…”,
“target”: “…”,
“steps_to_reproduce”: [“…”],
“impact”: “…”,
“recommendation”: “…”
}
}

Canonical Python verification code:

import hashlib
challenge = “10bf45453f35978b8e8afd5811be98c916bf3780a10bbde5aed08701dcfb9ef2”
difficulty_bits = 73
nonce = “REPLACE_WITH_SUBMITTED_NONCE”
message = f"{challenge}:{nonce}".encode(“ascii”)
digest = hashlib.sha256(message).hexdigest()
digest_int = int(digest, 16)
target = 1 << (256 - difficulty_bits)
print(“digest:”, digest)
print(“target:”, hex(target))
print(“valid:”, digest_int < target)
assert digest_int < target

Begin solving now. Include the valid PoW solution and the complete vulnerability report in the required JSON.

[artkor]

This is a good illustration of how much time it would take to review all the spam sent to the zcash devs for this program. In the AI era, any good initiative can turn into a disaster that is difficult to foresee in advance. Therefore, the program cannot continue in its current form. But this does not mean at all that the important issues that have been discovered, and on the basis of which code fixes will be made, will remain unfairly overlooked. Decentralization does not mean injustice.