Zcash Private Receive Bridge

1. Executive summary and decision snapshot

Micheal Dean requests $38,000 as sole developer to qualify, harden and release Zcash Private Receive Bridge (PRB), an open-source local service intended to reduce disclosure of wallet-selected confirmed-transaction lookups. Funding covers five milestones, including independent review and six months of maintenance; no startup payment is requested.[1][7] The strongest capability indicator is the applicant’s described Rust MVP, with persistent storage, transaction-ID checks, local RPC handling and automated tests—not a demonstrated production-wallet deployment. The central evaluation issue is whether an unchanged released wallet can use PRB with practical advantages over existing alternatives.[1][6] Decision posture: The October 12 committee minutes say “Too early to vote.” The proposed $5,000 first milestone explicitly permits stopping or rescoping if wallet compatibility or practical usefulness is not established.[10][7]

2. Applicant and team track record

Dean identifies himself as the existing MVP’s developer and would own architecture, implementation, testing, wallet qualification, packaging, reporting and maintenance. No additional team members are listed; the application points to the project repository as supporting implementation history.[1] The applicant reports no previous project funding or other funding sources.[6] Independently verified prior grant delivery, production adoption or technical-review results: No grounded evidence found. This does not establish that the applicant has no other experience or prior grants.

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

PRB acquires every full transaction referenced within configured public compact-block intervals, independently of downstream wallet requests. It serves wallet-selected requests from a local gRPC cache and returns explicit errors rather than selectively retrieving missing transactions upstream.[4][5] Initial delivery is Linux x86-64, with an exact wallet/account/pool compatibility matrix, reproducible receipt and memo tests, resource measurements, documentation and review remediation. Receiving is confirmed-only; broadcasting is disabled.[5] Budget: $30,000 for 600 developer hours; $8,000 for an estimated 80-hour external review at $100/hour; zero hardware/software costs. The reviewer is not appointed and the allowance is not a supplier quote.[6]

4. Community discussion, arguments, responses, and resolution

• Strongest argument for: The applicant proposes a narrowly defined privacy property: changing the wallet’s selected confirmed transactions must not change or prioritize upstream retrieval under the same public acquisition policy. The intended contribution is compatibility with unchanged wallets, rather than new cryptography.[4]
• Strongest objection: Hanh argues that remotely hosting PRB would merely transfer transaction-ID/IP disclosure to the bridge operator. He also questions whether users would prefer a Zebra-plus-lightwalletd stack if infrastructure requirements are comparable.[7]
• Applicant clarification: The proposal specifies localhost deployment, keeps keys within the wallet and promises comparison with full nodes, Tor, RIME and Valar Wallet PIR. These are commitments in the application, not a documented reply to Hanh.[4][5]
• Resolution assessment—inference: Local deployment addresses the intended hosting model, but does not demonstrate a lower operational burden or greater usefulness than alternatives. A direct applicant response or documented resolution of the objection: No grounded evidence found.[4][7]

5. Relevant precedents and documented outcomes

Comparative relevance below is evaluator inference, not a finding that the projects are equivalent.

• VKX Wallet — $48,000, declined: Relevant to wallet-integration feasibility and user value. Committee comments questioned the missing implementation approach and perceived low download count. PRB’s concrete approach is a distinction, but a credible supported-wallet demonstration remains important.[10]
• red·bridge Launch — $477,658, approved: Relevant to delivery-conditioned release and maintenance funding, not PRB’s technical architecture. The committee required milestone-based payments and reported that the team had already fixed some MetaMask Snap/WebZjs issues. The supplied evidence does not establish launch impact or adoption; approval itself is not an outcome measure.[11]
• Privacy Bridge — $100,000, declined: Relevant specifically to differentiation, despite its different cross-chain DeFi scope. The documented reason was that it offered nothing specific beyond work already being explored in the ecosystem. This makes PRB’s promised alternatives comparison decision-relevant.[14]

6. Material risks and execution considerations

• Privacy and correctness boundaries: PRB does not provide full consensus validation. Upstream operators may withhold data or supply a self-consistent false view; IP, coverage, polling and timing remain observable. Partial coverage must not be represented as a complete balance.[5][6]
• Resource burden: Exhaustive acquisition may be expensive for long restores or busy intervals and increases upstream load. Actual cost and usable coverage limits remain to be measured.[6]
• Execution concentration—inference: One developer handling engineering, release and maintenance creates continuity and schedule exposure. Unappointed external review adds procurement uncertainty, particularly with only two weeks between the planned release candidate and review completion.[1][6][7]
• Limited support commitment: Maintenance covers the declared profile, not automatic compatibility with every future wallet or protocol feature.[7]

7. Material gaps and questions for the applicant

• Which exact released wallet, version, account types and pools will qualify, and what end-to-end evidence already exists beyond mock tests?[5][7]
• What measured restore time, bandwidth, disk and memory limits would make PRB useful compared with a private node or other alternatives—and trigger stopping if exceeded?[6][7]
• Who will independently reproduce milestone-one acceptance, and what evidence must demonstrate request-independent acquisition across misses, retries, cancellation and reorganizations?[6][7]
• Which reviewer can commit to the scope, price and February schedule? What happens if review or remediation exceeds the allowance?[6][7]
• What user demand would justify a confirmed-only Linux workflow without broadcasting, and how will users understand incomplete coverage?[5][6]
• If qualification fails or requires material rescoping, what work remains payable and what committee authorization is required before later milestones begin?[7]

8. Neutral decision considerations

Inference: The proposed structure supports separating a bounded feasibility assessment from a broader release commitment. If the committee considers staged funding, milestone-one acceptance could explicitly govern further expenditure, rather than treating compatibility as a routine implementation detail.[7] The strongest value case would combine reproducible unchanged-wallet operation, measured practical advantage and independently reviewed privacy claims. A technically functional cache alone would not establish those benefits. Conditions could therefore focus on user acceptance, resource thresholds, reviewer availability and an explicit stop/rescope mechanism, without predetermining approval or rejection.[4][6][7]

9. Numbered source list

• [1] Grant Application - Zcash Private Receive Bridge — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/479
• [7] Grant Application - Zcash Private Receive Bridge — posts 1–5, part 4 — https://forum.zcashcommunity.com/t/grant-application-zcash-private-receive-bridge/58103/1
• [6] Grant Application - Zcash Private Receive Bridge — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-zcash-private-receive-bridge/58103/1
• [10] Zcash Community Grants Meeting Minutes 10/12/2026 — posts 1–5, part 10 — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-10-12-2026/58182/2
• [4] Grant Application - Zcash Private Receive Bridge — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-zcash-private-receive-bridge/58103/1
• [5] Grant Application - Zcash Private Receive Bridge — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-zcash-private-receive-bridge/58103/1
• [11] red·bridge Launch — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/335
• [14] {Privacy Bridge} — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/169