Zcash Integration in Coin Wallet (WebZjs + lightwalletd)

1. Executive summary and decision snapshot

Coin Wallet requests $100,000 to add full shielded Zcash support to its self-custodial multi-chain wallet across web, desktop, iOS, and Android. Proposed functionality includes Unified Addresses, shielded and transparent transfers, memos, on-device scanning/proving/signing, and operator-run lightwalletd infrastructure including a Tor endpoint. [1][4]

The named delivery team is lead developer Evgeny Vlasenko and CTO Nikita Verkhovin. Each claims 15 years of software-development experience; Vlasenko reports crypto work since 2020 and Verkhovin since 2015. [1]

The principal decision issue is not whether the proposed integration could add Zcash distribution, but whether ZCG should fund an individual multi-chain-wallet integration at this price when a recent comparable proposal was declined on the view that wallet operators increasingly have their own commercial incentive to add Zcash and can reuse previously funded web tooling. [11]

Milestone amounts, acceptance criteria, timeline, and a full budget breakdown are not available in the supplied substantive evidence. A committee comment indicates that the initial funding structure did not clearly reconcile startup funding and milestones to the $100,000 total; evidence does not show a corrected version. [5]

Inference: The request may have greater ecosystem value than a conventional wallet listing if it produces reusable mobile-integration work, reproducible WebZjs builds, upstream contributions, and public light-client endpoints as claimed. That incremental value needs specific, verifiable commitments before it can be weighed against the risk of subsidizing a wallet’s ordinary product development. [1]

2. Applicant and team track record

Coin Wallet describes itself as an open-source, MIT-licensed, self-custodial multi-currency wallet launched in 2015, supporting 23 chains according to its forum post. It states that private keys remain on user devices and that Monero is already supported. [4]

The applicant reports approximately 590,000 Google Play installs and 316,000 iOS downloads, while characterizing monthly active users as typically tens of thousands and, in some months, low hundreds of thousands. It does not track daily active users. These are applicant-reported metrics, not independently validated in the supplied evidence. [4]

The applicant also reports tens of thousands of monthly swaps, totaling millions of USD, through four in-app providers, plus six fiat on/off-ramp providers. [4]

No documented prior ZCG delivery, completed grant outcomes, code-quality assessment, security audit, or independently verified evidence of the team’s prior delivery performance was supplied. The team has a separate under-review request for $150,000 to create a pure-JavaScript Zcash library, with the same named lead and CTO. [8]

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

The proposed product scope is full shielded Zcash support: receiving via Unified Addresses or transparent addresses; shielded-to-shielded, shielded-to-transparent, and transparent-to-shielded transfers; memos; and on-device scanning, proving, and signing. The applicant says Zcash would ship on web, macOS, Windows, Linux, iOS, and Android. [1][4]

The technical approach is to integrate WebZjs rather than reimplement shielded Zcash. The applicant says its tested build supports Ironwood/NU6.3 and identifies hybrid mobile compatibility—particularly iOS and Android—as the core implementation challenge. It also proposes operating lightwalletd infrastructure, with public and Tor access, and releasing the work open source. [1]

The stated intended outputs include a wallet library, reproducible pinned WebAssembly build, upstream pull requests, public light-client infrastructure, and a mobile-device performance report. [1]

The application identifies external dependencies including librustzcash and lightwalletd infrastructure; beyond that, no grounded evidence provides a dependency-management plan, security-review plan, implementation timetable, or contingency approach. [1]

Material funding ambiguity: The request is stated as $100,000, but ZCG requested correction because startup funding plus milestone payments needed to equal that total. No supplied evidence confirms the correction or provides the resulting payment schedule. [5]

4. Community discussion, arguments, responses, and resolution

Strongest arguments for: The applicant offers access to an existing multi-platform wallet and reports a sizable user base, a large web audience, Tor usage, and existing Monero support. It projects “a few thousand” ZEC holders in the wallet within 6–12 months rather than an aggressive adoption forecast. [4] The proposal also frames hybrid-mobile WebZjs integration and reusable open-source outputs as work that may lower future integration costs. [1]

Strongest arguments against: A recent ZCG decision rejected a similar multi-chain-wallet request because members considered Zcash support increasingly necessary for wallet relevance, noted organic wallet integrations, and opposed paying separately for integrations that could use prior ecosystem-funded web work. [11] That precedent directly challenges whether the requested $100,000 represents public-good development rather than Coin Wallet’s commercial product cost.

Applicant clarifications: In response to questions about likely impact, Coin Wallet stated it has no existing ZEC users because it does not yet support Zcash, reported its broad user metrics, and set a directional target of a few thousand ZEC holders. [4]

Resolved concerns: The forum-post requirement appears satisfied through a public discussion containing a link to the application. [3][4]

Unresolved disagreement: The supplied discussion does not establish whether Coin Wallet’s claimed reusable mobile work and infrastructure sufficiently distinguish this request from an ordinary wallet integration. Nor does it resolve the milestone-payment inconsistency. [1][5]

5. Relevant precedents and documented outcomes

