Zcash Community Grants Meeting Minutes 1/19/2026

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: January 19, 2026

Attendance:

  • Artkor

  • GGuy

  • Hanh

  • Zerodartz

  • Decentralistdan

  • Alex (FPF resource, notetaker)

Key Takeaways:

Open Grant Proposals

  • Zcash Arabia - Q1 2026

    • Zcash Arabia is a community initiative focused on expanding awareness, adoption, and development of Zcash across the Arabic-speaking MENA region by delivering localized education, community engagement, and developer support. The project provides Arabic-language learning resources through an online academy, articles, videos, and interactive content, alongside events, AMAs, and partnerships to grow real-world usage and wallet adoption such as Zashi. In parallel, it supports developer growth through workshops, technical training, documentation, and planned hackathons, addressing the current lack of Arabic resources and low regional participation. By building a sustainable Arabic-speaking Zcash community, the initiative aims to drive long-term, organic growth and strengthen Zcash’s presence in a rapidly expanding crypto market. Applicant is requesting $7,500.

      • Gguy: We’re not going to decide on this one today. ZCG is still discussing how we can more effectively encourage collaboration between the community teams and get more value from new teams applying for ZCG funding. We will continue exploring options and hopefully have some updates soon.

      • Remains open.

  • TxGuard: Zcash v5 Consensus Branch‑ID Preflight (CLI + GitHub Action)

    • TxGuard is a lightweight open-source CLI tool and GitHub Action designed to prevent a recurring class of Zcash wallet and service failures by verifying that a Zcash v5 transaction’s embedded consensus branch ID matches what the target node expects at the current network upgrade state. By running in CI or as a pre-broadcast check, TxGuard catches branch-ID mismatches before release or transaction submission, avoiding user-blocking “can’t send” errors that have repeatedly surfaced during 2024–2025 upgrade events. Its narrow scope, fail-closed design, and CI-friendly outputs make it easy for external teams to adopt while directly addressing a well-documented ecosystem reliability gap. Applicant is requesting $21,500.

      • Gguy: This is one we’ve discussed and we’ve all voted to reject.

      • Artkor: I did not find convincing evidence that the applicant has a solid grasp of the topic they are proposing to work on. I also don’t consider this issue to be relevant or important enough for Zcash. So I reject.

      • Gguy: I think the specific solutions for each team is something that they’ll have to work through. If these teams see benefits of bringing in other teams to work on solutions I’m happy to review this one again. Until then this is a rejection for me as well.

      • Zerodartz: Also a reject from me as the team doesn’t seem to have a strong enough background.

      • Decentralistdan: Reject.

      • Unanimous rejection

  • Z3G: Zcash Z3 RPC Compatibility Gateway for zcashd Deprecation

    • Z3G is a migration-critical, operator-grade JSON-RPC compatibility gateway designed to reduce production risk as the Zcash ecosystem transitions away from zcashd to the Z3 stack. It provides a single zcashd-style RPC endpoint that preserves a clearly defined subset of the highest-demand, non-wallet RPC methods relied on by exchanges, mining pools, explorers, and infrastructure providers, while routing requests to Zebra and Zaino under the hood. By enforcing explicit, method-by-method compatibility contracts, normalizing schemas and error behavior, and shipping with regression and abuse-case tests plus secure-by-default deployment controls, Z3G makes limitations explicit rather than implicit and prevents silent compatibility drift. The result is safer, incremental migration with less integration churn, stronger upstream readiness through shared specifications and tests, and a reduced likelihood of service disruption during the deprecation of zcashd. Applicant is requesting $30,000.

      • Gguy: ZCG is going to reject this proposal.

      • Artkor: This proposal doesn’t appear to be aligned with the core technical teams of the ecosystem and as far as we know alternative approaches are already being discussed. For these reasons I reject this proposal.

      • Zerodartz: I don’t see the value for now as similar things are already planned by others.

      • Decentralistdan: reject. This type of proposal is in line with the work of the current teams working on Z3

      • Unanimous rejection

  • CipherScan

    • CipherScan is an open-source Zcash block explorer and privacy analysis platform, launched in November 2025, that helps users and developers understand and improve real-world transaction privacy. It uniquely enables fully client-side memo decryption in the browser using WebAssembly-compiled cryptographic libraries, ensuring viewing keys never touch servers, and augments standard explorer functionality with automated detection of common privacy-reducing patterns such as rapid same-amount shielding and deshielding. CipherScan also provides cross-chain visibility into ZEC flows, a robust public REST API, Lightwalletd endpoints, and a custom PostgreSQL-backed indexer to support wallet developers and researchers. With grant support, the project will expand into a Privacy Wallet Scanner with per-transaction privacy scores, real-time wallet-integrated privacy guidance via a Privacy Score API, human-readable transaction explanations, and a weekly Privacy Index to benchmark ecosystem privacy health, while maintaining free, reliable infrastructure for the broader community. Applicant is requesting $58,800.

      • Gguy: ZCG had the privilege of reviewing some of the hackathon submissions which included many block explorers. This was one of the submissions. ZCG has discussed the benefits of the project having well defined goals like exploring privacy within a user-friendly explorer. ZCG would like to see this work continue and are willing to find this project if it continues to focus on more of the user-friendly blockchain explorer features and continue to explore providing insight using the cross-chain transaction viewing with their Near integration which already exists on their dashboard.

      • Hanh: I wanted to ask them to have feature parity with the current block explorer which also means working well. They have a testnet so it’s fine. The mempool stuff was broken last time we checked and fees should be calculated properly (dunno if they are, the current explorer has some issues with them sometimes). They don’t need to have the decryption via viewing key because I think that’s broken in the current block explorer and the inbox scanner. I’m particularly interested because this code is easier to maintain than the stuff we have currently.

      • Zerodartz: I like that it’s Zebra powered block explorer and it has some features that are interesting, like privacy risks tool and privacy dashboard and stuff although I don’t consider we should fund the privacy score feature because it’s super hard for it to be accurate. But otherwise, I think they have done a good job with the explorer so far, and I’d like them to continue maintaining it.

      • Hanh: They have a list of things that are publicly available today and so I think we can remove the inbox scanner because I don’t think anybody uses that and it takes forever anyways. We can add the mempool explorer. Other than that, it seems pretty about right.

      • DecentralistDan: So we’re going back to them to tweak milestones, adding what Hanh just said, and removing the privacy score API as one of the milestones.

      • Gguy: Yeah. I’d also be interested in them leaning into some of the extra features which we haven’t seen before like the Near Intents support.

      • Hanh: There are a few additional tools in the current explorer that are nice to have, such as “decode binary tx”, “broadcast”, decode UA, …

      • Gguy: Going forward we’ll reach out to this applicant to let them know what we think their priorities should be.

      • Remains open.

  • Marketing + Workshops at Global Conferences

    • This project proposes a 2026 grassroots marketing initiative to increase Zcash awareness and adoption through sustained presence at major cryptocurrency conferences and monthly educational workshops, including outreach to at-risk populations who benefit from financial privacy. Building on proven results from DevConnect Buenos Aires and community workshops in New York City, the team will create repeated, high-quality touch points with developers, privacy advocates, and potential users while forming partnerships with aligned privacy organizations. The initiative addresses Zcash’s low brand awareness and fragmented outreach by combining conference engagement, hands-on Zashi onboarding, content creation, and long-term relationship building. By systematically engaging communities where privacy needs are highest and influence spreads organically, the project aims to measurably expand Zcash usage and advocacy within the global crypto ecosystem. Applicant is requesting $75,000.

      • Gguy: ZCG is divided about funding the full full year’s worth of conferences proposed. We would like to test this out on the proposal at one of the conferences. We will reach out and discuss if the applicant is willing to just pick one, maybe ETH Denver if that’s not too close or maybe another one just so we can test out and start gathering I guess evidence of the effectiveness of these grants.

      • DecentralistDan: And then evaluate that and determine if they should submit a full year proposal again.

      • Artkor: We highly value the applicant’s activities and consider their contributions to the ecosystem to be meaningful and yes this proposal generated discussion with the committee and while we are not supporting In this current form, we would welcome a revised submission.

      • Zerodartz: I met them in Buenos Aires and they did a good job there meeting new people and introducing and explaining Zcash and Zashi wallet. I would like to see them do as many events as possible, not sure though if all the chosen events in this proposal are the best ones that are needed. We should have more discussions with them if possible.

      • Unanimous rejection

  • Zk-Cosmwasm: A Programmable Selective Disclosure WebAssembly Smart Contract Virtual Machine

    • ZK-CosmWasm proposes a zero-knowledge verification layer for the CosmWasm smart contract runtime that enables contracts to validate cryptographic proofs without accessing or exposing private user data, bringing Zcash-style privacy to programmable, interoperable blockchains. By allowing developers to register zk-circuits on-chain and natively verify proofs within the VM, contracts can execute conditional logic based on proven statements rather than disclosed inputs, preserving full on-chain verifiability while eliminating transaction traceability and data leakage. This infrastructure unlocks privacy-preserving DeFi, identity, governance, and cross-chain applications across the Cosmos ecosystem, leveraging existing tooling and IBC connectivity while addressing the fundamental limitation of transparent smart contract execution. Applicant is requesting $500,000.

      • Gguy: This application didn’t give me any confidence that it’ll provide net benefit for Zcash, especially for the cost. This appears to be outside the scope of what might directly benefit Zcash. So given the cost and lack of specifics on how this contributes to Zcash I’m voting to reject this one.

      • Artkor: I asked clarifying questions about this request on the Forum. Given the high cost of the request and the current stage of the Zcash ecosystem the response did not convince me that this work represents a priority at this time and therefore I reject this application.

      • Hanh: Yes, reject.

      • Zerodartz: It’s a big ask and the proposal doesn’t explain the benefits for Zcashers well enough. Also very little community feedback shows it’s not in popular demand. Reject.

      • decentralistdan: reject. Not clear benefit to Zcash for the $ ask.

      • Unanimous rejection

  • State Snapshot and Fast Sync infrastructure

    • The project will build a state snapshot and fast-sync module for Zebra, the Zcash Rust full node, enabling new nodes to bootstrap from verified point-in-time state snapshots instead of replaying the entire blockchain from genesis. This infrastructure component will export, compress, verify, distribute, and import finalized chain state without changing consensus rules or protocol behavior. By dramatically reducing node startup time and resource costs, it will improve operator experience, enable efficient CI/CD and testing workflows, and support downstream analytics systems. The module will provide secure, multi-level integrity verification, a custom segmented snapshot format, resume-capable downloads, and CLI tools, delivered as a reusable, modular crate integrated with zebra-state. Applicant is requesting $30,000.

      • Gguy: I understand that there is a problem with creating fast syncing infrastructure which is beneficial in specific scenarios, mainly in testing and development, and that’s important. It’s my understanding that there are specific solutions that different teams use to achieve this but encouraging this usage more widely as this application proposes is probably not something ZCG should fund. Without greater protections, likely utilizing zero knowledge proofs, it’s hard to imagine that lessening the burden of syncing by having snapshots is good for the security of the network. So with those concerns I’m going to vote to reject this application.

      • Artkor: While the idea itself is attractive, from my perspective this approach increases centralization, making it unlikely to be included in Zebra’s automatic new-node path and therefore unlikely to see broad adoption. For this reason, I reject this proposal. And I found the alternative approach outlined by Hahn during the discussion more compelling.

      • Hanh: Well if you really want to have new infrastructure for development on demand like in Infura, they should build something different because this is not going to save much time. This is still going to take hours to boot. But the real question is do you really need to have an infrastructure like Infura since Zcash does not have smart contracts. So people don’t develop in the same way in Zcash. For most of the development, a reg test is enough and that can be started in a matter of minutes. If they want to speed up the installation of a new node they can copy from another node that they have and if they don’t have that then they should take it from a full blockchain and just wait. My position is the risk inferred by skipping a ton of checks or implementing your own checks outweighs the advantage of saving a little bit of time.

      • Zerodartz: Yes, saving time to start a full node would be nice. But for example with a slower connection speed the difference would be rather minor. This is a reject from me now, but hopefully in the future Zcash nodes can cut down in some way the sync time.

      • decentralistdan: Agreed, reject.

      • Unanimous rejection

  • Zec-Go - Independent Zcash Full Node Client

    • The project will develop zec-go, a clean-room, production-grade Zcash full node client written in Go to improve network resilience, performance, and decentralization by increasing node implementation diversity. With zcashd being deprecated and zebra becoming the dominant client, Zcash faces systemic risk from client monoculture; a single consensus bug could disrupt the entire network. Zec-go will be an independent, consensus-compatible implementation using a modular, service-oriented, library-first architecture optimized for concurrency and cross-platform deployment. To reduce cryptographic risk, all consensus-critical cryptography will be accessed via FFI to the heavily audited librustzcash library, allowing the project to focus on robust node engineering. Phase 1 will deliver a fully operational full node capable of initial block download, full chain validation, mempool management, and peer-to-peer block and transaction propagation. Applicant is requesting $1,296,000.

      • Gguy: There are pros and cons to having multiple nodes and we have very much experienced that very recently. And while I am open to the idea I don’t think that that would provide a net benefit at this point in time. I think it’d actually be a net negative for Zcash. I vote to reject.

      • Zerodartz: Right now, I don’t see the benefits but when we’re stably running on Zebra, maybe then something like this could be revisited.

      • Hanh: Yeah the full implementation would not be really a full implementation yet because they use librustzcash via FFI. The cryptographic part is not in Go. Second, they lack an audit. Without that, very few people will be comfortable using it as a full node. That’s in phase 2 & 3, and therefore is not covered by this proposal yet.
        It takes a lot of work to build a full node even for a team of experts Zcash engineers (the zebra team). So I think first of all we should have zebra work (it’s not fully ready yet) before we invest in having another implementation. At least, we would have the experience of building a full node from scratch and hopefully even some documentation regarding the pitfalls.

      • Artkor: I agree with everything that has been said, given that the Zcash protocol is currently evolving rapidly and is expected to undergo significant change. Maintaining multiple full node implementations in parallel appears premature due to the high long term costs of keeping them in sync. For this reason I reject this proposal too.

      • decentralistdan: Reject. As an Ecosystem we’re focused on deprecation of zcashd and Zebra as the single full node implementation. I would like to see that work finish and then possibly consider a new 2nd full node implementation in another language.

      • Unanimous rejection

  • Zcash block explorer by Routescan

    • Routescan.io proposes to build and operate a production-grade Zcash block explorer that supports transparent and shielded transactions, integrates viewing key–based selective disclosure, and provides unified cross-chain tracking of ZEC across EVM bridges such as Avalanche. The project addresses gaps in current Zcash infrastructure, including limited privacy feature support, lack of cross-chain visibility, and the absence of enterprise-grade reliability and documentation. Deliverables include a professionally operated explorer with 99.9% uptime, integrated bridge monitoring and multi-chain search, plus an open-source Zcash indexer and reference frontend for community use, enabling users, developers, researchers, and enterprises to interact with Zcash across its growing cross-chain footprint. Applicant is requesting $145,000.

      • Gguy: As we’ve mentioned with prior applications, we have seen an increase in the number of block explorers we’ve seen recently. In this specific example we don’t see any net benefits to paying for inclusion in other block explorers like this. We are already included in some multi-chain block explorers but the specifics for this grant application don’t fit with ZCG’s priorities or something we are willing to fund right now.

      • Hanh: Yup, pretty much it.

      • ZeroDartz: Agreed, reject for this project.

      • decentralistdan: Reject.

      • Unanimous rejection

  • Wizverse

    • Wizverse is a live, skill-based multiplayer Web3 battle game that uses NFT-based characters and on-chain rewards to provide transparent, fair competitive gameplay, while expanding its infrastructure with privacy-preserving components aligned with Zcash principles to protect sensitive player and economic data. The project addresses the common Web3 problem of exposing all activity on public blockchains by separating private gameplay and economic information from publicly verifiable outcomes, reducing data scraping and privacy risks without sacrificing auditability or trust. Deliverables include production-ready game infrastructure, open-source smart contracts, deployed systems, and technical documentation to support broader adoption of privacy-first design in Web3 gaming. Applicant is requesting $30,000.

      • Gguy: The buzz around crypto-gaming has been around for a while but I am yet to see something take off and be worthwhile funding in this way. I reject this proposal.

      • Artkor: Yes, I want to pay attention to ZCG consistently stating funding priorities do not include gaming platforms or gaming.

      • Hanh: Yeah, has very little do with Zcash, that’s the main thing for me.

      • Zerodartz: While games are fun this particular one doesn’t bring much benefits to Zcash if implemented. So I reject.

      • Decentralistdan: Reject, out of scope.

      • Unanimous rejection

Miscellaneous:

  • ZCG has approved a $2,000 hardware addition to Pacu’s grant.
9 Likes
ILE Labs: Zcash Developer Testing & Automation Toolkit - $28K Request
2

Thank you for the feedback. I’m available to discuss the revised milestones at your convenience. I also have a few questions and ideas I’d like to share.

3

Thank you for the expanded feedback, I re-submitted my application for a single event: Grassroots Marketing at ETHDenver 2026

@zerodartz I am open to a conversation with ZCG about events that would be most valuable to attend. BTC vs ETH vs mixed-chains like Consensus or other suggestions. I did the research to find major conferences, but there are hundreds to thousands of events globally. I am open to other suggestions.

2 Likes