Zebra Mempool Adversarial Resilience Suite

1. Executive summary and decision snapshot

The request is for an open-source “Zebra Mempool Adversarial Resilience Suite”: a standalone Rust testing crate intended to make Zebra mempool timeout, cancellation, concurrency, eviction, and admission-policy behavior deterministically testable under adversarial but valid transaction patterns. Proposed outputs include CI tests, ZIP 401 conformance checks, a threat model, documentation, and coordinated disclosure of confirmed findings. [5][7][10]

The applicant is Deucalion / GitHub user @deucali0n10, described as an independent solo developer. The application presents prior Rust, async-service, mempool, serialization, and Zcash/Zebra architectural experience, but these qualifications are self-reported and are not independently substantiated in the supplied evidence. [1][5]

Funding snapshot: the application narrative, budget, and milestone table consistently state a total of $18,000 over eight weeks: $3,000 startup funding, then three $5,000 milestones. However, the request metadata records $18.00. This material amount conflict should be resolved before any funding terms are considered. [1][9][10][11]

Delivery snapshot: Milestone 1 tests the central technical assumption by requiring deterministic CI reproduction of Zebra issue #10684; later milestones extend scenarios and integrate ZIP 401 properties and CI. This creates a useful early test of feasibility. [10]

Primary decision issue: the proposal identifies a plausible testing gap between individual regression tests and reusable adversarial, stateful testing. Its value nevertheless depends heavily on whether Zebra maintainers consider the standalone harness technically useful and maintainable, because upstream adoption is explicitly not required for milestone completion. [6][7][11]

2. Applicant and team track record

The applicant identifies as an independent, solo developer. No additional team members, subcontractors, or external funding sources are proposed. [5][9]

The application states that the lead has systems-engineering experience in Rust consensus-node internals; mempool transaction handling and admission logic; serialization; address encoding; chain/genesis initialization; multisignature schemes; and Tokio scheduling, timeout, and cancellation paths. The proposed responsibilities include harness architecture, adversarial-scenario design, vulnerability triage, coordinated disclosure, documentation, and reporting. [1][5]

Evidence limitation: No grounded evidence found of prior completed grants, publicly documented code contributions, delivered software, or externally verified outcomes attributable to Deucalion / @deucali0n10. The application says it has received no previous funding. [9]

Inference: The claimed background aligns closely with the project’s technical surface, but solo execution and the absence of independently documented delivery history increase reliance on milestone-based validation.

3. Proposal scope, milestones, budget, technical approach, and dependencies

The project would build a standalone crate, zebra-mempool-resilience, containing a controlled-clock and controlled-task-progression harness, synthetic multi-peer inputs, property/invariant checks, and adversarial scenario libraries. Targeted invariants include release of per-peer slots after verification timeouts, adherence to ZIP 401 mempool cost limits, resistance to adversarial eviction steering, and internal consistency after eviction. [7][8]

Scope is deliberately limited to in-process mempool policy behavior. The applicant excludes transaction/block/P2P/RPC parsing fuzzing, external synthetic-node network testing, batch-verification soundness, consensus changes, wallet functionality, and mempool reimplementation. [8][11]

Funding structure stated in the proposal:

• Startup: $3,000 for initial repository/crate scaffolding and deterministic-harness work. [10]
• Milestone 1: $5,000 by week 4 for the deterministic harness, multi-peer model, P0 scenarios, and repeatable CI reproduction of #10684. [10]
• Milestone 2: $5,000 by week 6 for P1 scenarios, timeout/concurrency regression coverage, and disclosure of confirmed findings. [10]
• Milestone 3: $5,000 by week 8 for ZIP 401 checks, CI integration, threat model, documentation, and final report. $1,500 of this milestone is conditional on stable Ironwood APIs. [10]

The stated budget is $16,500 compensation and $1,500 CI/compute costs, for $18,000 total. [8][9]

The project is designed to function against a pinned public Zebra revision without a commitment from Zebra maintainers. Upstream merge is described as beneficial but not required. [7][8]

4. Community discussion, arguments, responses, and resolution

No grounded evidence found of substantive community or Zebra-maintainer feedback on technical merit, overlap, cost, or adoption. The supplied comments concern posting the application to the forum and adding the application link. [12][13][14]

Strongest argument for: The applicant identifies a concrete gap: individual disclosed vulnerabilities may receive narrowly scoped regression tests, while timeout- and concurrency-dependent adjacent paths remain difficult to reproduce deterministically. The cited #10684 is presented as a regression in a timeout path despite nearby existing regression coverage. [5][6][11]

Strongest argument against: The proposal may create a separate test harness with limited practical value if Zebra maintainers do not adopt, run, or use it. The applicant recognizes this directly, asking maintainers whether they would find an external harness useful or prefer work retained in their existing security and CI processes. [11]

Applicant clarification: The applicant distinguishes the work from coverage-guided input fuzzing, synthetic-node testing, and batch-verification testing, and frames upstream merge as optional rather than a delivery dependency. [8][11]