Zcash Support in NUFI Multi-Chain Wallet — declined, $49,000. This is the closest precedent: a non-custodial multi-chain wallet sought funding for both shielded and transparent Zcash support. The committee declined it, principally arguing that multi-chain wallets have an incentive to add Zcash organically and that prior funding of web integration should reduce the case for paying wallet-by-wallet. [11] This precedent is highly relevant to the present value-for-money question.

Zcash WalletConnect Integration — approved, $50,000. The committee approved this browser-wallet proposal partly because it expected a reusable Zcash integration layer that other wallets and services could adopt, despite uncertain immediate demand. [9] It is relevant because it illustrates a rationale for funding wallet work when reusable ecosystem infrastructure is credibly committed. The evidence documents approval but no completed outcome or impact yet. [9]

6. Material risks and execution considerations

• Public-good additionality risk: The proposal’s strongest funding rationale depends on reusable mobile/WebZjs and infrastructure deliverables, but the supplied evidence does not define which artifacts must be reusable, maintained, independently usable, or accepted upstream. [1]
• Mobile technical risk: The applicant explicitly identifies running WebZjs in hybrid iOS and Android applications as unproven work. No test results, benchmarks, or fallback plan are provided. [1]
• Security and operational risk: Shielded-wallet support includes note scanning, proof generation, signing, and wallet-operated light-client infrastructure. No grounded evidence found for security audit arrangements, threat model, service-level commitments, or incident-response responsibilities. [1]
• Adoption uncertainty: The applicant estimates only a few thousand ZEC holders after 6–12 months. This is a measured forecast, but it is unsupported by a conversion model or Zcash-specific demand evidence. [4]
• Scope-overlap risk: Coin Wallet has simultaneously requested $150,000 for a pure-JavaScript Zcash library, while this request proposes use of WebZjs. The supplied evidence does not clarify separation of deliverables, staffing, shared components, or whether funding both would duplicate effort. [1][8]

7. Material gaps and questions for the applicant

1. Provide the corrected milestone schedule: payment amounts totaling exactly $100,000, dates, concrete deliverables, and objective acceptance tests. [5]
2. Specify which outputs will be public goods: repositories, licenses, reproducible build instructions, mobile compatibility layers, benchmarks, upstream pull requests, and support/maintenance commitments. [1]
3. Explain the relationship between this WebZjs integration request and the separate $150,000 pure-JavaScript-library request, including non-overlapping work, personnel allocation, and whether either project depends on the other. [1][8]
4. Provide evidence from current prototypes showing WebZjs operation on both iOS and Android, including scan, prove, signing, memory, synchronization, and transaction-performance results.
5. State the security assurance plan before production handling of shielded funds: code review, independent audit scope, test coverage, disclosure process, and responsibility for infrastructure failures.
6. Quantify the basis for the projected few thousand ZEC holders: anticipated acquisition channels, retention measures, and what adoption threshold would demonstrate value within 6–12 months. [4]
7. Define the operating commitment for public and Tor lightwalletd endpoints, including expected availability, funding beyond the grant, and user-impact mitigation if they are unavailable. [1]

8. Neutral decision considerations

A committee evaluation can weigh the request on two competing propositions:

• Funding case: Coin Wallet reports established multi-platform distribution, privacy-oriented user segments, and a conservative adoption estimate. If the project yields genuinely reusable, open-source hybrid-mobile integration components and dependable public infrastructure, it could reduce future Zcash wallet-integration costs beyond Coin Wallet itself. [1][4]
• Caution case: The closest precedent rejected payment for a multi-chain-wallet integration on the grounds that supporting Zcash can be normal product investment and that ecosystem tooling already lowers integration barriers. The current request is more than double that precedent’s amount and lacks supplied evidence of a settled budget, measurable milestones, audit plan, or differentiated public-good commitments. [5][11]

Inference: If committee members see the principal benefit as Zcash merely appearing in Coin Wallet, the NUFI precedent weighs strongly against support. If they see the principal benefit as independently reusable hybrid-mobile tooling with enforceable open-source deliverables, the WalletConnect precedent provides a more favorable—but not outcome-proven—analogy. [9][11]

9. Numbered source list

• [1] Grant Application - Zcash Integration in Coin Wallet (WebZjs + lightwalletd) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/412
• [4] Grant Application - Zcash Integration in Coin Wallet (WebZjs + lightwalletd) — posts 1–5 — https://forum.zcashcommunity.com/t/grant-application-zcash-integration-in-coin-wallet-webzjs-lightwalletd/57469/1
• [11] Zcash Support in NUFI Multi-Chain Wallet — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/214
• [5] Comment on #412: Grant Application - Zcash Integration in Coin Wallet (WebZjs + lightwalletd) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/412#issuecomment-5542452156
• [8] Grant Application - zcashlib: A Pure-JavaScript Zcash Library — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/413
• [3] Zcash Integration in Coin Wallet (WebZjs + lightwalletd) — https://docs.google.com/spreadsheets/d/1FQ28rDCyRW0TiNxrm3rgD8ai2KGUsXAjPieQmI1kKKg/edit?gid=1164534734
• [9] Zcash WalletConnect Integration — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/391