Project Summary
Zcash Private Receive Bridge is an open-source local service designed to reduce disclosure of wallet-selected confirmed transaction lookups to remote lightwallet servers. It downloads public block intervals and the full transactions referenced by their compact blocks, then serves supported wallets through a local gRPC cache without selective upstream fallback.
Project Description
I am seeking funding to take the existing PRB MVP through wallet qualification, release hardening, packaging, independent technical review and six months of maintenance.
The intended user keeps a supported, unchanged desktop wallet and configures it to connect to the bridge’s localhost endpoint. The bridge acquires public blockchain data separately from wallet requests. Wallet-selected lookups are served locally; missing data does not trigger a selected request to the upstream server.
The current Rust implementation includes interval acquisition, persistent SQLite storage, transaction-ID checking, local RPC handlers, coverage tracking, restart and reorganization handling, and automated protocol tests.
The funded work will establish a reproducible supported-wallet workflow and produce a qualified standalone release. Mock-server tests and written compatibility summaries will be distinguished from actual released-wallet demonstrations.
Proposed Problem
A shielded wallet can scan compact blocks locally and subsequently request selected full transactions to obtain received transaction details or memos. The remote service sees those transaction identifiers and can infer the wallet’s interests.
Running a private full node is an existing alternative. Tor can reduce IP and session linkage, depending on routing and circuit isolation, but does not automatically conceal a selected transaction identifier from the service answering that request.
PRB targets this retrieval pattern for a precisely documented confirmed-receive workflow.
Proposed Solution
PRB acquires a configured public coverage interval, retrieves every full transaction referenced in those compact blocks, checks transaction encoding and identifiers, and commits complete batches to its local database. A compatible wallet reads from that cache.
The target privacy property is that, under the same public coverage and acquisition policy, changing which confirmed transactions the wallet requests must not introduce or prioritize selected upstream retrieval. Cache misses return explicit errors.
This uses established cover-retrieval ideas rather than new cryptography. The proposed contribution is a standalone standard-gRPC delivery path for unchanged released wallets.
Qualification will compare that workflow with private full nodes, Tor, RIME and Valar Wallet PIR. Any claimed practical advantage will be supported by evidence.
Solution Format
The project will deliver:
-
A standalone Rust daemon and command-line tools.
-
A persistent SQLite cache and local CompactTxStreamer gRPC endpoint.
-
An initial Linux x86-64 release with checksums and reproducible build and installation instructions.
-
An exact wallet-release and account/pool compatibility matrix.
-
Reproducible receipt, memo, RPC-trace and resource-measurement evidence.
-
A threat model, CONTRIBUTING.md, security-reporting guidance and maintenance documentation.
-
An independent review report and documented resolution of findings.
Dependencies
The MVP uses Rust, Tokio, Tonic/Prost, SQLite and released Zebra parsing code. Resolved dependencies are recorded in Cargo.lock.
Acquisition requires an available lightwalletd-compatible service exposing the necessary public RPCs. Wallet delivery requires a current released wallet that accepts a custom localhost endpoint and the documented confirmed-only profile. Establishing that exact compatibility is the first milestone.
The intended delivery model requires no upstream merge, wallet fork, letter of intent, maintainer approval, commercial partnership, new custody arrangement or unreleased protocol feature.
Independent technical review will be procured as an external service.
Technical Approach
-
Keep public acquisition independent of downstream wallet requests, including retry and cancellation behavior.
-
Parse complete transaction encodings using released libraries, recompute transaction IDs and compare them with the corresponding compact-block references.
-
Persist complete batches and required block, transaction, tree and subtree data atomically.
-
Serve wallet-selected requests from local storage only. Reject missing or unsupported coverage without selected upstream fallback.
-
Qualify restart, corruption, reorganization and concurrent-read behavior against the delivered wallet profile.
-
Validate network-upgrade metadata and transaction/pool support against current released protocol data before advertising current-mainnet compatibility.
-
Keep receiving confirmed-only and broadcasting disabled. Verify the selected wallet’s behavior without live unconfirmed transaction delivery.
-
Measure actual daemon RPCs, bytes, elapsed time, peak memory and persistent disk use on declared workloads.
The bridge requires no seed, private key or viewing key. Keys and note decryption remain within the wallet.
Transaction-ID matching and compact-block continuity checks do not independently authenticate the whole chain or replace full consensus validation. Upstream operators can still withhold data or provide a self-consistent false view. IP address, public coverage, polling and network timing remain observable.
Transparent indexing will not be presented as complete transparent-account support without qualification. Only account types, pools and RPC paths supported by the evidence will be advertised.
Upstream Merge Opportunities
No upstream merge is required. PRB is a standalone service using released libraries and the public lightwallet RPC protocol.
Any later contribution to a wallet, SDK or node would be optional and separately scoped.
Open Source License
MIT
Hardware/Software Costs (USD)
0
Hardware/Software Justification
Nil
Service Costs (USD)
$8,000
Service Costs Justification
Estimated allowance for independent review of the acquisition/privacy boundary, parsing and transaction-ID checks, cache consistency, reorganization handling and supported-wallet behavior.
The planning basis is approximately 80 hours at $100 per hour. This is an estimate rather than a supplier quote; no reviewer has been appointed.
Compensation Costs (USD)
$30,000
Compensation Costs Justification
| Work | Estimated hours | Compensation |
|---|---|---|
| Wallet qualification and feasibility evidence | 100 | $5,000 |
| Daemon hardening and regression coverage | 220 | $11,000 |
| Packaging, documentation, reproducibility and remediation | 160 | $8,000 |
| Six months of maintenance | 120 | $6,000 |
| Total | 600 | $30,000 |
The budget covers future work and does not charge again for the existing MVP.
Total Budget (USD)
$38,000
Previous Funding
No
Previous Funding Details
No response
Other Funding Sources
No
Other Funding Sources Details
No response
Implementation Risks
-
A current released wallet may require RPC, tree, pool or mempool behavior beyond the qualified profile. Milestone 1 establishes feasibility before broader delivery.
-
Exhaustive transaction acquisition can be expensive during long restores or busy intervals. Costs and usable coverage limits will be measured rather than extrapolated from a short sample.
-
Upstream outages, malformed responses, chain replacement and interrupted writes can affect scanning. Recovery must preserve cache-only behavior and explicit errors.
-
A solo developer has limited delivery capacity. The proposal therefore starts with one qualified Linux wallet profile and a bounded release scope.
-
Existing alternatives may provide a better practical workflow. The first milestone will evaluate whether PRB offers a useful independent delivery path
Potential Side Effects
-
Cover retrieval increases traffic and load on upstream services. Concurrency, retry and coverage limits will be documented.
-
A confirmed-only profile delays visibility of unconfirmed receipts. Partial coverage can produce missing data and must not be presented as a complete account balance.
-
Users must not interpret PRB as IP anonymity, complete traffic privacy or full-node validation.
Success Metrics
-
At least one current official released desktop wallet works unchanged through PRB for the declared profile.
-
A reproducible confirmed shielded receipt and memo workflow produces matching direct-versus-bridge wallet state, including restart and offline rescan.
-
Complete upstream RPC traces show no wallet-triggered selected fallback under the tested public policy, including misses, retries, cancellation, restart and reorganization cases.
-
Every advertised pool, transaction version and account profile has appropriate, clearly labelled qualification evidence.
-
Daemon measurements disclose workload, hardware, RPC attempts and errors, byte-accounting boundary, elapsed time, peak memory and disk use.
-
Existing regression assertions remain intact, and newly claimed behavior has targeted tests.
-
Independent review findings affecting the claimed privacy or correctness are resolved before release.
-
A target user or representative can reproduce installation and the supported workflow, with milestone acceptance documented.
Startup Funding (USD)
0
Startup Funding Justification
nil
Milestone Details
Milestone 1 — Wallet qualification and feasibility
Amount: $5,000
Expected Completion: 23 November 2026
User Story
- As a desktop wallet user, I want to retrieve confirmed receipt details through PRB while keeping my existing wallet.
Deliverables
-
Exact official wallet-release provenance and a safe reproducible receipt/memo fixture.
-
Clean GUI setup and direct-versus-bridge wallet-state comparison.
-
Restart and offline-rescan demonstration.
-
Required-RPC audit and complete upstream traces.
-
Restoration and recent-interval cost measurements.
-
Comparison with existing alternatives and explicit support/resource limits.
Acceptance Criteria
-
A target user or representative reproduces the workflow without modifying the wallet, giving keys to PRB or triggering selected upstream fallback.
-
Stop or rescope if no current unchanged released wallet qualifies or the workflow lacks practical independent usefulness.
Milestone 2 — Hardened daemon
Amount: $11,000
Expected Completion: 4 January 2027
User Story
- As a user, I want covered receive data to remain correct through outages, restarts and chain replacement.
Deliverables
-
Qualified network, pool and transaction-version metadata.
-
Persistent complete coverage and required tree/subtree policy.
-
Reorganization and concurrent-read handling.
-
Corruption and interruption recovery.
-
Expanded regression coverage.
Acceptance Criteria
- Documented failure-injection and supported-wallet tests pass without partial committed coverage or selected upstream fallback. Unsupported profiles fail explicitly.
Milestone 3 — Installable release candidate and evidence package
Amount: $8,000
Expected Completion: 1 February 2027
User Story
- As a Linux desktop user, I want to install and operate PRB using clear, repeatable instructions.
Deliverables
-
Linux x86-64 release candidate, checksums and build instructions.
-
Configuration and status guidance.
-
Exact compatibility matrix and reproducibility evidence.
-
Threat model, contribution guidelines and security-reporting documentation.
-
Engineering capacity for review remediation.
Acceptance Criteria
- A target user or representative completes a clean installation and the qualified receipt workflow using the published instructions. Product claims match the evidence and supported profile.
Milestone 4 — Independent technical review
Amount: $8,000
Expected Completion: 15 February 2027
User Story
- As a user, I want independent scrutiny of the privacy and correctness properties on which the release relies.
Deliverables
-
Scoped external review report.
-
Findings register and remediation evidence.
-
Final release.
-
Implementation and remediation time is included in the developer compensation above.
Acceptance Criteria
The review covers the advertised workflow and trust boundaries. Findings that invalidate the claimed privacy or correctness are resolved and retested. Remaining limitations are disclosed.
Milestone 5 — Six months of maintenance
Amount: $6,000
Expected Completion: 15 August 2027, assuming the February release.
User Story
As a user, I want the supported release maintained as dependencies, wallets and network conditions change.
Deliverables
-
Monthly progress reports.
-
Issue triage and bounded compatibility/dependency retesting.
-
Necessary fixes.
-
Final maintenance report.
####Acceptance Criteria
-
Six monthly reports and a reproducible final regression and compatibility record are delivered.
-
Maintenance covers the declared profile; it does not promise automatic support for every new wallet or protocol feature.
Supporting Documents
- MVP Repository: https://github.com/intelliDean/zcash-prb