Resolution status: Scope overlap is more clearly addressed than adoption value. The unresolved disagreement is whether a standalone external harness will provide sufficient ongoing security benefit without confirmed maintainer support.

5. Relevant precedents and documented outcomes

Zebra Coverage-Guided Fuzzing Infrastructure — $30,000. This is the closest documented comparable because it concerns security-testing infrastructure for Zebra. The present applicant distinguishes its proposal as stateful in-process mempool policy testing rather than broad coverage-guided fuzzing of transactions, blocks, P2P, and RPC. The comparable grant is recorded as approved, with Milestones 1 and 2 marked complete; however, no supplied evidence documents security findings, upstream adoption, or other substantive outcomes. [8][17]

Batch-vs-Single Verification Equivalence — $45,000 request. This is relevant as another proposed continuous CI-based assurance system for Zebra verification. It aimed to compare batch and individual shielded-verification results continuously. Its record is internally inconsistent: it is labeled approved while the supplied decision text says “Remains open.” No outcome evidence is supplied. It therefore supports the existence of interest in sustained security-test infrastructure, but not a reliable funding or delivery precedent. [15]

6. Material risks and execution considerations

• Core feasibility risk: deterministic control of async timeout and cancellation behavior is the principal engineering challenge. The proposal appropriately makes successful deterministic reproduction of #10684 the Milestone 1 acceptance test. [9][10]
• Adoption and durability risk: CI infrastructure can be delivered standalone, but practical ongoing value is uncertain without evidence that Zebra maintainers will run, review, or incorporate it. [7][11]
• Solo-delivery risk: one developer is responsible for all engineering, testing, disclosure, documentation, and reporting. [5][9]
• Upstream-change risk: Zebra mempool code is described as actively changing; the applicant plans to pin and update against revisions. [9]
• Conditional-scope risk: Ironwood scenarios are dependent on API stability and account for $1,500 of the final milestone. [10]
• Impact boundary: the applicant does not claim that this work prevents consensus failures; the stated security objective is availability and transaction-relay censorship resistance. [6][11]

7. Material gaps and questions for the applicant

1. Please confirm the requested amount: is it $18,000, as the budget and milestones state, or $18.00, as the request metadata states? [1][9][10]
2. Can Zebra maintainers provide written feedback on whether a standalone harness would be used, reviewed, incorporated, or otherwise considered valuable?
3. What public code, prior contributions, or prior testing artifacts demonstrate the applicant’s ability to build deterministic Tokio-based test infrastructure?
4. What exact repository, licensing, maintenance period, CI ownership, and compute-spending controls will apply after the eight-week grant?
5. Can Milestone 1 acceptance require an independently reproducible demonstration that #10684 fails on an affected pinned revision and is reliably exercised by the harness?
6. If Ironwood APIs are not stable, how will the $1,500 conditional component be withheld, redirected, or separately accepted? [10]
7. What measurable criterion distinguishes a useful ZIP 401 “eviction gameability” property from a test that merely reflects assumptions embedded in the harness?

8. Neutral decision considerations

Factors supporting consideration include a narrowly defined security-testing objective, an early feasibility gate, permanent open-source deliverables, and a stated effort to avoid duplicating adjacent testing domains. [8][10]

Factors warranting caution include the unresolved $18-versus-$18,000 funding discrepancy, lack of independently documented applicant delivery history, solo execution, uncertain maintainer adoption, and absence of substantive community or maintainer feedback. [1][9][12][13][14]

Inference: A committee could treat the proposal as stronger if funding conditions emphasize verified Milestone 1 reproducibility, explicit treatment of the conditional Ironwood amount, and evidence of intended-user interest before substantial later payments. This is a decision consideration, not a recommendation for an autonomous approve-or-reject outcome.

9. Numbered source list

• [5] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [7] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 4 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [10] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 7 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [1] Grant Application - Zebra Mempool Adversarial Resilience Suite — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/362
• [9] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 6 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [11] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 8 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [6] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [8] Grant Application - Zebra Mempool Adversarial Resilience Suite — posts 1–5, part 5 — https://forum.zcashcommunity.com/t/grant-application-zebra-mempool-adversarial-resilience-suite/56740/1
• [12] Comment on #362: Grant Application - Zebra Mempool Adversarial Resilience Suite — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/362#issuecomment-5023938286
• [13] Comment on #362: Grant Application - Zebra Mempool Adversarial Resilience Suite — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/362#issuecomment-5023509814
• [14] Comment on #362: Grant Application - Zebra Mempool Adversarial Resilience Suite — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/362#issuecomment-5024002064
• [17] Zebra Coverage-Guided Fuzzing Infrastructure — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/234
• [15] Batch-vs-Single Verification Equivalence: Continuous Soundness Fuzzing for Zcash Shielded Verification (incl. Ironwood) - decision minutes — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-6-22-2026/56384