# Zebra Coverage-Guided Fuzzing Infrastructure **URL:** \ **Category:** Applications\ **Created:** [March 16, 2026, 12:32am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972 "2026-03-16T00:32:13Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [March 16, 2026, 12:32am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/1 "2026-03-16T00:32:13Z")
Hello everyone, I am submitting a proposal to Zcash Community Grants (ZCG) to build a coverage-guided fuzzing infrastructure for Zebra, the Zcash Foundation’s Rust consensus node implementation. This project focuses on systematically testing Zebra’s critical parsing, networking, and cryptographic components against malformed inputs, enabling continuous, automated discovery of security vulnerabilities and edge-case bugs. * * * Why This Matters Zebra currently has zero fuzzing coverage. There are no fuzz targets, no cargo-fuzz configuration, and no OSS-Fuzz registration. After NU7, Zebra becomes the sole consensus node for the entire Zcash network. Any exploitable parsing or validation bug could compromise the network’s security and user funds. For comparison, Bitcoin Core maintains a mature fuzzing infrastructure with over 100 fuzz targets and continuous OSS-Fuzz integration. Zcash, as a privacy-focused cryptocurrency, arguably requires even more rigorous testing, yet has none. * * * Project Overview This proposal introduces a complete fuzzing infrastructure for Zebra that includes: - Fuzz targets for all major attack surfaces: transaction and block deserialization, P2P protocol parsing, RPC input handling, script and address parsing, note commitment tree operations, and Equihash verification - Seed corpora extracted from Zcash mainnet real data - CI integration with PR-level smoke fuzzing and nightly extended fuzzing campaigns via GitHub Actions - OSS-Fuzz submission, enrolling Zebra in Google’s continuous fuzzing service for 24/7 automated testing - Security reporting with structured crash triage, severity classification, reproduction steps, and fix recommendations * * * Technical Approach The infrastructure is built on cargo-fuzz with the libFuzzer backend. For complex inputs, the arbitrary crate enables structured fuzzing. All targets run with AddressSanitizer and UndefinedBehaviorSanitizer for maximum bug detection. Fuzz targets are prioritized by attack surface: - P0 (Critical): Transaction deserialization (v1 through v5+), block and header parsing, P2P message parsing - P1 (High): RPC input handling, script and address parsing, note commitment tree operations - P2 (Medium): Equihash verification, Orchard and Sapling serialization * * * Deliverables and Milestones The proposal is structured into three milestones over 6 months: 1. Core Fuzzing Framework and Initial Targets — zebra-fuzz crate, 3+ fuzz targets for critical deserialization code, seed corpora from mainnet 2. Extended Targets, Corpus Optimization and CI — 7+ total fuzz targets, corpus minimization, GitHub Actions CI integration, coverage reporting 3. Security Analysis, OSS-Fuzz and Documentation — crash analysis report, OSS-Fuzz submission PR, documentation for community contributors, upstream PRs to Zebra * * * Budget - Startup Funding: $3,000 (infrastructure setup) - Milestones 1 through 3: $27,000 (engineering work) - Total: $30,000 * * * Design Principles - Standalone: independent crate, no modifications to Zebra core code required - Sustainable: OSS-Fuzz integration ensures fuzzing continues indefinitely after project completion - Community-oriented: documentation enables anyone to add new fuzz targets as Zebra evolves * * * Full proposal details are available here: > > > \### Terms and Conditions > > \- \[x\] I agree to the \[Grant Agreement\](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded > \- \[x\] I agree to \[Provide KYC information\](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD > \- \[x\] I agree to disclose conflicts of interest > \- \[x\] I agree to adhere to the \[Code of Conduct\](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and \[Communication Guidelines\](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284) > \- \[x\] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story. > \- \[x\] 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 \[\`librustzcash\` style guides\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference. > \- \[x\] 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\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), \[branch\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), \[pull request\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and \[commit\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the \`librustzcash\` repository. > \- \[x\] I agree to post request details on the \[Community Forum\](https://forum.zcashcommunity.com/c/grants/33) > \- \[x\] I understand it is my responsibility to post a link to this issue on the \[Zcash Community Forums\](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application. > > \### Application Owners (@Octocat, @Octocat1) > > robustfengbin > > \### Organization Name > > Independent Developer > > \### How did you learn about Zcash Community Grants > > The Zcash Community Forum, GitHub > > \### Requested Grant Amount (USD) > > 30000 > > \### Category > > Research & Development > > \### Project Lead > > \`\`\`project-lead.yaml > Name: robust > Role: Project Lead > Background: > Senior software engineer with over 15 years of experience building production-grade backend systems and developer tooling. > Strong background in Rust, distributed systems, and blockchain infrastructure. > Solid working knowledge of the Zcash protocol stack and practical experience with the Zebra node architecture. > Responsibilities: > \- Overall project ownership and technical direction > \- System architecture and core fuzz target design decisions > \- Crash triage, severity assessment, and security analysis > \- Review and acceptance of all milestone deliverables > \- Coordination with Zcash Community Grants reviewers and community stakeholders > \`\`\` > > \### Additional Team Members > > \`\`\`team-members.yaml > \- Name: aic-larry > Role: Rust Engineer > Background: > Experienced Rust developer with strong focus on systems programming, security testing, and fuzzing methodologies. > Prior experience building coverage-guided fuzz testing infrastructure for Rust projects. > Responsibilities: > - Fuzz target implementation and harness development > - Seed corpus extraction and corpus management > - CI/CD integration and GitHub Actions workflow configuration > - OSS-Fuzz project submission and integration > - Writing unit tests, performance benchmarks, and documentation > \`\`\` > > \### Project Summary > > Build a comprehensive coverage-guided fuzzing infrastructure for Zebra, the Zcash Foundation's consensus node implementation. This project will create systematic fuzz targets for Zebra's critical parsing, networking, and cryptographic components, integrate them into CI, and submit the project to Google's OSS-Fuzz for continuous automated fuzzing. > > \### Project Description > > Zebra is the sole consensus node implementation for the Zcash network post-NU7. Despite this critical role, Zebra currently has zero fuzzing infrastructure — no \`fuzz/\` directory, no \`cargo-fuzz\` integration, and no presence in Google's OSS-Fuzz program. > > This project delivers a production-ready fuzzing infrastructure covering Zebra's most security-sensitive components: > > \- \*\*Transaction & Block deserialization\*\* — the primary attack surface for any blockchain node > \- \*\*P2P network protocol message parsing\*\* — exposed to untrusted network input > \- \*\*RPC interface input handling\*\* — external-facing API surface > \- \*\*Script and address parsing\*\* — complex format validation logic > \- \*\*Note commitment tree operations\*\* — critical to shielded transaction integrity > \- \*\*Equihash proof-of-work verification\*\* — consensus-critical validation > \- \*\*Orchard/Sapling serialization\*\* — privacy-layer data handling > > The infrastructure uses \`cargo-fuzz\` with the libFuzzer backend for coverage-guided fuzzing, includes corpus management, CI integration via GitHub Actions, and a structured crash triage and reporting workflow. > > \### Proposed Problem > > Zebra has no systematic fuzzing, despite being the only Zcash consensus node after NU7. > > Key concerns: > > 1. Zero fuzzing coverage: Zebra's repository contains no fuzz targets, no \`cargo-fuzz\` configuration, and the project is not registered with OSS-Fuzz. A \`grep\` for \`fuzz\` in the codebase confirms the complete absence of fuzzing infrastructure. > > 2. Single point of failure: After NU7, Zebra becomes the sole consensus node for the entire Zcash network. Any exploitable parsing or validation bug could compromise the network's security and user funds. > > 3. Industry standard gap: Bitcoin Core maintains a mature fuzzing infrastructure with 100+ fuzz targets and continuous OSS-Fuzz integration. Zcash, as a privacy-focused cryptocurrency handling shielded transactions, arguably requires \*more\* rigorous testing — yet has none. > > 4. Complementary to audits: Least Authority has conducted code audits of Zebra, but audits and fuzzing serve fundamentally different purposes. Audits are point-in-time human reviews; fuzzing provides continuous, automated discovery of edge cases that human reviewers miss. These approaches are complementary, not redundant. > > 5. ZCG priority alignment: The ZCG Wishlist explicitly includes "Audits for updated Zcash software." Fuzzing is the most cost-effective form of continuous security testing and directly supports this priority. > > > \### Proposed Solution > > A systematic, coverage-guided fuzzing infrastructure for Zebra that: > > 1. Targets high-risk attack surfaces — Prioritizes components that process untrusted input: deserialization, network protocol parsing, and RPC handling. > > 2. Uses industry-standard tooling — Built on \`cargo-fuzz\` (libFuzzer backend), the de facto standard for Rust fuzzing, ensuring compatibility with the broader ecosystem. > > 3. Manages corpora intelligently — Seeds initial corpora from real network data (valid transactions, blocks, protocol messages) and accumulates coverage-expanding inputs over time. > > 4. Integrates into CI — GitHub Actions workflows run fuzzing on every PR and perform extended nightly fuzzing runs, catching regressions before they reach production. > > 5. Submits to OSS-Fuzz — Google's free, continuous fuzzing service will provide 24/7 fuzzing with automatic bug filing and disclosure management. > > 6. Produces actionable security reports — Every crash is triaged, deduplicated, and reported with reproduction steps, severity assessment, and suggested fixes. > > \### Solution Format > > Deliverables: > > \- Rust crate: \`zebra-fuzz\` — a standalone crate within the Zebra workspace containing all fuzz targets, corpus seeds, and helper utilities > \- CI configuration: GitHub Actions workflows for PR-level and nightly fuzzing > \- \*\*OSS-Fuzz integration: Project configuration and Dockerfiles for submission to Google's OSS-Fuzz > \- Security reports: Detailed crash analysis reports with reproduction cases and severity ratings > \- Documentation: Guide for adding new fuzz targets, running fuzzing locally, and interpreting results > > > \### Dependencies > > This project has no dependencies on the Zebra core team. All work is based on the public Zebra repository and uses Zebra's existing public APIs and data structures. We will submit upstream PRs but do not require core team involvement to complete deliverables. > > \### Technical Approach > > The project adopts a layered architecture designed for modularity, maintainability, and extensibility. > > \### Fuzzing Framework > > The infrastructure is built on \`cargo-fuzz\` with the libFuzzer backend for coverage-guided fuzzing. For modules where raw byte mutation is insufficient (e.g., structured protocol messages), we use the \`arbitrary\` crate for structured fuzzing. Coverage instrumentation is provided by LLVM's SanitizerCoverage. > > \### Fuzz Target Design > > Each fuzz target acts as a thin harness that feeds mutated input data into Zebra's parsing and validation functions. The harness captures panics, memory errors, and unexpected behavior. For simple deserialization targets, raw byte streams are fed directly into Zebra's \`zcash\_deserialize\` methods. For complex inputs such as network protocol messages, structured fuzzing generates well-formed but edge-case inputs that exercise deeper code paths. > > \### Target Modules (Priority Order) > > Fuzz targets are organized by attack surface priority: > > \- \*\*P0 — Critical (untrusted network data)\*\*: Transaction deserialization (all versions v1–v5+), block deserialization and header parsing, P2P network protocol message parsing > \- \*\*P1 — High (external-facing)\*\*: RPC interface input handling, script and address parsing (transparent and shielded), note commitment tree insert/remove operations > \- \*\*P2 — Medium (consensus/privacy layer)\*\*: Equihash proof-of-work solution verification, Orchard/Sapling serialization and deserialization > > \### Corpus Management > > Seed corpora are extracted from Zcash mainnet data — real transactions, blocks, and protocol messages — providing the fuzzer with realistic starting inputs. Corpus minimization is performed regularly to maintain efficient test sets while preserving maximum code coverage. A regression corpus is preserved for all discovered crashes to prevent regressions in future builds. > > \### CI Integration > > GitHub Actions workflows provide two levels of fuzzing integration: > > \- \*\*PR-level smoke fuzzing\*\*: Short fuzzing runs on each pull request to catch obvious regressions before merge > \- \*\*Nightly extended fuzzing\*\*: Multi-hour fuzzing campaigns across all targets, running overnight to maximize coverage exploration > > \### Sanitizers > > All fuzz targets run with AddressSanitizer (ASan) for memory safety violation detection and UndefinedBehaviorSanitizer (UBSan) for catching undefined behavior in unsafe code blocks. > > \### Upstream Merge Opportunities > > > All deliverables are designed for upstream integration into the main Zebra repository: > > \- \`zebra-fuzz\` crate can be added as a workspace member > \- CI workflows follow Zebra's existing GitHub Actions patterns > \- OSS-Fuzz integration requires a one-time PR to the \`google/oss-fuzz\` repository > \- Fuzz targets serve as living documentation of expected input formats > > We will submit upstream PRs for all deliverables and work with maintainers on review. > > \### Hardware/Software Costs (USD) > > 3000 > > \### Hardware/Software Justification > > Infrastructure & Environment ($2,000) > > \- Cloud compute instances for extended fuzzing campaigns (6 months) > \- Zebra node deployment for seed corpus extraction > \- Storage for chain data, corpora, and crash artifacts > > CI/CD ($700) > > \- CI/CD pipeline configuration and compute > \- Automated nightly fuzzing execution > \- Reproducible build environment for fuzz targets > > Development Environment ($300) > > \- Local development environment setup > \- Debugging, profiling, and coverage analysis tools > > \### Service Costs (USD) > > NO > > \### Service Costs Justification > > NO > > \### Compensation Costs (USD) > > 27000 > > \### Compensation Costs Justification > > Compensation covers engineering work over a 6-month period for a two-person team. > > \- \*\*Project Lead (robust)\*\*: System architecture, core fuzz target design, crash triage and security analysis, code reviews, documentation, and coordination with ZCG. > \- \*\*Rust Engineer (aic-larry)\*\*: Fuzz target implementation, corpus management, CI integration, OSS-Fuzz submission, and performance optimization. > > Compensation is distributed evenly across milestones ($9,000 per milestone), with early milestones focusing on core infrastructure to reduce risk, followed by analysis and documentation in later phases. > > \### Total Budget (USD) > > 30000 > > \### Previous Funding > > No > > \### Previous Funding Details > > NO > > \### Other Funding Sources > > No > > \### Other Funding Sources Details > > \_No response\_ > > \### Implementation Risks > > Zebra API Isolation Complexity > > Some Zebra internal APIs may be tightly coupled, making it difficult to fuzz individual components in isolation. > > Mitigation: Use structured fuzzing with the arbitrary crate to generate well-typed inputs; create thin wrapper harnesses that isolate target functions from their dependencies. > > Low Crash Yield Due to Rust Memory Safety > > Rust's ownership model and memory safety guarantees may result in fewer crashes compared to C/C++ codebases. > > Mitigation: Focus on logic bugs, panics, resource exhaustion, and infinite loops rather than memory corruption. Use AddressSanitizer and UndefinedBehaviorSanitizer for unsafe code blocks where memory issues are still possible. > > Upstream PR Acceptance Timeline > > Submitted PRs to the Zebra repository may not be reviewed or merged within the project timeline. > > Mitigation: All deliverables are designed to function as a standalone fork. Upstream merge is a bonus outcome, not a blocker for milestone completion. > > Zebra Codebase Evolution > > Zebra's internal APIs may change during the 6-month project period. > > Mitigation: Track Zebra's main branch weekly; design fuzz targets against stable public APIs and deserialization interfaces that are unlikely to change. > > \### Potential Side Effects > > False Sense of Security > Users may assume fuzzing catches all bugs, reducing manual review effort. > Mitigation: Clear documentation that fuzzing is complementary to audits, not a replacement. Emphasize coverage limitations in security reports. > > Noise from Non-Critical Findings > Fuzzing may surface panics or edge cases that are not security-relevant, creating noise for maintainers. > Mitigation: Crash triage process with severity classification; only report confirmed security-relevant findings to maintainers; maintain separate tracking for low-priority issues. > > \### Success Metrics > > Functional Completeness > > \- All planned fuzz targets operational with coverage-guided feedback > \- Seed corpora extracted and validated from mainnet data > \- CI integration running on every PR and nightly > > Security Impact > > \- Number of unique crashes discovered and categorized by severity > \- Number of bugs reported to Zebra maintainers > \- Code coverage percentage achieved across target modules > > Community Adoption > > \- OSS-Fuzz PR submitted and accepted > \- Upstream PRs submitted to Zebra repository > \- Documentation enables community contributors to add new fuzz targets independently > > > \### Startup Funding (USD) > > 3000 > > \### Startup Funding Justification > > Startup funding covers essential infrastructure required to begin development and is included within the total requested grant amount. > > Primary uses: > > \- Cloud environment initial setup for fuzzing campaigns > \- Zebra node deployment for seed corpus extraction > \- CI/CD pipeline configuration > \- Initial storage allocation for corpora and artifacts > > \### Milestone Details > > \`\`\`milestones.yaml > Milestone 1 — Core Fuzzing Framework & Initial Targets > \- Amount (USD): $9,000 > \- Expected Completion Date: Month 2 > > User Stories > \- As a security researcher, I want systematic fuzz targets for Zebra's critical deserialization code > \- As a Zebra maintainer, I want automated detection of parsing bugs in transaction and block handling > \- As a node operator, I want assurance that network protocol parsing is tested against malformed inputs > > Deliverables > \- zebra-fuzz crate scaffolding with cargo-fuzz integration > \- Fuzz targets for transaction deserialization (all versions v1–v5+) > \- Fuzz targets for block deserialization and header parsing > \- Fuzz targets for P2P network protocol message parsing > \- Initial seed corpora extracted from Zcash mainnet data > \- Local fuzzing runner scripts and developer documentation > \- Preliminary crash triage for any findings > > Acceptance Criteria > \- 3 fuzz targets running with coverage-guided feedback > \- Seed corpora seeded from real mainnet data > \- Setup instructions documented and verified > \- Any discovered crashes triaged and reported > > Milestone 2 — Extended Targets, Corpus Optimization & CI > \- Amount (USD): $9,000 > \- Expected Completion Date: Month 4 > > User Stories > \- As a security researcher, I want comprehensive fuzzing coverage across all major Zebra attack surfaces > \- As a Zebra maintainer, I want CI integration that catches regressions automatically on every PR > \- As a developer, I want coverage metrics to understand which code paths are being tested > > Deliverables > \- Additional fuzz targets for RPC interface input handling > \- Fuzz targets for script and transparent/shielded address parsing > \- Fuzz targets for note commitment tree insert/remove operations > \- Fuzz targets for Equihash solution verification > \- Corpus optimization: minimization, deduplication, coverage analysis > \- GitHub Actions CI integration (PR-level smoke fuzzing and nightly extended runs) > \- Coverage reporting dashboard > > Acceptance Criteria > \- 7+ fuzz targets operational > \- CI pipelines running on PRs and nightly > \- Corpus coverage metrics tracked and reported > \- Corpus minimized and deduplicated > > Milestone 3 — Security Analysis, OSS-Fuzz & Documentation > \- Amount (USD): $9,000 > \- Expected Completion Date: Month 6 > > User Stories > \- As a Zebra maintainer, I want a comprehensive security report detailing all findings > \- As a community member, I want Zebra enrolled in OSS-Fuzz for continuous automated fuzzing > \- As a developer, I want documentation to add new fuzz targets as Zebra evolves > > Deliverables > \- Comprehensive crash analysis report with severity classifications > \- Reproduction steps for each finding > \- Suggested fixes and patches where applicable > \- OSS-Fuzz project submission (Dockerfile, build configuration, PR to google/oss-fuzz) > \- Final documentation (adding fuzz targets guide, corpus management, security recommendations) > \- Upstream PRs submitted to Zebra repository > > Acceptance Criteria > \- Security report delivered with all findings categorized > \- OSS-Fuzz PR submitted > \- All documentation complete and reviewed > \- Upstream PRs opened for Zebra repository > > Total Budget (USD): $30,000 > \- Startup Funding: $3,000 > \- Milestones (1-3): $27,000 > \- Total: $30,000 > \`\`\` > > \### Supporting Documents > > \`\`\`files.yaml > > \`\`\` Thank you for your time and feedback. ---
**Author:** ![Marek](https://avatars.discourse-cdn.com/v4/letter/m/b2d939/32.png) [@Marek](https://forum.zcashcommunity.com/u/Marek)\ **Post date:** [March 20, 2026, 2:22pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/2 "2026-03-20T14:22:17Z")
I’m supportive of this grant. ---
**Author:** ![alchemydc](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/alchemydc/32/16230_2.png) [@alchemydc](https://forum.zcashcommunity.com/u/alchemydc)\ **Post date:** [March 23, 2026, 5:13pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/3 "2026-03-23T17:13:17Z")
Hi all, I reviewed this proposal and am **supportive** , with a few concerns I’d like the committee and proposer to address. ### What I Like **Right tool, right scope.** The technical approach is sound. `cargo-fuzz` with libFuzzer is the standard Rust fuzzing toolchain, and the phased milestone structure and $30K budget are reasonable for the scope of work. **OSS-Fuzz submission is the highest-value deliverable.** If accepted, Google provides 24/7 continuous fuzzing at zero ongoing cost to the ecosystem. This is where the long-term ROI lives. ### Concerns **Proposer credibility gap on fuzzing specifically.** The proposer’s GitHub shows meaningful Rust experience, but I found no public evidence of fuzzing work. No fuzz targets, no crash triage, no OSS-Fuzz contributions. I also could not locate a GitHub profile for the co-proposer (aic-larry), who is listed as the primary implementer. The proposer appears to be using Claude Code (based on `CLAUDE.md` in their pinned repo), which is fine for development but makes it harder to evaluate their independent depth on security analysis and crash triage. **OSS-Fuzz acceptance is not guaranteed, and that changes the value equation.** Google’s bar for inclusion is high. Projects must have a significant user base or be critical to global IT infrastructure. If Zebra is not accepted, the fuzzing infrastructure still has value, but becomes a material ongoing cost center (CI compute, corpus maintenance, someone to monitor and triage results). **I’d recommend ZCG structure payment so that a meaningful portion of milestone 3 funding is gated on OSS-Fuzz submission acceptance** , giving the proposers strong incentive to build a compelling case for inclusion. **Crash triage and severity assessment need more detail.** Fuzzing safe Rust code will likely surface many panics and edge cases that are not security-critical. These are still worth fixing, but someone needs to distinguish “consensus node crashes on malformed input from an adversarial peer” from “unreachable panic in a rarely-exercised code path.” It’s not clear to me that the team has experience making these determinations in a consensus-node context. I’d like to see the proposer describe their triage framework and, ideally, point to prior experience assessing bug severity. ### Recommendations 1. **Request a proof-of-concept** : A single working fuzz target against Zebra’s transaction deserialization, before full grant approval. This would materially de-risk the grant. 2. **Require a GitHub profile or portfolio for aic-larry** so the committee can vet the primary implementer. 3. **Gate a portion of milestone 3 on OSS-Fuzz acceptance** to align incentives with the proposal’s highest-value deliverable. The proposer obviously can’t control Google’s decision here, but the committee can align incentives such that the proposer makes a compelling case for inclusion in the OSS-Fuzz program. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [March 24, 2026, 6:39am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/4 "2026-03-24T06:39:23Z")
Hi alchemydc, thank you for the thoughtful feedback and support. I want to address your concerns — and share an important update. **Update first:** Since posting our proposal, we’ve continued our PoC work and our deep fuzzing methodology has already uncovered a security issue that we’ve reported to the Zcash Foundation through Zebra’s official responsible disclosure process (GitHub Security Advisory, per Zebra’s SECURITY.md). We can’t share details until the disclosure process completes, but we believe this early finding validates both our approach and our team’s ability to deliver real security value. Now to your specific points: **1. Team experience and aic-larry** aic-larry has been my long-term Rust development partner. We’ve built production cryptocurrency trading systems together — market-making and arbitrage on Binance Futures, Hyperliquid, Lighter, and Uniswap. These are systems handling real capital where bugs mean real losses, so code correctness and security are ingrained in how we work. Due to the commercially sensitive nature of quantitative trading, these projects live in private repositories — standard practice in this industry. On the AI tooling question (CLAUDE.md in our repo): yes, we use AI assistants as part of our development workflow. We see this as a strength, not a weakness — AI-assisted fuzzing harness design and code path analysis significantly accelerates our work. The security judgment, methodology design, and responsible disclosure process are all human-driven. Rather than profiles, I’d point to results: our deep fuzzing approach found a reportable security issue within the first day of deploying our new multi-layer harness methodology. That’s what matters. **2. OSS-Fuzz and M3 funding** Fair concern. We propose splitting M3 ($9,000): - **$6,000 (fixed)**: Complete OSS-Fuzz integration PR (fuzz targets, Dockerfile, project.yaml), standalone CI fuzzing pipeline, curated seed corpus, and documentation. This is real engineering work regardless of Google’s decision. - **$3,000 (conditional)**: Released upon Google’s acceptance. Either way, we commit to maintaining continuous fuzzing infrastructure. If OSS-Fuzz declines, we’ll run equivalent continuous fuzzing on dedicated servers (cost ~$500/6 months). The Zcash community gets continuous fuzzing regardless — OSS-Fuzz acceptance just means Google subsidizes the compute. **3. Crash triage process** Here’s our workflow, which we’ve now battle-tested with a real finding: **Severity levels:** - **Critical** : Remotely exploitable, affects consensus or network availability - **High** : Node crash or denial of service - **Medium** : Non-security logic errors - **Low** : Edge cases not affecting production **Process:** 1. **Discovery** — Fuzzer flags crash, triggering input automatically preserved 2. **Reproduction** — Minimize test case (`cargo fuzz tmin`), confirm stable reproduction 3. **Classification** — Determine severity, analyze attack reachability (can this be triggered remotely? via P2P? via RPC?) 4. **Reporting** — Critical/High: private disclosure to ZF security team within 24 hours. Medium/Low: public GitHub issue 5. **Documentation** — Each report includes: minimized input, stack trace, impact analysis, reachability assessment, and suggested fix 6. **Fix assistance** — Patch suggestions + verification 7. **Disclosure** — 90-day responsible disclosure window We’ve now executed this entire pipeline end-to-end — from fuzzer discovery through reachability analysis to responsible disclosure — on a real finding. Not a hypothetical workflow anymore. **PoC progress:** Beyond the security finding (details embargoed), our Phase 1 numbers: - 95.6 million iterations across 6 targets, zero crashes in standard (Layer 1) fuzzing - Multi-layer deep fuzzing methodology: we go beyond “does it deserialize without panicking” to test property access, hash computation, consensus checks, and fee calculations on deserialized objects - Real mainnet data as seed corpus (1,565 transactions + 473 blocks from a fully-synced Zebra node) - Running across multiple machines (2-core GCP + 8-core dedicated server), with up to 52x performance scaling The key insight: traditional deserialize-only fuzzing (Layer 1) ran 95M+ iterations and found nothing. Our multi-layer approach found a reportable issue within minutes of deployment. This is the methodological contribution we’re bringing. Looking forward to the committee’s feedback. ---
**Author:** ![alchemydc](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/alchemydc/32/16230_2.png) [@alchemydc](https://forum.zcashcommunity.com/u/alchemydc)\ **Post date:** [March 26, 2026, 1:46pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/5 "2026-03-26T13:46:01Z")
Thanks @robustfengbin for the follow-up. I can confirm that the bug that you found and reported responsibly in Zebra was 1) serious and 2) remotely exploitable. Indeed this validates your approach, methodology and triage capabilities. Bravo! I appreciate your commitment to M3 and doing the work to get GOOG to accept the project, as well as doing 6 months worth of fuzzing independently of acceptance into the GOOG program. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [March 27, 2026, 1:11am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/6 "2026-03-27T01:11:04Z")
Thank you @alchemydc — this confirmation means a lot, both as validation of our methodology and as encouragement going forward. The responsible disclosure process with ZF was smooth and professional. From report to hotfix, the turnaround was impressive, and we appreciate the team’s responsiveness. Looking forward to continuing this collaboration. 🙏 ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [March 27, 2026, 2:05pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/8 "2026-03-27T14:05:30Z")
@thejohnnycrypto Thanks, really appreciate this perspective. I fully agree that fuzzing coverage on a consensus-critical node like Zebra is essential. The deserialization panic we found is exactly the kind of issue that can hide in edge cases and only surface under adversarial inputs. Our goal with this proposal is not just to find isolated bugs, but to build a continuous fuzzing and triage pipeline that provides long-term security assurance for the ecosystem. Really glad to see the community recognizing the importance of this work. ---
**Author:** ![shieldedmark](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shieldedmark/32/36509_2.png) [@shieldedmark](https://forum.zcashcommunity.com/u/shieldedmark)\ **Post date:** [March 27, 2026, 3:57pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/9 "2026-03-27T15:57:31Z")
It’s not zero fuzzing! [Ziggurat](https://github.com/runziggurat/), which I did during my time at Equilibrium Labs fuzzed the network layer and found several critical-but-now-fixed vulns. cc @olliten @JoakimEQ ---
**Author:** ![conradoplg](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/conradoplg/32/42878_2.png) [@conradoplg](https://forum.zcashcommunity.com/u/conradoplg)\ **Post date:** [March 27, 2026, 4:58pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/10 "2026-03-27T16:58:54Z")
Finding a critical bug was an excellent way to market your proposal 😆 I support this! ---
**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\ **Post date:** [March 30, 2026, 1:20pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/11 "2026-03-30T13:20:31Z")
@robustfengbin at the most recent meeting, ZCG voted to approve this proposal. Congratulations! To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread. Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [March 30, 2026, 2:13pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/12 "2026-03-30T14:13:15Z")
Thank you ZCG for the approval! I’m excited to get started and grateful for the community’s trust. I’ll begin work on Milestone 1 immediately and provide monthly progress updates in this thread as requested. Looking forward to delivering meaningful security improvements for Zebra and the Zcash ecosystem. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [May 2, 2026, 6:50am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/13 "2026-05-02T06:50:06Z")
### M1 Month 1 — Coverage detail + disclosure follow-up Two finer-grained pieces of evidence from the closed Month 1 window (2026-03-30 → 2026-04-30): a per-target coverage breakdown for the five fuzz harnesses, and a short coordinated-disclosure follow-up. M1 Month 2 (May) is the harden + ship window and is in progress; the M1 final delivery report will be posted ahead of the **2026-05-30** sign-off. * * * #### 1. Coverage snapshot — 5 fuzz targets Per-target line coverage at the close of Month 1, measured with `cargo fuzz coverage` against each target’s corpus and aggregated via `llvm-cov report`. ![coverage-snapshot-may-2026](https://global.discourse-cdn.com/zcash/original/3X/b/c/bca097ba259975f7f856244fbaf9b3d9c9f1385d.png) (Same data in text form for screen readers.) | Target | Corpus files | Key file | Line coverage | | --- | --- | --- | --- | | `block_deserialize` | 1,494 | `zebra-chain/src/block/serialize.rs` | **64.38%** | | `block_deep_fuzz` | 353 | `zebra-chain/src/block/serialize.rs` | **64.38%** | | `p2p_message_parse` | 283 | `zebra-network/src/protocol/external/codec.rs` | **32.85%** | | `p2p_deep_fuzz` | 344 | `zebra-network/src/protocol/external/codec.rs` | **35.48%** | | `addr_message_fuzz` | 16 | `zebra-network/src/protocol/external/addr/v1.rs` | corpus expansion in flight | **Block deserialization — coverage on key zebra-chain files:** | File | Lines | Line coverage | | --- | --- | --- | | `zebra-chain/src/transaction/serialize.rs` | 828 | **83.45%** | | `zebra-chain/src/sapling/output.rs` | 123 | **83.74%** | | `zebra-chain/src/orchard/action.rs` | 62 | **87.10%** | | `zebra-chain/src/sapling/spend.rs` | 147 | **74.83%** | | `zebra-chain/src/orchard/note/nullifiers.rs` | 22 | **77.27%** | | `zebra-chain/src/serialization/compact_size.rs` | 116 | **81.03%** | | `zebra-chain/src/serialization/zcash_deserialize.rs` | 106 | 57.55% | | `zebra-chain/src/serialization/zcash_serialize.rs` | 96 | 53.12% | | `zebra-chain/src/serialization/read_zcash.rs` | 36 | 50.00% | | `zebra-chain/src/block/serialize.rs` | 160 | 64.38% | A note on `block/serialize.rs`: the residual ~36% un-covered region is composed mostly of the `CountedHeader` serialize/deserialize impls (used by P2P “headers”-only messages, not on the `block_deserialize` fuzz path) and the `SerializedBlock` conversion `impl`s (the serialize direction; this target only exercises deserialize). These regions are unreachable from `Block::zcash_deserialize` regardless of corpus or fuzz duration — they need a separate ser-direction target, which is a Month 2 hardening candidate. The block target reaches deep into transaction-internal deserialization paths because mainnet blocks embed real V5 / V4 transactions. That’s why `transaction/serialize.rs`, `sapling/output.rs`, and `orchard/action.rs` all sit at **80%+** line coverage from the block target alone. * * * #### 2. Coordinated disclosure update While preparing M1 Month 2 work, we identified a panic in Zebra’s V6 transaction hash path that was reachable through a recently exercised code path. We submitted the report through the standard GitHub Security Advisory workflow on the Zebra repository. The Zebra Foundation security team triaged the report promptly, then converted it to a public tracking issue with **High** severity and the appropriate `C-bug` / `S-needs-triage` labels. We would like to thank **@conradoplg** and the Zebra Foundation security team for the **rapid and constructive triage** — initial submission to public tracking inside one working day. * * * #### 3. Where this leaves M1 going into the final stretch Month 2 is the consolidation window: - Hardening of the existing targets and corpus seeding for the queued candidates - Initial CI smoke scaffold (M2 deliverable preparation) - Upstream re-baselining - M1 final delivery report ahead of the **2026-05-30** sign-off All scope and quality remain anchored to the proposal verbatim deliverables and acceptance criteria. Thanks again to ZCG, the Zebra Foundation, and the broader Zcash community for the support and the responsive coordination on disclosure. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [May 29, 2026, 3:27pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/14 "2026-05-29T15:27:31Z")
# Milestone 1 — Final delivery With the 2026-05-30 sign-off approaching, here is the Milestone 1 close-out for the Zebra Coverage-Guided Fuzzing Infrastructure grant. The full code, seed corpus, and reproduction scripts are now published on GitHub (link below) — this post is the summary; anyone who wants the per-file detail can clone the repository and reproduce everything in a few minutes. ## Fuzz targets & coverage The five Milestone 1 fuzz targets are complete and running under `cargo-fuzz` (libFuzzer + AddressSanitizer), covering Zebra’s core untrusted-input surface: - **`block_deserialize`** — block parsing + merkle-root / hash / coinbase-height invariants - **`block_deep_fuzz`** — 4-layer block fuzz reaching the consensus-validation layer - **`p2p_message_parse`** / **`p2p_deep_fuzz`** — P2P codec framing + multi-message decode - **`addr_message_fuzz`** — application-layer Addr handling On the security-critical deserialization surface — the code an attacker reaches with malformed serialized data — region coverage is **77–89%** (transaction 85%, transparent 86%, sapling 84%, orchard 89%, nullifiers 77%). Entry/parser layers (the P2P codec, the outer block parser) read lower by nature for decode-oriented fuzzing. Every figure reproduces against the published repository via the included `run-coverage.sh`, which replays the committed corpus — no long fuzzing run required. ## Bugs found & disclosed During Milestone 1 our coverage-guided fuzzing surfaced a **V6 transaction hash panic** (issue **#10534** ): a crafted V6 transaction passes deserialization but then panics while computing its transaction ID, on a path reachable from P2P message decode before consensus checks run. It only affects nodes built with the `nu7` + `tx_v6` feature flags, which are not enabled in production builds, so it is **not currently exploitable** — we caught it ahead of the NU7 release and coordinated-disclosed it to the Zcash Foundation, where it is tracked as public issue #10534. ## Code The Milestone 1 fuzzing code is published here: **[GitHub - robustfengbin/zebra-fuzz-m1: Milestone 1 of ZCG "Zebra Coverage-Guided Fuzzing Infrastructure" — five cargo-fuzz targets, committed seed corpus, coverage-reproduction scripts, built against ZcashFoundation/zebra main · GitHub](https://github.com/robustfengbin/zebra-fuzz-m1)** It ships the five fuzz targets, the committed seed corpus (16,180 real mainnet-derived inputs, ~134 MB), and the coverage-reproduction scripts, built against `ZcashFoundation/zebra` `main`. The repository is deliberately trimmed to the crates needed to build and reproduce the targets — this keeps the deliverable focused and lets reviewers diff the retained Zebra crates against upstream to confirm the only changes are the two fuzzing feature gates. The five targets themselves are not reduced in scope; they span the full core attack surface listed above. ## What’s next Milestone 2 extends to the proposal’s wider target set (RPC interface, script and address parsing, note-commitment trees, Equihash verification) along with corpus optimization and CI integration. A Month 2/3 progress update will follow in this thread. Thanks again to ZCG, the Zcash Foundation security team, and the community for the continued review and engagement. Happy to answer questions or walk through reproduction. ![aaa](https://global.discourse-cdn.com/zcash/original/3X/b/9/b9a25df9f2494e6ca2dd4dffb30a2f0fe9b57cba.png) ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [June 17, 2026, 12:49pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/15 "2026-06-17T12:49:52Z")
Hi ZCG team, Zebra maintainers, and Zcash community, I’m happy to share the delivery for Milestone 2 of the Zebra coverage-guided fuzzing grant. # Milestone 2 Building on Milestone 1, this milestone delivers the second set of coverage-guided fuzz targets for Zebra, together with continuous-fuzzing infrastructure on GitHub Actions and a public, auto-updating coverage dashboard. ## Deliverables (all complete) **1. RPC interface input handling** — `rpc_handler_fuzz` and `jsonrpsee_envelope_fuzz`, exercising `zebra-rpc`’s `methods.rs` (34% region coverage). **2. Script & transparent/shielded address parsing** — `script_verify_fuzz` and `script_flag_matrix_fuzz` drive transparent-script verification through the `zcash_script` C/C++ library via FFI (sanitizer-coverage does not instrument the C side, so these provide crash detection rather than Rust region coverage); `address_fuzz` drives `transparent/address.rs` (63% region coverage). **3. Note-commitment tree insert/remove** — `note_commitment_tree_fuzz`, exercising `orchard/tree.rs` (54% region coverage). **4. Equihash solution verification** — `equihash_fuzz`, exercising `work/equihash.rs` (65% region coverage). That is **7 new operational targets** , meeting the proposal’s “7+ targets” criterion and covering the full deliverable family. Combined with Milestone 1’s 5 block/P2P-deserialization targets, the suite now runs **12 targets** in one cumulative repository. ## Continuous fuzzing (ClusterFuzzLite on GitHub Actions) - **Pull-request** fuzzing — short code-change runs with AddressSanitizer + SARIF output - **Batch** fuzzing every 6 hours — accumulates newly-discovered inputs into the corpus - **Daily** coverage report + corpus pruning ## Coverage Per-subject-under-test region coverage is reported per source file. (A whole-report total is not meaningful here — it averages in the Rust standard library and every third-party dependency, none of which the fuzzers target.) Beyond the headline files above, \*\*90+ Zebra source files are exercised at ≥5% region coverage\*\*. These are seed-corpus baselines and grow with sustained fuzzing. **No crashes found to date** across the 12 targets. ## Corpus The seed corpus is **mainnet-derived public data** — real blocks, transactions, headers and P2P messages dumped from a fully-synced Zcash node — plus a small set of hand-constructed protocol seeds. The CI corpus accumulates and is periodically pruned/minimized. ## Repositories (public, fully reproducible) - **Fuzzing suite & harnesses:** [GitHub - robustfengbin/zebra-fuzz-m2: Continuous fuzzing suite for the Zebra Zcash node — 12 libFuzzer targets, mainnet-derived corpus, ClusterFuzzLite CI with coverage dashboard. · GitHub](https://github.com/robustfengbin/zebra-fuzz-m2) - **Corpus & live coverage dashboard:** [Zebra Fuzzing — Coverage Overview](https://robustfengbin.github.io/zebra-fuzz-m2-corpus/) The vendored crates are upstream Zebra v5.0.0, byte-identical except for two fuzzing-only `cfg` gates that expose otherwise-private modules to the harnesses. Anyone can clone, build and run (`cargo +nightly fuzz build/run --fuzz-dir zebra-fuzz/fuzz `), and the coverage report rebuilds automatically every night in CI. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [July 23, 2026, 5:34pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/16 "2026-07-23T17:34:47Z")
Hi ZCG team, Zebra maintainers, and Zcash community, I’m happy to share the delivery for Milestone 3 of the Zebra coverage-guided fuzzing grant. # Milestone 3 — Final Delivery Milestone 3 completes the grant. Building on the M1 (block / P2P deserialization) and M2 (RPC / script / address / note-commitment-tree / Equihash) targets, this milestone: 1. **rebases the entire suite onto the latest Zebra** (v6.2.1, NU6.3 “Ironwood”), 2. **adds dedicated fuzzing for the new Ironwood shielded pool** , and 3. **packages Zebra for OSS-Fuzz** while keeping continuous fuzzing running on GitHub Actions. The suite now runs **15 targets** in one cumulative, reproducible repository, with **no crashes found** across all of them on the latest consensus code. ## Rebased onto the latest Zebra (NU6.3 “Ironwood”) The 12 M1+M2 targets have been moved from v5.0.0 up to **v6.2.1** , recompiled and re-run. The continuous-fuzzing infrastructure therefore now exercises the **current consensus code**, including the NU6.3 changes, rather than a frozen older release. The vendored crates are byte-identical to upstream Zebra except for two fuzzing-only `cfg` gates that expose otherwise-private modules to the harnesses. ## New: Ironwood shielded-pool fuzzing NU6.3 introduces the **V6 transaction format** , the **Ironwood shielded pool** , and its note-commitment tree — a brand-new attack surface reachable from untrusted peer input. Milestone 3 adds three targets that reach it progressively: - **`v6_transaction_fuzz`** — V6 wire (de)serialization and round-trip. This is the highest-value, lowest-level surface: exactly the bytes a peer puts on the wire. - **`v6_transaction_semantic_fuzz`** — drives the _business logic_ on a decoded transaction: Ironwood accessors, value-balance arithmetic (including the consensus non-negativity rule), flag validation, and the structural consensus checks — all pure `fn(&Transaction) -> Result` predicates. - **`ironwood_value_balance_codec_fuzz`** — round-trips the 48-byte Ironwood `ValueBalance` state encoding. Together these exercise the Ironwood **parsing surface plus the semantic / structural consensus surface **— roughly** 70% of the pool’s business methods**. The remainder (note-commitment-tree state wiring, history-tree MMR, and the halo2 proof verification) requires block-level and async harnesses and is documented as follow-on scope rather than claimed as covered. All three targets ran to **zero crashes**. ## Corpus for a not-yet-activated format NU6.3 is not yet active on mainnet, so there is no ready-made corpus of real V6 transactions — and random bytes essentially never land inside the V6 structure. The seed corpus draws on three sources: - **A dedicated `fake_v6` generator** that uses Zebra’s own `fake_v6_transaction` / `fake_v6_orchard_shielded_data` builders to synthesize diverse Ironwood shapes (bundle presence, flag combinations, value-balance and action-count variations), each self-checked by round-trip. - **The M1+M2 corpus** — ~68,000 mainnet-derived seeds (blocks, transactions, headers, P2P messages) carried forward. - **Real testnet samples** — NU6.3 is already active on testnet; an isolated node has synced past the activation height, and ~200 de-duplicated genuine Ironwood V6 transactions (carrying real Orchard proofs and actions) have been harvested into the corpus. Because they carry real proofs, these samples exercise branches the synthetic seeds cannot reach. Together the synthetic and real seeds drive execution deep into the Ironwood branches — the synthetic set for breadth of shapes, the testnet samples for real-proof depth — confirming the new targets genuinely reach the new code rather than bouncing off the wire format. ## Continuous fuzzing (GitHub Actions) ClusterFuzzLite continues to run on GitHub Actions — pull-request runs, six-hourly batch runs that grow the corpus, and a daily coverage report with corpus pruning. This baseline keeps Zebra under **continuous, latest-code fuzzing regardless of the OSS-Fuzz outcome below**. ## OSS-Fuzz submission As the final M3 deliverable, the project is packaged for **OSS-Fuzz** (`projects/zebra/` with Dockerfile, build script and project config). **No Zcash-ecosystem project is currently on OSS-Fuzz**, so this would be the first — putting Zebra on Google’s fuzzing infrastructure with automated triage, bisection and 24/7 runs. Zebra has been submitted as a pull request to `google/oss-fuzz` (#15900). If acceptance requires sponsorship from an established maintainer, we are glad to coordinate with the Zebra / Zcash Foundation team, and the fuzzing project can live in or be integrated with the official infrastructure. Either way — accepted upstream or not — the GitHub Actions setup above guarantees continuous fuzzing, and we intend to **maintain and iterate on this fuzzing project on an ongoing basis**. ## Coverage Per-subject-under-test region coverage is reported per source file (a whole-report total is not meaningful — it averages in the Rust standard library and third-party dependencies the fuzzers do not target). The report rebuilds automatically every day in CI. - Ironwood transaction — de/serialization (`transaction/serialize.rs`): **80.9%** - Ironwood transaction — semantic / consensus (`zebra-chain/transaction.rs`): **69.3%** - Ironwood value-balance codec (`value_balance.rs`): **41.7%** - Ironwood shielded data (`orchard/action.rs` **88.7%** , `orchard/shielded_data.rs` **48.6%** ) and note-commitment tree (`orchard/tree.rs` **53.7%** ) - (M1+M2 headline files carried forward: block/P2P deserialization, RPC, script, address, note-commitment tree, Equihash — see the repository dashboard.) **No crashes found to date** across all 15 targets. ## Repositories (public, fully reproducible) - **Fuzzing suite & harnesses:** [GitHub - robustfengbin/zebra-fuzz-m3 · GitHub](https://github.com/robustfengbin/zebra-fuzz-m3) - **Corpus & live coverage dashboard:** [https://robustfengbin.github.io/zebra-fuzz-m3-corpus/coverage/latest/report/linux/index.html](https://robustfengbin.github.io/zebra-fuzz-m3-corpus/coverage/latest/report/linux/index.html) Clone, build and run with `cargo +nightly fuzz build/run --fuzz-dir zebra-fuzz/fuzz `; the coverage report rebuilds nightly in CI. ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [September 10, 2026, 1:33am UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/17 "2026-09-10T01:33:54Z")
Hi ZCG team, Zebra maintainers, and Zcash community, **Monthly update — 2026-07-23 (M3 delivery) → 2026-09-10.** Apologies for the gap in this thread: the work continued through August, the write-up didn’t. Back to monthly from here. ## The harnesses now live in `ZcashFoundation/zebra` OSS-Fuzz’s review said the project looked good but needed maintainer buy-in, and that the harnesses should live upstream so maintenance ownership is clear. That is now done: - **Merged into `ZcashFoundation/zebra` on 2026-08-17** under `zebra-fuzz/` ([#11221](https://github.com/ZcashFoundation/zebra/pull/11221)) — 15 `cargo-fuzz` targets, 30 files, +12,455 lines, 0 deletions, reviewed and approved by a Zebra maintainer. - **Seed corpora** now live in [`ZcashFoundation/zebra-fuzz-corpora`](https://github.com/ZcashFoundation/zebra-fuzz-corpora), a Foundation repository the Zebra team created and populated. - **The OSS-Fuzz PR points at the Foundation** — `main_repo` is `ZcashFoundation/zebra`, `primary_contact` is `security@zfnd.org`, at their request. - The only change to existing crates is an off-by-default `fuzzing` feature on `zebra-network` and `zebra-consensus`: 16 lines, 0 deletions, no new dependencies. A fuzzing suite in a contributor’s repository decays the moment the contributor stops paying attention; one in the upstream tree is the maintainers’ to keep. ## What the review changed — with thanks to @alchemydc The most valuable findings this window came from the review, not from me. An automated pass raised 17 items; @alchemydc’s pass then assessed the harnesses for **defects found per CPU-hour** rather than correctness and produced seven must-fix items, all landed 2026-08-14: - A `sha256d` checksum barrier was starving three P2P targets — their compute went into one hash per input, then the input was discarded. Fixed: - Two oracles that could not fail, replaced with checks that can. - An Equihash probe whose parameters were rejected before reaching the verifier. - A `script_verify_fuzz` oracle that existed only in debug builds, not the one OSS-Fuzz uses. - Four wrong dictionary constants; every constant in all four dictionaries re-derived. - Seed corpora moved out of Zebra’s tree; per-input setup work removed from four targets. None were crashes found. They are the fuzzer’s aim being corrected — which decides whether the continuous compute that follows is worth anything. Thank you, DC. ## The backlog is upstream, and other people are working it The review also produced [#11261](https://github.com/ZcashFoundation/zebra/issues/11261), ten further improvements. Since then: **another contributor** , john-lawniczak, found the fuzz crate no longer built on `main` after the `zcash_primitives` transaction refactor, and a maintainer invited the repair — [#11394](https://github.com/ZcashFoundation/zebra/pull/11394), all 15 targets building. Reading the same drift, I reported five assertions that no longer test what they claim: two weakened by the refactor, **three that never tested anything from the day they were introduced — those three are mine.** I’m also proposing a CI job upstream, since nothing in Zebra’s CI compiles `zebra-fuzz` today, which is why that break went unnoticed for a week. [#11066](https://github.com/ZcashFoundation/zebra/issues/11066) — three caller-contract panics from the fuzzing, none reachable from untrusted input — is still open awaiting a maintainer preference on the fix. ## Continuous fuzzing Still running on GitHub Actions: per-PR runs, six-hourly batch runs, daily coverage report with corpus pruning. **No crashes across the 15 targets.** To be precise: those runs build from the vendored snapshot in `robustfengbin/zebra-fuzz-m3` pinned at 2026-07-31, not from Zebra’s `main` — the upstream copy is not under continuous fuzzing yet, which is what the OSS-Fuzz submission is for. The snapshot does include NU6.3, so the three Ironwood targets now run against the format that activated on mainnet on 2026-07-28. ## Where the OSS-Fuzz submission stands [google/oss-fuzz#15900](https://github.com/google/oss-fuzz/pull/15900) is still open, and it is not waiting on what it was in July. Maintainer buy-in is in place, @alchemydc confirmed the Foundation’s side on 2026-08-18, and the OSS-Fuzz reviewer came back on 2026-09-05 with a single one-line request. **The blocker is upstream and ours to clear, not Google’s.** The build clones `ZcashFoundation/zebra` at HEAD, so the API drift above turns two build configurations red. The repair (#11394) needs to land on `main`; it was waiting on #11387, which merged 2026-09-08. Once it is in, the PR goes green in one change. Acceptance itself is the **$3,000 conditional portion of Milestone 3** and that call does belong to Google; the fixed M3 deliverables were complete at delivery on 2026-07-23. If accepted, this would be the first Zcash-ecosystem project on OSS-Fuzz. Either way, the GitHub Actions setup keeps Zebra under continuous fuzzing and I intend to keep maintaining these harnesses. ## Links - Harnesses upstream: [zebra/zebra-fuzz at main · ZcashFoundation/zebra · GitHub](https://github.com/ZcashFoundation/zebra/tree/main/zebra-fuzz) - Merge PR: [https://github.com/ZcashFoundation/zebra/pull/11221](https://github.com/ZcashFoundation/zebra/pull/11221) - Seed corpora (Foundation): [GitHub - ZcashFoundation/zebra-fuzz-corpora: Seed corpora for the Zebra cargo-fuzz harnesses. Harnesses live in ZcashFoundation/zebra; only the binary archives live here. · GitHub](https://github.com/ZcashFoundation/zebra-fuzz-corpora) - Follow-up backlog: [Follow-up work for the zebra-fuzz harnesses (deferred from #11221) · Issue #11261 · ZcashFoundation/zebra · GitHub](https://github.com/ZcashFoundation/zebra/issues/11261) - OSS-Fuzz submission: [Add zebra (Zcash consensus node) by robustfengbin · Pull Request #15900 · google/oss-fuzz · GitHub](https://github.com/google/oss-fuzz/pull/15900) - Coverage dashboard: [https://robustfengbin.github.io/zebra-fuzz-m3-corpus/coverage/latest/report/linux/index.html](https://robustfengbin.github.io/zebra-fuzz-m3-corpus/coverage/latest/report/linux/index.html) ---
**Author:** ![robustfengbin](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/robustfengbin/32/42095_2.png) [@robustfengbin](https://forum.zcashcommunity.com/u/robustfengbin)\ **Post date:** [September 19, 2026, 12:20pm UTC](https://forum.zcashcommunity.com/t/zebra-coverage-guided-fuzzing-infrastructure/54972/18 "2026-09-19T12:20:29Z")
Hi ZCG team, Zebra maintainers, and Zcash community, **Milestone 3 close-out — Zebra is now on OSS-Fuzz, and this completes the grant.** ## What shipped [google/oss-fuzz#15900](https://github.com/google/oss-fuzz/pull/15900) was merged on **2026-09-18 at 16:45 UTC** (merge commit `967a684`). `projects/zebra/` — Dockerfile, build configuration, project metadata — is now on `google/oss-fuzz` master, and **14 fuzz targets** ship from it, each with its seed corpus and, where useful, a dictionary. The submission built green under all ten configurations OSS-Fuzz’s CI exercises — libFuzzer with ASan, MSan, UBSan and coverage instrumentation, plus AFL++, Honggfuzz and Centipede — and the project itself is configured to run libFuzzer with AddressSanitizer on x86\_64, which is what fuzzes continuously. The first scheduled build on OSS-Fuzz’s own infrastructure **succeeded on 2026-09-19 at 06:10 UTC**, built from `ZcashFoundation/zebra` at HEAD, shipping all 14 targets with their corpora. The 15th target, `block_deep_fuzz`, is deliberately left out of the OSS-Fuzz set: `block_deserialize` already covers the same parse surface, and OSS-Fuzz splits a project’s compute across its targets, so a redundant target would dilute the others. It stays in the upstream tree and can be added in one line if that trade changes. ## A first for the Zcash ecosystem `google/oss-fuzz` master carries **1,381 project directories**. I checked every one of them by name: there is no `zcash`, `zcashd`, `librustzcash`, `halo2`, `orchard` or `sapling` entry. `bitcoin-core`, `go-ethereum` and `monero` are all there. **Zebra is the first project from the Zcash ecosystem to enter OSS-Fuzz.** ## What this changes in practice - **The fuzzing follows `main`.** The build clones `ZcashFoundation/zebra` at HEAD, so each daily rebuild fuzzes the current consensus code. Until now the continuous runs were against a snapshot pinned at 2026-07-31 — a pin that goes stale every time Zebra ships, which is more than weekly. - **Google’s infrastructure, not mine.** 24/7 runs, automatic crash deduplication, bisection to the offending commit, regression testing of every past crash, and a 90-day coordinated disclosure clock on anything found. - **Reports go to the Foundation.** `primary_contact` is `security@zfnd.org` at the Zebra team’s request, so crash reports and the ClusterFuzz dashboard land with the people who can fix and disclose them. - **The harnesses are upstream, not in a contributor’s repo.** They were merged into `ZcashFoundation/zebra` on 2026-08-17 ([#11221](https://github.com/ZcashFoundation/zebra/pull/11221)) under `zebra-fuzz/`, with seed corpora in [`ZcashFoundation/zebra-fuzz-corpora`](https://github.com/ZcashFoundation/zebra-fuzz-corpora). A fuzzing suite in a contributor’s repository decays the moment the contributor stops paying attention; one in the upstream tree is the maintainers’ to keep. ## Getting it through review The submission sat open for 57 days, and the last stretch was an upstream problem rather than a Google one: after the `zcash_primitives` transaction refactor the `zebra-fuzz` crate stopped building on `main`, which turned two OSS-Fuzz build configurations red. That repair — [#11394](https://github.com/ZcashFoundation/zebra/pull/11394), from another contributor, john-lawniczak, at a maintainer’s invitation — merged on 2026-09-18 at 13:44 UTC; the OSS-Fuzz build went green about three hours later and DavidKorczynski merged the submission the same day. Earlier in the window, @alchemydc’s review of #11221 sharpened where the harnesses aim — most visibly a `sha256d` checksum barrier that was starving three P2P targets, whose coverage rose 72%, 139% and 101% once it was fixed. ## Milestone 3 acceptance criteria Fixed portion ($6,000), all complete at delivery on 2026-07-23: | Criterion | Status | | --- | --- | | Security report delivered with all findings categorized | Delivered to the committee 2026-07-23 (private; contains disclosure detail) | | All documentation complete and reviewed | `docs/FUZZING-GUIDE.md` — adding targets, corpus management, security recommendations | | Upstream PRs opened for Zebra repository | [#11066](https://github.com/ZcashFoundation/zebra/issues/11066) (three caller-contract panics) and [#11221](https://github.com/ZcashFoundation/zebra/pull/11221), merged 2026-08-17 | | OSS-Fuzz PR submitted to google/oss-fuzz | [#15900](https://github.com/google/oss-fuzz/pull/15900), opened 2026-07-23 | Conditional portion ($3,000): | Criterion | Status | | --- | --- | | OSS-Fuzz PR accepted and merged by Google | Merged 2026-09-18 16:45 UTC, `967a684` | | Zebra actively running on OSS-Fuzz with continuous fuzzing operational | First scheduled build succeeded 2026-09-19 06:10 UTC, from `ZcashFoundation/zebra` at HEAD, all 14 targets shipped | ## Where the grant ends up Across the three milestones this grant took Zebra from no fuzzing infrastructure at all to 15 `cargo-fuzz` targets in the upstream tree, a maintained seed corpus, a documented process for adding targets, a security report to the committee, and continuous fuzzing on Google’s infrastructure that tracks `main` without anyone having to remember to update a pin. ## What I’m continuing, grant or no grant - Maintaining the harnesses as Zebra evolves — NU6.3/Ironwood is the current surface, and the targets need to keep up with consensus changes. - [#11261](https://github.com/ZcashFoundation/zebra/issues/11261) — ten follow-up improvements from the review, tracked upstream. - Five assertions that no longer test what they claim: two weakened by the transaction refactor, three that were weak from the start — mine, filed rather than left. Now that `main` compiles again, the replacements are unblocked. - A CI job that compiles `zebra-fuzz`. Nothing in Zebra’s CI builds it today, which is why the August break went unnoticed for a week. It guards compilation only — it would not have caught the five assertions above, and I don’t want to oversell it. - [#11066](https://github.com/ZcashFoundation/zebra/issues/11066) is still open, awaiting a maintainer preference on how to shape the fix. Thank you to ZCG for funding this, and to the Zebra maintainers — @alchemydc, @conradoplg and the review team — for taking the harnesses into the tree and reviewing them properly, and to john-lawniczak for the upstream repair that cleared the final blocker. ## Links - Zebra on OSS-Fuzz: [oss-fuzz/projects/zebra at master · google/oss-fuzz · GitHub](https://github.com/google/oss-fuzz/tree/master/projects/zebra) - Merged submission: [Add zebra (Zcash consensus node) by robustfengbin · Pull Request #15900 · google/oss-fuzz · GitHub](https://github.com/google/oss-fuzz/pull/15900) - Harnesses upstream: [zebra/zebra-fuzz at main · ZcashFoundation/zebra · GitHub](https://github.com/ZcashFoundation/zebra/tree/main/zebra-fuzz) - Seed corpora (Foundation): [GitHub - ZcashFoundation/zebra-fuzz-corpora: Seed corpora for the Zebra cargo-fuzz harnesses. Harnesses live in ZcashFoundation/zebra; only the binary archives live here. · GitHub](https://github.com/ZcashFoundation/zebra-fuzz-corpora) - Follow-up backlog: [Follow-up work for the zebra-fuzz harnesses (deferred from #11221) · Issue #11261 · ZcashFoundation/zebra · GitHub](https://github.com/ZcashFoundation/zebra/issues/11261) - Build status: [OSS-Fuzz build status](https://oss-fuzz-build-logs.storage.googleapis.com/index.html#zebra)