### 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)
@mahnunchik, @nikashitsa, @Dolorozo
### Organization Name
Coin Wallet
### How did you learn about Zcash Community Grants
Colleagues from Unstoppable Wallet (https://github.com/Dadybayo) told us
### Requested Grant Amount (USD)
150000
### Category
Research & Development
### Project Lead
```project-lead.yaml
Name: Evgeny Vlasenko
Role: Lead developer, Coin Wallet
Background: 15 years of software development experience. Working in crypto since 2020.
Responsibilities: Development according to the project plan.
```
### Additional Team Members
```team-members.yaml
- Name: Nikita Verkhovin
Role: CTO Coin Wallet
Background: 15 years of software development experience. Working in crypto since 2015
Responsibilities: Development according to the project plan.
```
### Project Summary
Build a pure-JavaScript Zcash library — no WASM, no native bindings — supporting transparent and shielded Zcash end to end: key derivation, Unified Addresses, note scanning, and proof generation for both sending and receiving shielded funds.
### Project Description
Every shielded Zcash implementation reachable from JavaScript today is Rust, either compiled to WASM or behind native FFI. We surveyed the npm registry and confirmed it across Ledger's packages, `zcash-view-wasm`, `pivx-shield`, `@chainvue/verus-sapling`, `zcash-zip321-alpha`, `@gstohl/t2z`, WebZjs and `react-native-zcash`. **No pure-JS implementation of Zcash's shielded protocol exists.**
This grant produces one: an auditable library resting only on well-reviewed JavaScript cryptography primitives, validated at every step against the official Zcash test vectors and against `librustzcash` itself.
### Proposed Problem
A WASM blob is not auditable the way source is. Shielded wallet state managed by a multi-megabyte opaque binary — in practice built by hand from an unpinned revision — is a supply-chain question for every integrator downstream.
WASM also raises the floor for integration: threaded builds need cross-origin isolation, native bindings exclude browsers entirely, and both shut out large classes of JavaScript environments.
And there is no reference implementation JS developers can read. Verifying or reimplementing Zcash from JavaScript today means reading Rust.
### Proposed Solution
Four layers, which are also the build order — you cannot spend a shielded note without first being able to find it, locate it in the commitment tree and keep its witness:
1. **Transparent** — transaction building and signing, addresses, HD derivation.
2. **Keys and addresses** — shielded key hierarchy, viewing keys, Unified Addresses.
3. **Viewing** — trial decryption of shielded outputs, nullifiers, commitment tree and witnesses, background scanning.
4. **Proving** — a JavaScript Groth16 prover and the Sapling circuits, which is what makes shielded funds spendable.
Only two of these are user-facing releases: transparent Zcash, and then full shielded send and receive. The layers in between are engineering stages, not product increments.
Ironwood, the pool activated in July 2026, uses a different proof system for which no implementation exists outside Rust. Supporting it is the natural next step for this library and a separate, larger piece of work; this grant delivers the Sapling stack and the prover foundation that step would build on.
### Solution Format
`zcashlib` on npm under MIT · the official Zcash test-vector suite green in CI · a differential harness against `librustzcash` · a standalone JavaScript Groth16 prover and verifier · Zcash live in Coin Wallet as real-world validation · published benchmarks from browser and mobile.
### Dependencies
`@noble` and `@scure` cryptography primitives, pinned. The relevant ZIPs read as primary sources. `zcash/zcash-test-vectors` and `librustzcash` as differential oracles. Sapling parameter files are used, not redistributed.
**Needed from upstream:** test vectors for zk-circuit *witnesses*. None exist today, and this is exactly where they would matter most. We will contribute ours.
### Technical Approach
Scope is set by measurement rather than estimate: we benchmarked the underlying curve and proving primitives in real browsers and on mobile before writing this application, and mobile engines are re-measured in the first milestone before the rest of the scope is fixed.
Correctness is established differentially, not by self-testing. Every layer is checked against the official vectors, and the wallet layers are checked against `librustzcash` on the same seed and block range. For the prover, the diagnostic harness that compares our circuit synthesis against the reference implementation is built **before** the circuits themselves, because a proof that fails to verify otherwise gives no clue where it went wrong.
### Upstream Merge Opportunities
We are not forking a Zcash repository; this is a new independent implementation, so the contribution flows the other way — toward what the ecosystem lacks:
- **The library itself** — the first pure-JS shielded implementation, and a second independent implementation of the protocol, useful for differential testing of the Rust stack.
- **A JavaScript Groth16 prover** compatible with Zcash's existing parameters, plus the Sapling circuits in JS. Nothing comparable exists outside Rust. Released standalone so it is reusable beyond this project.
- **Circuit witness test vectors** contributed to `zcash/zcash-test-vectors`, filling the one gap in an otherwise excellent suite.
- Protocol ambiguities and spec divergences we surface, as ZIP feedback or `librustzcash` issues. A fresh implementation written from the spec alone tends to find these.
We will publish work in progress from the first milestone and ask ECC/ZF for review as we go rather than at the end, since correctness here is not something we can self-certify.
### Hardware/Software Costs (USD)
2000
### Hardware/Software Justification
$2,000 for one extra mid-range Android phone and one iOS device. The first milestone publishes mobile benchmarks, and those numbers decide the rest of the scope. Existing Coin Wallet machines cover the rest. No servers or licenses.
### Service Costs (USD)
8000
### Service Costs Justification
$8,000 for CI and compute over the project: running the official Zcash test vectors on every change, and running the differential harness against librustzcash. npm publishing is free. No hosted lightwalletd in this grant.
### Compensation Costs (USD)
140000
### Compensation Costs Justification
$140,000 is compensation for the senior JS/cryptography engineer, plus a ZK engineer for the proving work, which is the single largest cost driver.
### Total Budget (USD)
150000
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
**Implementation risks.** The prover is the hard part, and honestly so: reproducing the reference implementation's circuit synthesis exactly has a binary correctness signal, which is why the diagnostic harness is built first and why the earlier layers are independently valuable and ship separately. The commitment tree and witness store risk silent state corruption, so they are validated against `librustzcash` rather than self-tested. Mobile JavaScript engine performance is measured before scope is fixed. Ironwood support is not in this grant's scope and is stated as such rather than assumed.
### Potential Side Effects
**Potential side effects.** Nothing shielded reaches users until spending works, so no one is left holding funds they cannot move. A second implementation of a privacy protocol does risk subtle divergence from the first; mitigated by vectors and differential testing, but stated openly — the library should not be trusted with funds until independently reviewed, and we will label it so. Publishing a prover also invites misuse in unaudited wallets, so limitations are documented prominently.
### Success Metrics
**Success metrics.** The official vectors pass for every layer. Balance and note set match `librustzcash` byte for byte on the same seed and block range. A shielded transaction built, proved and signed entirely in JavaScript is accepted by the network. Zcash live in Coin Wallet on web, desktop and mobile. Library published with external consumers, and witness vectors merged upstream.
### Startup Funding (USD)
40000
### Startup Funding Justification
$40,000 is requested as startup funding so work can begin starting from December 2026 (earliest).
This is our first grant application. We have not received or worked with any previous grants.
These first $40,000 let us put zcashlib at the highest priority: build and sign transparent Zcash transactions in pure JavaScript, get the official vectors green, publish mobile benchmarks, and ship transparent ZEC in Coin Wallet.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 50000
Expected Completion Date: 2027-04-30
User Stories:
- "As a JS developer, I want to build and sign transparent Zcash transactions in pure JavaScript, so that official test vectors pass."
- "As a Coin Wallet user, I want transparent ZEC live on web, desktop and mobile, so that the first release is real, not only a library."
- "As a wallet developer, I want shielded keys, Unified Addresses and note scanning in pure JS, so that a wallet can find its own shielded notes."
Deliverables:
- Transparent core in pure JS: addresses, HD derivation, transaction building and signing
- Official Zcash test vectors green in CI
- Mobile benchmarks published
- Transparent ZEC shipped in Coin Wallet on web, desktop and mobile
- Shielded key hierarchy, viewing keys and Unified Addresses
- Trial decryption, nullifiers, commitment tree, witnesses
- Background incremental scanning
Acceptance Criteria: Official vectors pass for transparent txs, keys and Unified Addresses. Transparent ZEC send/receive works in Coin Wallet on web, desktop and mobile. On the same seed and block range, the library finds the same shielded notes as librustzcash. Benchmarks from a real phone are published.
- Milestone: 2
Amount (USD): 60000
Expected Completion Date: 2027-06-30
User Stories:
- "As a user, I want a shielded transaction built, proved and signed entirely in JavaScript and accepted by the network, so that send and receive work without WASM."
Deliverables:
- Witness store validated against librustzcash
- JavaScript Groth16 prover and verifier
- Diagnostic harness before the circuits
- Sapling circuits in JS
- Shielded send and receive shipped in Coin Wallet
- Witness test vectors contributed to zcash/zcash-test-vectors
Acceptance Criteria: A shielded transaction built, proved and signed only in JavaScript is accepted by the Zcash network. Shielded send/receive works in Coin Wallet. Witness vectors are submitted upstream.
```
### Supporting Documents
```files.yaml
- File Name 1: Brief description of the file contents
- File Name 2: Brief description of the file contents
```