Zcash Coinholder Grants 77: $300,000 for two reported Zebra consensus bugs

A retroactive grant application posted on 2 November 2026 by @ouicate asks the Coinholder-Directed Retroactive Grants Program for $300,000 for two consensus vulnerabilities in the Zebra full node that were reported before they shipped. The application is issue #77 in the program's GitHub repository, which the Financial Privacy Foundation (FPF) administers; coinholders, not Zcash Community Grants (ZCG), decide it. It matters twice over: it is a $300,000 request from the coinholder grant fund, and it asks coinholders to settle a precedent, whether a Critical consensus bug caught on the development branch is paid at the same rate as one found in a release.

Both findings come from the same refactor, PR #10461, which replaced Zebra's own transaction parser with the shared zcash_primitives library, was merged into main on 22 August 2026 and dropped two rules every node must enforce. The applicant reported both privately on 2 September; the Zcash Foundation (ZF) made them a release blocker, merged the fix (PR #11387) on 8 September, and shipped Zebra 6.4.0 on 23 September with both rules enforced, so no release ever carried them. Zebra 6.0.0 to 6.3.0 and Zakura v1.3.1 enforce both rules. The Critical rating is the applicant's, by reference to ZCG's severity framework and ZF's ratings for similar shipped bugs: ZF publishes ratings only in advisories for affected releases, so it published none for these.

What it changes

• The request: $300,000 USD, split into $150,000 for C-01 and $150,000 for C-02. Grants are valued in USD and paid in shielded ZEC from the program's multisig, which is funded by 12% of block rewards under ZIP 1016 plus initial capital from the Deferred Dev Fund Lockbox; grants above $50,000 require KYC checks by FPF before disbursement.
• C-01: Zebra's main branch accepted about 2.1 billion invalid nExpiryHeight values above the ZIP 203 maximum, so anyone could have split the network with one transaction, with no mining and no authentication needed.
• C-02: the coinbase scriptSig length rule of 2 to 100 bytes was no longer enforced, so any miner could have split the network with one block.
• Had either shipped, upgraded Zebra nodes would have accepted transactions and blocks that Zakura and older Zebra nodes rejected. Once a split passed Zebra's 1,000-block rollback limit, about 21 hours, ending it would have required a resync of every affected node or a hard fork.
• The pricing basis is the $150,000 Core Node Critical base for each sole-reporter consensus finding, with no bonus. The applicant points to what coinholders approved in Q3: $425,000 for five Critical Zebra consensus divergence vulnerabilities at 96.33% Accept, $400,000 for a temporary detectable unlimited mint-and-sell exploit at 98.66% Accept, and $750,000 for an Orchard counterfeiting vulnerability at 99.99% Accept.
• The Zcash Foundation added a permanent Zebra Book chapter on refactoring consensus-critical code, described as distilled from this incident, and credited the reporter in its engineering update.
• The recipient is @ouicate, applying as ouicate (Quorint), an independent researcher and the sole reporter of both findings. The application declares no conflict of interest and discloses a separate Q4 application, #78, for two other Zebra advisories, GHSA-jq45-ghw5-v37x and GHSA-3c94-hf7p-g5mf. The thread states the findings were found by using Zakura v1.3.1 as a reference for consensus divergence, with LLM-assisted code review mapping the refactor and generating leads, confirmed by hand with deterministic tests.
• The thread also notes that the ZCG bounty programme closed in May, three months before the refactor was merged, so there was no bounty route for these findings.

The case for it

The applicant states the request and its basis: "I have submitted a Q4 retroactive grant application on GitHub (#77), requesting $300,000 USD for two Critical Zebra consensus vulnerabilities that I found and privately reported before they shipped." The application describes how the fixes landed: "ZF made both findings a release blocker, merged the fix six days after my report ( PR #11387 ), and shipped Zebra 6.4.0 with both rules enforced. No release ever carried them." And he sets out the policy position the application would establish: "My answer is yes: pay them at the same rate as shipped bugs, as long as they were really headed for a release."

Where it stands

The thread had six posts as of 8 November 2026, and no decision has been made. Issue #77 is labelled Ready For Vote - All Steps Completed on GitHub. Under the Q4 2026 schedule, a mandatory review period runs from 16 November to 16 December and coinholder polling from 17 to 29 December 2026. Each proposal is voted Yes or No; a vote counts only with participation of about 420,000 ZEC, and a simple majority passes. Keyholder organizations retain a veto before and after approval.

The precedent question is the live part of the debate. @sangsoo, the reporter behind Q3 application #58 that this request uses as its pricing reference, asked: "Should bounties be paid for critical bugs found in the develop branch?" and said it could set a good precedent, while noting this is not the kind of credit usually seen on bounty platforms. The applicant's answer was to pay pre-release findings at the shipped rate, on the argument that "A discount pays researchers to wait." @sangsoo replied that it would be a terrible case to have to wait until the release is out, hoping the developers do not catch the bug, and @0x15 supported the application, noting that the Zcash Foundation's tracking issue credited @ouicate for both bugs and made the fix a release blocker.