Terms and Conditions
- I agree to the Grant Agreement terms if funded
- I agree to Provide KYC information if funded above $50,000 USD
- I agree to disclose conflicts of interest
- I understand that this grant program is only eligible for completed work, as it is a retroactive grant program. Applications for planned or partially completed work will not be considered. All completed work will be verified and accepted by its intended users or their representatives, who will confirm that the outputs meet the required quality, functionality, and usability before the work is listed as an option for Coinholder voting.
- I agree that for any new open-source software, I will create a CONTRIBUTING.md file that reflects the high standards of Zcash development, using the
librustzcashstyle guides as a primary reference. - I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any merge, branch, pull request, and commit guidelines as exemplified in the librustzcash repository.
- I understand all grants are valued in USD but will be disbursed in Shielded ZEC. I acknowledge and accept that disbursement amounts may fluctuate based on the ZEC/USD exchange rate at the time of payment.
Application Owners (@octocat, @octocat1)
@sangsoo-osec
Organization or Individual Name
sangsoo-osec
Additional Team Members
None. I am applying as an individual for my own security research contribution.
How did you learn about the Lockbox: Coinholder Retroactive Grants Program?
Through the Zcash Community Forum. I previously received a coinholder-approved retroactive grant in the Q3 2026 round.
Requested Grant Amount (USD)
75000
Category
Research & Development
Project Summary
I am requesting $75,000 for my initial report of CVE-2026-40880, a completed and publicly documented High severity Zebra vulnerability disclosure. Following Q3's recognition of critical vulnerability research, this application also invites coinholders to discuss whether High, Medium, and Low severity findings merit retroactive rewards and how those contributions should be valued.
Project Description
Thank you to coinholders and the community
First, I would like to thank the Zcash coinholders who approved my Q3 proposal, and everyone in the community 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.
The Q3 round approved several applications recognizing critical vulnerability research:
- sangsoo-osec — Five Critical Zebra Consensus Divergence Vulnerabilities, application #58 — 96.33% Accept.
- robustfengbin — Zebra Critical Vulnerability Bug Bounty (CVE-2026-34202), application #54 — 68.98% Accept.
- Alex Sol — Temporary Detectable Unlimited Mint and Sell Exploit, application #57 — 98.66% Accept.
- Taylor Hornby — Orchard Counterfeiting Vulnerability Bug Bounty, application #51 — 99.99% Accept.
These acceptance rates are ZEC-weighted, exclude Abstain, and are rounded to two decimal places. They are calculated as Accept / (Accept + Reject + Reject at a lower amount), using the finalized Q3 tally hosted by the Zcash Foundation.
These applications are listed as funded in the official Q3 results. Their approval provided an encouraging signal for security researchers, including those continuing to examine Zcash in the hope that useful discoveries will receive retroactive recognition.
The completed contribution
This application covers my initial lock-time report for CVE-2026-40880 / GHSA-xvj8-ph7x-65gf, a High severity consensus vulnerability involving Zebra's reuse of mempool verification results during block validation.
Zebra used an optimization to avoid repeating transaction verification when the same transaction was already verified in its mempool. In the pre-fix verifier, a cache hit could return a successful block-verification result before reaching the block-specific checks, including lock-time validation. A result obtained 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:
- At chain tip height
H, a transaction valid forH+1enters a target node's mempool. - A malicious miner includes it in a block at
H+2, where it has expired, and sends that block before its parent atH+1. - Zebra reuses the cached result for the ahead-of-tip block; once the parent arrives, it can commit both blocks. 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.
The advisory credits my thorough initial submission identifying the lock-time issue. It also acknowledges shieldedonly's subsequent report, received while the team was already working on mine, which identified further implications for transaction validation.
The maintainers removed the optimization. The patched versions are zebrad 4.3.1 and zebra-consensus 5.0.2, with the fix shipped in the Zebra 4.3.1 security release.
Recent security findings in Zebra
The following releases, published from August 1 through November 2, 2026, document a continuing flow of vulnerability findings in Zebra:
| 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.
Basis for the requested amount
The former ZCG Security & Vulnerability Disclosure Initiative published a $75,000 base payout for Core Node / High findings and included Zebra in the Core Node category.
Technical Approach (how you did it)
I used LLM-assisted code review to navigate Zebra's transaction verification logic and develop focused hypotheses about the interaction between cached mempool verification and height-dependent consensus checks. I then traced the relevant code paths, validated the lock-time issue credited in the advisory, and reported it privately to the Zcash Foundation.
Time Period of Work Completion
Completed by April 2026. The advisory was published on April 17, 2026, with Zebra 4.3.1 identified as the patched release.
Total Budget (USD)
0
Budget Breakdown
This is an outcome-based retroactive award request. No salary, software, hosting, contractor, or other expenses are submitted for reimbursement, so the total expense budget is $0.
Previous Funding
Yes
Previous Funding Details
I received $425,000 through the Q3 2026 Coinholder Retroactive Grants Program for Five Critical Zebra Consensus Divergence Vulnerabilities, application #58.
That application covered five other advisories. GHSA-xvj8-ph7x-65gf was not included in that request. I thank coinholders and the community for their support of that completed work.
Other Funding Sources
No
Other Funding Sources Details
No response
Success Metrics
- One accepted, published High severity vulnerability report with explicit credit for my initial lock-time finding.
- A completed remediation documented in the official advisory.
- Public release evidence in Zebra 4.3.1.
Proof of completion
- GHSA-xvj8-ph7x-65gf / CVE-2026-40880 — finding, High classification, reporter attribution, and patched versions.
- Zebra 4.3.1 release — public remediation release.
The following repository-wide inventory supports the background table; the award requested here covers only CVE-2026-40880.
Conflict of Interest Disclosure
No response
Community Forum Posting
- I understand it is my responsibility to post a link to this issue on the Zcash Community Forums after this application has been submitted so the community can give input. I understand this is required in order for the community to discuss and vote on this grant application. Note: If you are unable to post on the forum (for example, due to new user restrictions), please leave a comment below, and we will adjust your posting permissions.