`zcashlib`: A Pure-JavaScript Zcash Library

1. Executive summary and decision snapshot Coin Wallet requests $150,000 to build zcashlib, an MIT-licensed pure-JavaScript Zcash library without WASM or native bindings. The proposed end state is transparent and Sapling shielded Zcash support—including key derivation, Unified Addresses, scanning, witnesses, and JavaScript proof generation—validated against Zcash test vectors and librustzcash, then deployed in Coin Wallet. [1][5][6]

• Delivery team: Evgeny Vlasenko, lead developer, and Nikita Verkhovin, CTO. [1][5]
• Funding structure: $40,000 startup funding, then $50,000 Milestone 1 due April 30, 2027, and $60,000 Milestone 2 due June 30, 2027. [7][8]
• Central value proposition: a reusable second implementation and a JavaScript-native integration option for environments where WASM/native bindings are undesirable. [5][6]
• Core delivery concern: the proposal’s highest-value component—the JavaScript Groth16 prover and Sapling circuits—is explicitly the hardest and least proven element. [7]
• Material scope ambiguity: Coin Wallet has a simultaneous $100,000 proposal to ship Zcash using WebZjs/WASM and support Ironwood, while this request proposes a separate pure-JS Sapling implementation and also names Coin Wallet deployment as validation. The applications’ division of work, sequencing, and whether either depends on the other need clarification. [8][15]

Inference: This is best evaluated primarily as high-risk protocol and cryptographic R&D with potential ecosystem reuse, rather than as a conventional wallet-integration grant.

2. Applicant and team track record Coin Wallet describes itself as a self-custodial, open-source, MIT-licensed multicurrency wallet launched in 2015, with support for 23 chains including Monero. [8] The team identifies:

• Evgeny Vlasenko: 15 years of software-development experience and crypto work since 2020. [1]
• Nikita Verkhovin: 15 years of software-development experience and crypto work since 2015. [5]

The applicant states this is its first grant application and that it has not received prior grant funding. [7] No grounded evidence found of independently documented delivery of Zcash protocol software, JavaScript cryptography, zero-knowledge proving systems, or prior grant outcomes by this team.

The claimed existing multi-platform wallet is relevant operational evidence, but it does not by itself establish capability to reproduce Sapling circuit synthesis or build a secure JavaScript prover. [8]

3. Proposal scope, milestones, budget, technical approach, and dependencies The project builds in four engineering layers: transparent transactions; shielded keys and Unified Addresses; shielded viewing, note scanning, and witnesses; then a JavaScript Groth16 prover and Sapling circuits. Only transparent support and full shielded send/receive are intended as user-facing releases. Ironwood is explicitly excluded. [5]

Budget

• Compensation: $140,000, attributed to a senior JavaScript/cryptography engineer and a ZK engineer. [7]
• Hardware/software: $2,000 for Android and iOS test devices. [6]
• Services: $8,000 for CI and compute. [6]
• Total: $150,000. [7]

Milestone 1 — $50,000, April 30, 2027

• Transparent pure-JS transaction construction/signing, official vectors in CI, mobile benchmarks, and transparent ZEC in Coin Wallet.
• Shielded keys, Unified Addresses, scanning, commitment-tree/witness functionality, and background scanning.
• Acceptance includes matching shielded notes found by librustzcash for the same seed and block range. [7][8]

Milestone 2 — $60,000, June 30, 2027

• JavaScript Groth16 prover/verifier, Sapling circuits, diagnostic harness, validated witness store, shielded send/receive in Coin Wallet, and submission of witness vectors upstream.
• Acceptance includes a shielded transaction built, proved, and signed entirely in JavaScript being accepted by the Zcash network. [8]

Dependencies include pinned @noble and @scure primitives, Zcash test vectors, librustzcash as a differential oracle, and Sapling parameter files. The applicant identifies missing upstream zk-circuit witness vectors and proposes to create and contribute them. [6]

4. Community discussion, arguments, responses, and resolution Strongest argument for: The project could create an independently auditable JavaScript implementation, remove WASM/native integration constraints, provide reusable prover infrastructure, and improve cross-implementation testing through differential validation. [5][6]

Strongest argument against: A community respondent questioned why WebZjs is insufficient, whether a pure-JS approach is more secure, whether WASM would be faster, and whether benchmarks substantiate the performance trade-off. [12]

Applicant response: The applicant agreed JavaScript is slower, arguing that an all-JS approach avoids a WASM bridge and moving private data between JavaScript and WASM. [12] The written proposal also commits to benchmark mobile performance before finalizing remaining scope. [6][7]

Resolved concern: The applicant has directly acknowledged the likely performance disadvantage and proposed measurement early in the project. [6][12]

