Hello Zcash community,
First, I would like to thank the coinholders who approved my Q3 proposal, and everyone who reviewed, discussed, and supported it. I appreciate the recognition of my work and the broader message that responsibly disclosed security findings can receive meaningful support from the people whose network they help protect.
I have submitted a Q4 retroactive grant application on GitHub (#74), requesting $75,000 USD for my initial report of CVE-2026-40880 / GHSA-xvj8-ph7x-65gf, a completed High severity Zebra vulnerability disclosure.
I also see this round as a useful opportunity to discuss what criteria should guide rewards for researchers’ contributions to Zcash’s security.
Background from Q3
The Q3 round approved several applications recognizing critical vulnerability research:
- My application for five Critical Zebra consensus divergence vulnerabilities (#58) — 96.33% Accept.
- robustfengbin’s application for CVE-2026-34202 (#54) — 68.98% Accept.
- Alex Sol’s application for the temporary detectable unlimited mint-and-sell exploit (#57) — 98.66% Accept.
- Taylor Hornby’s application for the Orchard counterfeiting vulnerability (#51) — 99.99% Accept.
These percentages are ZEC-weighted acceptance rates, excluding Abstain and including both Reject options in the denominator, rounded to two decimal places. They come from the finalized Q3 tally hosted by the Zcash Foundation. All four applications are listed as funded in the official Q3 results.
Those outcomes provided an encouraging signal for researchers, including those continuing to examine Zcash in the hope that useful discoveries will receive retroactive recognition.
The vulnerability and my contribution
The issue concerned Zebra’s reuse of mempool verification results during block validation. Zebra used an optimization to avoid repeating transaction verification when the same transaction had already been verified in its mempool.
In the pre-fix verifier, a cache hit could return a successful result before reaching block-specific checks, including lock-time validation. Verification in the mempool’s context could therefore bypass checks required for the block containing the transaction.
The public advisory illustrates the broader failure with an expiry-height example:
1. At chain tip height H, a transaction valid for H+1 enters a target node’s mempool.
2. A malicious miner includes it in a block at H+2, where it has expired, and sends that block before its parent at H+1.
3. Zebra reuses the cached result for the ahead-of-tip block. Once the parent arrives, it can commit both blocks, while other nodes reject the expired transaction, creating a consensus split.
This scenario requires a malicious miner and a target with the relevant cached transaction. The advisory identifies network partitioning, service disruption, and potential double-spend attacks as consequences.
I used LLM-assisted code review to navigate the verification logic and develop focused hypotheses, then traced the relevant code paths, validated the lock-time issue, and reported it privately to the Zcash Foundation.
The maintainers removed the optimization. The patched versions are zebrad 4.3.1 and zebra-consensus 5.0.2; the fix shipped in the Zebra 4.3.1 security release. The disclosure and remediation were completed by April 2026.
Recent security findings in Zebra
For stable releases published from August 1 through November 2, 2026, Zebra’s public GHSA metadata lists the following designated patched versions:
| GHSA-designated patched release | Tag published (UTC) | Critical | High | Medium | Low | Unique GHSAs |
|---|---|---|---|---|---|---|
| v6.3.0 | 2026-08-10 | 0 | 1 | 3 | 0 | 4 |
| v6.4.2 | 2026-09-25 | 0 | 1 | 2 | 1 | 4 |
| v7.0.0 | 2026-10-22 | 0 | 5 | 2 | 0 | 7 |
| Total | 0 | 7 | 7 | 1 | 15 |
These releases show that vulnerabilities continue to be found and fixed in Zebra. This suggests that security researchers may still be hunting for bugs and preparing further disclosures. It would be useful to clarify how coinholders want to recognize such contributions.
The question for coinholders
I see this round as a good opportunity for coinholders to discuss what criteria should guide rewards for researchers’ contributions to Zcash’s security. Following Q3’s recognition of critical vulnerability research, there are several questions worth considering:
- Severity ratings: How much weight should the severity assigned by the Zebra team carry in deciding whether to reward a finding and setting the amount? Should it serve as the main basis for a reward schedule?
- Practical impact: How should coinholders weigh the case-specific risk alongside that rating, including realistic exploitation conditions, required attacker capabilities, the number of nodes or users exposed, and the potential harm?
I would welcome coinholders’ views on how to balance these considerations, whether through severity-based reference amounts, case-by-case assessments, or a combination of the two. Discussing completed, publicly verifiable contributions in this round gives the community a practical opportunity to work through those choices.
This application puts one High severity finding and a specific requested amount before coinholders as a concrete case for that discussion. Feedback on the criteria behind a decision would help researchers understand how their contributions are valued and what they may reasonably expect from future rounds.
