Zcash Community Grants Meeting Minutes 1/3/26

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: March 2, 2026

Attendance:

  • Artkor

  • GGuy

  • Hanh

  • Zerodartz

  • Decentralistdan

  • Alex (FPF resource, notetaker)

Key Takeaways:

Open Grant Proposals

  • Wrapped Zcash

    • Wrapped Zcash (WZEC) is a fully collateralized ERC-20 representation of ZEC designed to restore Zcash’s interoperability with Ethereum, Layer-2, and other EVM ecosystems, enabling holders to participate in lending, liquidity provision, and broader DeFi activity without sacrificing transparency or security. The system uses Chainlink’s Runtime Environment and Proof of Reserve to provide real-time, on-chain verification that every WZEC minted is backed 1:1 by deposited ZEC, automatically preventing under-collateralization, while institutional custody is provided by BitGo for secure mint and redemption operations. This trust-minimized architecture delivers deterministic mint/burn guarantees, continuous reserve attestation, and upgradeable smart contracts to support multi-chain expansion. The team is self-funding development, infrastructure, and security work, requesting $80,000 solely for essential service providers and liquidity bootstrapping to accelerate adoption, with the goal of transforming ZEC from an isolated privacy asset into a composable DeFi primitive.

      • Remains open, waiting on feedback from several parties.

  • Secure-by-Default Zebra ↔ lightwalletd: Add RPC Cookie-File Authentication Support

    • This project strengthens the security and operational reliability of Zebra ↔ lightwalletd deployments by adding native RPC cookie-file authentication support to zcash/lightwalletd, eliminating the current need for operators to disable cookie authentication or rely on long-lived static RPC credentials. The work introduces a new configuration option to read Zebra’s RPC cookie file and use it for HTTP Basic authentication, along with deterministic cookie refresh behavior on authentication failures and clear error handling for misconfiguration. To ensure durability and ease of adoption, the project includes a regression-proof CI integration test that validates a fully authenticated Zebra + lightwalletd setup, as well as updated documentation and reference deployments (Docker Compose and Kubernetes) that make secure configurations the default. Designed as a tightly scoped, upstreamable improvement with no protocol or infrastructure changes, the implementation closes a documented security gap, reduces credential risk, and enables operators to run authenticated local RPC setups using the safer, standard cookie-based mechanism already used across Zcash node infrastructure. Applicant is requesting $18,000.

      • Gguy: I’ve reviewed the implementation details, I think that this might be something that lightwalletd and Zebra team might need to do themselves. I’m not sure it’s the right time to do this without clear cooperation with that team.

      • Artkor: My current position is that it’s difficult for me to envision realistic scenarios in which Zebra and lightwalletd will be deployed separately in a way that requires a dedicated authentication scheme between them. In any case, I will prefer that change of this nature be implemented by the core backend developers of Zcash rather than external teams without a proven track record. So I reject.

      • Hanh: I will reject as well because I think this work, if it’s done by someone else, would need significant review by the authors of Zebra and Zallet and at the end of the day they will essentially do the work themselves. There is not much to outsource here.

      • Zerodartz: Agree with others. Reject.

      • Decentralistdan: agreed. reject due to reliance on core teams.

      • Declined (unanimous)

    • Laminar - The Tactical Spike: Batch Payment Infrastructure

      • Laminar, by Darklight Labs, is a local-first, air-gapped desktop tool that converts payroll spreadsheets into scannable QR codes for secure, batch shielded Zcash payments, ensuring private keys never touch an internet-connected device. It addresses the operational bottleneck of manual address entry by reducing large payroll disbursements from hours to minutes while maintaining full offline operation, standards-compliant payment requests, and zero hosted dependencies. Positioned as a “calculator, not conduit,” the project strengthens security, regulatory clarity, and institutional usability of shielded Zcash, with a roadmap toward audited, institutional-grade treasury infrastructure and an open SDK for broader ecosystem integration. Applicant is requesting $50,000.

        • GGuy: I personally don’t see this as a priority right now. This kind of fits in between solutions that already exist and I don’t currently see the benefits right now.

        • Artkor: I generally like this proposal. However, after the committee discussions, I have concluded there does not appear to be significant demand for it at this time. Recently, the community has been placing strong emphasis on demonstrated product demand. There are already custodial payroll and payout services available for Zcash. I have not seen clear evidence that this functionality is currently in high demand. So the proposal feels expensive relative to its immediate necessity. I hope the community will need to revisit this idea in the future. But at this time, I vote to reject it.

        • Zerodartz: It’s also my understanding that there is not much demand for it yet and maybe if it is needed in future it should be built into the wallets instead of having a special tool for it. Reject for now.

        • Hanh: For me, what they request in Milestone 1 is not infrastructure for batch payment but a converter between a list of payees as a CSV and converting that into payment URI. As it is this doesn’t represent the batch payment infrastructure, which would be valuable. But that’s not what it is here. I reject.

        • Decentralistdan: reject. Milestones not aligned with described infra work, and lack of clear demand for a standalone tool/product like this.

        • Declined (unanimous)

    • Incremental Contributions to the Zcash Ecosystem

      • Eryx, a worker-owned cooperative with nearly 15 years of experience in mathematics, software development, and cryptography, is seeking a grant to make their first contributions to the Zcash ecosystem by resolving three well-scoped issues in the librustzcash repository: adding a WalletRead::find_account_for_address method (#1944), fixing a bug where wallet summaries omit coins due to identical change outputs (#1964), and updating zip321::Payment::new to return a Result instead of an Option (#1794). These issues were selected in consultation with maintainers and span key crates including zcash_client_backend, zcash_client_sqlite, and zip321. The work will be delivered as GitHub PRs with automated tests, and is intended as a foundation for deeper, ongoing contributions to the ecosystem. Applicant is requesting $18,000.

        • Gguy: I’m waiting to hear more feedback on the ability for this individual to contribute and we hope to have more information soon about the feasibility of this.

        • Artkor: It would help if core backend developers flagged tasks for outsourcing so the committee could better understand priorities.

        • Hanh: This doesn’t represent a classic way to contribute to our project, an open source project. First, you learn about the project, you communicate with the moderators, with the developers, and you find bugs that you can contribute, low-hanging fruits that you can fix and get a reputation with the project. This seems to be more like trying to pick an easy task and get a grant for that. There’s no sign of added value for these particular bugs and it feels awkward. I will reject, but it doesn’t mean that the guy who submitted this proposal can’t later submit something better after he gains some reputation.

        • Zerodartz: They might actually be good developers but the proposal itself is a bit much for the proposed fixes.

        • Decentralistdan: team seems qualified to contribute but would like to see them contribute and get involved in the open source development of Zcash independently as opposed to relying on a grant as a first step.

        • Remains open

    • Incrypted Media Support in the CIS Region

      • Incrypted is proposing a localized educational media campaign to raise Zcash awareness among CIS and Eastern European Web3 audiences. The project addresses the lack of accessible, native-language (Ukrainian and Russian) content about Zcash by producing original videos, articles, and Telegram digests across Incrypted’s existing platforms. The goal is to simplify Zcash’s privacy technology for general crypto users in the region and drive broader adoption. Applicant is requesting $45,000.

        • Decentralistdan: This definitely feels like a send to ZecHub request. In my mind this is a rejection at this price but we can discuss further.

        • Gguy: I agree. We’ll get in contact with the team on next steps.

        • Zerodartz: Would want to have more community feedback on it also.

        • Remains open

    • Project Sentinel: Automated Dust Quarantine for Zodl

      • Project Sentinel proposes a “privacy firewall” for Zcash that automatically detects and quarantines malicious transparent dust to prevent deanonymization attacks. The solution consists of a real-time Risk Scoring API built on the CipherScan API and a Rust-based middleware module that wallets such as Zodl can integrate to identify, flag, and lock suspicious low-value t-address transactions before they can be inadvertently spent alongside shielded funds. Applicant is requesting $9,990.

        • Artkor: I vote to reject because I don’t consider the issue described in this proposal to be relevant.

        • Gguy: I agree. This grant doesn’t resonate with me as a current need for Zcash.

        • Zerodartz: Same, reject.

        • Hanh: This is for transparent dust, it’s not very meaningful. Anyway, if it’s really dust, the price of spending it exceeds the fee as dictated by the zip 317. Wallets typically skip over dust inputs under that amount. I think it’s a non-issue actually.

        • Decentralistdan: reject. Out of scope for current funding.

        • Declined

    • Veridex: Passkey Shielded Wallets and AI Agent Payments

      • Veridex is proposing to integrate Zcash into two of its existing open-source SDKs: a passkey wallet SDK that enables seedless, biometric-authenticated shielded Zcash wallets using WebAuthn/device secure enclaves, and an agentic payments SDK that allows AI agents to autonomously execute shielded ZEC transactions within strict human-defined spending limits. Deliverables include updated npm packages with WASM bindings, a third-party cryptographic audit of the WebAuthn-to-Zcash key derivation, developer documentation, and an open-source demo app featuring an MCP-based AI agent paying for resources with ZEC. Applicant is requesting $45,000.

        • Hanh: I would be interested in splitting the grant in 2. First one for Passkey shielded wallet and the other for the AI agent payments.

        • Gguy: I vote we reject this now and we recommend the applicant split this up into two separate grants, one for the passkeys and one for the AI agents. We wouldn’t be interested in providing startup funding. If the applicant is able to resubmit as two grants we would prefer to review these applications separately.

        • Zerodartz: Passkeys are needed. Could this team deliver a working feature, not sure.

        • Decentralistdan: reject in current form.

        • Declined (unanimous - see GGuy’s comments above)

    • Zallet ↔ zcashd Wallet RPC Equivalence Harness (Normalized Diff Reports)

      • This project builds a repeatable JSON-RPC parity harness that runs standardized wallet RPC calls against both zcashd and Zallet using the same keys and produces normalized diff reports (MATCH, DIFF, MISSING, ERROR) to identify migration-critical compatibility gaps. As zcashd is deprecated, subtle differences in response structure and error behavior pose operational risks for downstream infrastructure; the tool provides a shared, reproducible way to measure readiness, prioritize fixes or documentation, and prevent regressions during the transition without requiring strict one-to-one parity. Applicant is requesting $20,000.

        • Artkor: I appreciate the effort and the initiative to apply to our grants program, but I urge the applicant to stop here. Zcash is not an experimental playground. It is payment infrastructure that I consider part of the future of finance. I am not willing to rely on vibe-coding in this context and I would honestly feel embarrassed approving this grant.

        • Gguy: My concern is that the way that the application is described has more wording about how they’re going to achieve the goal when it feels like they probably could have described the implementation in the same amount of effort and it would have more clearly demonstrated a clear understanding of the work that’s required. I vote to reject.

        • Hanh: I reject because this submission is obviously AI generated and doesn’t show that the submitter has proper understanding of what the proposal is and how they can complete it.

        • Zerodartz: I understand it would be useful to have. The team doesn’t have proof of being trustworthy enough sadly.

        • Decentralistdan: out of scope due to AI generation proposal and lack of clarity on ability of team to execute

        • Declined (unanimous)

    • Strategic Lobbying and Community Building for the Proliferation and Understanding of Zcash in Japan

      • Fracton Ventures, a Japanese crypto incubator, in collaboration with Centrum, is proposing a two-pronged initiative to advance Zcash adoption in Japan: a regulatory lobbying effort (80% of budget) targeting the Financial Services Agency and legal experts to build understanding of Zcash’s compliance-compatible privacy features, and a community-building effort (20%) to engage developers and users. The project aims to address Japan’s historically cautious stance toward privacy coins by clarifying the technical distinctions of Zcash’s selective disclosure and ZK-SNARK capabilities within the Japanese regulatory context. Applicant is requesting $25,000.

        • Artkor: I can reach out to the applicant to verify some details.

        • Gguy: Great, thanks Artkor.

        • Decentralistdan: I’m definitely open to exploring a Japan-based community building that they touch on as the second part there. And it might end up being again like a Zechub-style collab. Question for Alex: is there a restriction on lobbying as described in this application?

        • Alex: Lobbying isn’t allowed but the applicant is actually talking about education so no issues here.

        • Zerodartz: Japan community sounds like it could be good for Zcash. Would love to have community feedback and see Zcashers from Japan comment on it (if there are any out there).

        • Too early to vote

    • OneKey Zcash Hardware Support with Unified Wallet Architecture (Transparent + Shielded)

      • OneKey, an open-source hardware wallet provider with nearly one million users across 166 countries and a recent $150M Series B valuation, is proposing to implement full Zcash support — including transparent and Orchard shielded transactions — into its hardware wallet firmware. Deliverables include firmware-level transaction signing, PCZT parsing, on-device clear signing with display of transaction details, automated regression testing, an external security audit, and a production release, all under OneKey’s existing open-source license. Applicant is requesting $45,000.

        • Too early to vote

    • Marketing at ETHCC + Exxxotica, Chicago

      • A grassroots marketing team of 3–4 people is proposing to attend two spring 2026 events — ETHCC Cannes (March 30–April 3) and Exxxotica Chicago (April 10–12) — to drive Zcash and Zodl wallet adoption through direct user onboarding, building on documented results from prior appearances at DevConnect Buenos Aires and ETHDenver. The proposal includes a potential co-booth with Bitrefill at Exxxotica, daily social media documentation of new user onboarding, follow-up outreach to 300+ existing contacts, and post-event reports tracking new wallet downloads, conversations, and partnerships. Applicant is requesting $18,500.

        • Zerodartz: We are happy with their new connections made at ETH Denver. Would love to see community feedback on this new proposal also. We are also looking into some possible future plans with them at Berlin Blockchain Week.

        • Too early to vote.

4 Likes