Unresolved disagreement: No grounded evidence found of published benchmarks, a comparative security analysis versus WebZjs/WASM, or external technical review supporting the claimed security, auditability, or practical-performance advantages. The central question is therefore unresolved: whether pure JS delivers ecosystem value commensurate with its engineering and security risk. [12]

5. Relevant precedents and documented outcomes Zcash WalletConnect Integration — Noir Wallet, $50,000, approved. This is relevant because ZCG supported a wallet-facing integration where the committee emphasized reusable ecosystem value beyond a single wallet and cited the applicant’s perceived track record. [16] It suggests that portability and reuse can justify funding, but zcashlib is technically much more ambitious and costs three times as much. No grounded evidence found of post-approval delivery or adoption outcomes for that grant. [16]

Qubit Wallet — QuBit, $45,000, declined. This is relevant because it shows a documented committee concern about funding additional wallets without strong product demand. The decline cited lack of interest in further wallet funding and insufficient apparent demand. [18] zcashlib differs because it proposes shared library and proving infrastructure, but its practical value should be assessed on likely external adoption rather than Coin Wallet deployment alone.

6. Material risks and execution considerations

• Cryptographic correctness and safety: The applicant acknowledges that protocol divergence is possible and says the library should not be trusted with funds until independently reviewed. Test vectors and differential testing reduce but do not replace an independent security review. [6][7]
• Prover feasibility: Correctly reproducing circuit synthesis is explicitly identified as the hardest component. Milestone 2 concentrates the most novel work into a short period after the April milestone. [6][8]
• Performance: Pure JS is acknowledged to be slower, while mobile performance is fundamental to usable shielded wallets. Benchmarks are proposed but not yet supplied. [6][12]
• Milestone design: Milestone 1 combines transparent product release with most viewing/scanning infrastructure; it is substantial before the project reaches its main shielded-spending proof point. [7][8]
• Adoption and maintenance: Publishing on npm and deploying in Coin Wallet are stated goals, but no external integrator commitments, maintenance plan, audit plan, or adoption targets are documented. [6][7]

7. Material gaps and questions for the applicant

8. Provide benchmark results or a concrete benchmark plan with minimum pass/fail thresholds for browser, iOS, and Android proving, scanning, and memory use.

9. Explain why the pure-JS approach offers sufficient security or integration advantage over WebZjs/WASM to justify a separate $150,000 implementation.

10. Define the exact relationship between this request and the concurrent $100,000 WebZjs/Coin Wallet proposal: overlapping work, mutual dependencies, shared staff, and whether both grants can be funded without duplicative Coin Wallet integration spending. [8][15]

11. Identify the named engineers responsible for JavaScript cryptography and zero-knowledge proving, their allocated effort, and relevant verifiable prior work.

12. Specify what independent review or audit will be required before Coin Wallet enables shielded funds for users, who will perform it, and how findings would affect release.

13. State whether Milestone 2 payment requires upstream acceptance of witness vectors or only their submission, since upstream acceptance is outside the applicant’s control. [8]

14. Neutral decision considerations Potential reasons to support the request include creation of reusable JavaScript-native Zcash components, a second implementation for differential testing, explicit acceptance criteria tied to vectors and network acceptance, and an applicant-proposed warning against premature use with funds. [6][7][8]

Potential reasons for caution include the absence of independently documented ZK-proving experience, no supplied benchmarks or external audit commitment, an ambitious cryptographic scope concentrated into a short schedule, and material overlap questions with Coin Wallet’s parallel WebZjs integration proposal. [6][8][15]

Inference: If the committee considers funding, value protection may be improved by treating independently reproducible correctness tests, published performance thresholds, a clear non-duplication plan across the two Coin Wallet proposals, and a pre-release independent security-review commitment as conditions tied to milestone acceptance.

9. Numbered source list

• [1] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/413
• [5] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-zcashlib-a-pure-javascript-zcash-library/57470/1
• [6] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-zcashlib-a-pure-javascript-zcash-library/57470/1
• [7] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — posts 1–5, part 4 — https://forum.zcashcommunity.com/t/grant-application-zcashlib-a-pure-javascript-zcash-library/57470/1
• [8] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — posts 1–5, part 5 — https://forum.zcashcommunity.com/t/grant-application-zcashlib-a-pure-javascript-zcash-library/57470/1
• [15] Grant Application - Zcash Integration in Coin Wallet (WebZjs + lightwalletd) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/412
• [12] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — posts 1–5, part 9 — https://forum.zcashcommunity.com/t/grant-application-zcashlib-a-pure-javascript-zcash-library/57470/2
• [16] Zcash WalletConnect Integration — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/391
• [18] Qubit Wallet — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/134