Zcash Community Grants Meeting Minutes 2/16/26

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: February 16, 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. 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.

      • Artkor: I support approving the grant for Zcash Arabia. Following a meeting with the applicant and ZecHub representatives the proposal was updated to reflect the feedback received. I expect the team to deliver measurable results and contribute to the global community through close collaboration with ZecHub.

      • Gguy: I’m also happy to approve this grant under those conditions and we can review the outcomes when we encourage more collaboration between these local communities and the wider Zcash ecosystem.

      • Zerodartz: I also approve. They have become more active and responsive again. We can see how they do and then review later.

      • Decentralistdan: Approve as well. After the meeting and discussions with ZecHub and the changes made I’m going to approve for the three month time frame and then evaluate.

      • Hanh: Yes, approve as well for three months.

      • Approved (unanimous)

  • 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: We recently had a call with this applicant and they’ve updated the deliverables for this project. I vote to approve this grant.

      • Hanh: Me too. I think the modifications are looking good and the applicant is showing good response and flexibility. So far I like what’s happening.

      • Artkor: This is another example of good feedback from ZCG to an applicant that helped bring the grant proposal into desired form. Given the applicant’s high level of engagement I support approving this grant.

      • Zerodartz: I really like this block explorer and I started using it myself. They’re really responsive for ideas and updates which is a big plus and it’s working with Zebra which has been needed for a while. Approve.

      • Decentralistdan: Happy with the modifications made after feedback given, Approve.

      • Approved (unanimous)

  • Sustainability and the Zbase Vision (Zcash Turkey)

    • Zcash TĂĽrkiye seeks funding to establish ZBase, a dedicated operational structure that will strengthen the team’s capacity, professionalism, and long-term sustainability while keeping Zcash as its primary focus. ZBase will provide a stable foundation for ongoing Zcash-focused workshops, seminars, and community events, supported by limited, project-based collaborations with privacy and Web3 initiatives to generate complementary revenue without diluting priorities. Grant funds will be used to set up a small office, essential equipment, and the operational capacity needed to run regular programs and maintain a consistent local presence. This structure is intended to reduce long-term dependence on grants, improve accountability and efficiency, and demonstrate a model through which community initiatives can evolve into independent, self-sustaining contributors to the Zcash ecosystem. Applicant is requesting $31,000.

  • Mnemosyne: Thermodynamic AI Verification on Zcash

    • Mnemosyne is a Rust-native, local-first decentralized inference network that enables privacy-preserving AI computation on consumer edge devices and integrates Zcash Shielded ZEC as a native payment rail to power an anonymous, permissionless “pay-for-compute” marketplace. By executing models directly on user-owned or distributed edge hardware rather than centralized cloud providers such as OpenAI, Google, Microsoft, Amazon, Meta Platforms, Apple, and Nvidia, the project protects user prompts and data from surveillance while reducing reliance on centralized AI infrastructure. Its lightweight Rust unikernel enables efficient, memory-safe inference on low-cost devices, while a Shielded Inference Gateway embeds encrypted requests and verification data directly into ZEC transactions to create a seamless, anonymous payment and verification loop. Together, these components establish verifiable, censorship-resistant, and privacy-preserving access to AI services, positioning ZEC as a functional utility token for secure, decentralized compute rather than solely a store of value. Applicant is requesting $50,000.

      • Gguy: This doesn’t make sense for Zcash right now. I reject.

      • Hanh: Reject for being out of scope and not related to Zcash core business.

      • Artkor: This proposal didn’t receive any community feedback largely because its description raises doubts about feasibility and practical value for Zcash. I vote to reject it.

      • Zerodartz: Nothing to add, reject.

      • Decentralistdan: Reject, out of scope for funding.

      • Rejected.

  • Zcash India

    • This initiative seeks to establish a vibrant, developer-focused community for Zcash in India by delivering localized education, technical resources, and hands-on opportunities that introduce builders to financial privacy and zero-knowledge technologies. Targeting India’s rapidly growing open-source and crypto ecosystem, the program will produce Hindi and English content, host workshops and hackathons, and foster active online and in-person communities across key hubs such as Bengaluru, Mumbai, Delhi, and Indore. By onboarding developers and correcting misconceptions around privacy technology, the project aims to drive experimentation, integrations, and long-term adoption of Zcash while strategically preparing a knowledgeable local base ahead of Devcon 8, the flagship Ethereum Foundation developer conference hosted in India, ensuring Zcash is well-positioned for meaningful engagement and sustained ecosystem growth during this high-visibility global event. Applicant is requesting $10,400.

      • Artkor: Overall I like this proposal although I believe it’s important to follow a proven step-by-step path for onboarding and collaborating with the community. I hope the applicants will adopt this approach by starting with smaller measurable contributions before taking in a broader scope. I reject.

      • Hanh: I reject this particular proposal because we prefer to have them follow the same process as Zcash Arabia and approach ZecHub. This proposal is phrased as an individual endeavor and that’s why I reject it. They can adapt and try again in the future.

      • Decentralistdan: I reject for similar reasons. I’d like to see them prove themselves out by contributing to ZecHub and then potentially coming back to the table at a later date.

      • Zerodartz: Same, I want to see them start small before we start funding this sort of community proposals.

      • Gguy: For historical reference usually we like to see at least 6 months of history of contributions before funding grants like this.

      • Rejected

  • ZEX for Zcash

    • ZEX proposes to integrate Zcash into its high-performance, order-book decentralized exchange to give ZEC holders fast, private, and fully self-custodial trading comparable to centralized exchanges while preserving on-chain security. Built as a gas-free, MPC-secured DEX capable of 150,000+ transactions per second and protected by the pooled economic security of EigenLayer, ZEX combines email/web2 onboarding, unified liquidity, and chain abstraction to enable seamless trading between Zcash and major ecosystems including Bitcoin, Ethereum, Solana, and Tron. The integration will deliver native shielded deposits and withdrawals, audited infrastructure, and frictionless cross-chain access without wrappers or custodial risk, targeting $3M liquidity and 25,000 users in 2026H1. Overall, the project aims to remove technical and liquidity barriers that isolate Zcash today, expanding adoption and total value locked by providing a secure, privacy-preserving, and CEX-level user experience within a trustless DeFi environment. Applicant is requesting $75,000.

      • Hanh: It’s a reject for me because we have better solutions and this one is more centralized than decentralized and the technology doesn’t seem to be up and working yet.

      • Gguy: This problem and solution didn’t resonated with me as something that is necessary for ZCG to fund. I reject.

      • Artkor: In essence, this is a request to fund an early-stage exchange startup without demonstrated demand or a functioning market, and I don’t find that persuasive as a case for funding. I reject.

      • Zerodartz: I also don’t see much benefits so I reject.

      • Decentralistdan: Reject as well, we have strong solutions at the moment that we have supported and this one doesn’t feel like the right time or the right application to fund.

      • Rejected

  • 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.

  • Zingo Labs Hackfest

    • Applicant is requesting $25,500.23 to run a hackfest in Rome that aligns with and amplifies the benefits of ZEC Dev Summit, EuroCrypt, and ZKProof8.

      • Gguy: I think this proposal is quite reasonable and I’m looking favorably on this grant. I approve.

      • Hanh: I approve. For one week of work it’s quite reasonable and it could create significant interest. It would be good to have something with the developers probably coming for the conference.

      • Decentralistdan: Excited for this initiative and the outcomes it may produce. I approve as well.

      • Artkor: It’s a clear practical initiative with a reasonable budget. I approve.

      • Zerodartz: I also approve. The more the different teams get together and can collaborate in real life the better for Zcash and the budget is very reasonable.

      • Approved (unanimous)

  • Zcash Web Gateway

    • Zcash Web Gateway is a foundational open-source infrastructure project that removes a critical blocker to browser-based Zcash wallets by standardizing the gRPC-web gateway required for browsers to communicate with lightwalletd servers. Because native gRPC cannot run in browser environments, wallet teams today must rely on centralized hosted proxies or build fragile, one-off solutions, creating reliability, security, and decentralization risks. The project delivers a production-ready, Envoy-based gRPC-web proxy with Zcash-specific hardening, automated deployment templates, and a conformance test suite to ensure consistent behavior across operators, alongside a public registry and uptime dashboard for discovering healthy, geographically distributed endpoints. By making it easy for multiple independent providers to run standards-compliant gateways, Zcash Web Gateway reduces single points of failure, improves developer experience, and enables “web wallets that just work” while preserving the privacy and decentralization goals of the Zcash ecosystem. Applicant is requesting $25,450.

      • Hanh: The need is real. It’s true that the webZJS needs a web gateway to function properly but the proposal itself as stated is overblown and does not align with the deliverables that we need. Basically, it’s mostly dev ops and infrastructure but the proposal goes with a lot of “fluff”. It’s overpriced. Therefore I reject as stated but I hope that we see better submissions for this type of work.

      • Gguy: I agree. There is a need in this area but with infrastructure grants it’s important the team can demonstrate a proven track record of delivering. This is not only important for final delivery but also for protecting users. I reject.

      • Artkor: I just want to add. If the applicant is willing to take risk to prove it’s useful and demonstrate something that actually works then a retroactive community grant is very likely to reward whoever pulls it off. But in its current form, I reject this request.

      • Zerodartz: This team doesn’t seem good enough for this but otherwise I would be open to a similar idea. Reject.

      • Hanh: I think for any kind of infrastructure proposal or project the main issue is the reliability after delivery because we will eventually point a lot of applications towards these servers and if they mismanage, if they go away or they go down, the reputation risk is very high. We learned it with ZecWallet. We still pay the price of having users not be able to access their wallet because the domain and infrastructure for Zwallet is not maintained.

      • Decentralistdan: reject due to lack of teams track record in Zcash and potential reliance on core teams to execute.

      • Rejected

  • X402 Compatible Payment Bridge For Private ZEC Settlement

    • This project proposes a Zcash-native settlement bridge for the x402 payment protocol, enabling HTTP services, APIs, and agents to require payment via standard 402 Payment Required responses while settling funds privately to Zcash shielded addresses. While x402 defines how clients pay for web resources, existing implementations rely on transparent or custodial payment rails that leak identity and transaction metadata. The proposed bridge introduces a privacy-preserving backend that converts x402 payment authorizations into ZEC and settles them directly into shielded or unified addresses without persistent identity or address linkage. The result is a production-ready, x402-compatible monetization layer that supports micropayments, pay-per-request APIs, and agent-to-agent transactions, positioning Zcash as a first-class, privacy-first payment rail for the web and agent economy. Applicant is requesting $35,000.

      • Hanh: x402 was the web protocol for micro payments to API. I reject this proposal because we don’t have the infrastructure to leverage this protocol at this moment even for regular payments such as Bitcoin or other crypto payments, or even cash payments. This is just too early and too little support in the ecosystem for this to be valuable.

      • Gguy: Yeah I agree. I think that infrastructure and protocols for micropayments is well overdue. This is a real world problem but unfortunately until there is widespread client and server support for these types of payments it’s really hard to drive adoption. So until we see signs of adoption of a common standard I reject.

      • Artkor: I think this topic is largely hype-driven and gained traction mainly on the back of the AI agent narrative. Activity around the protocol showed an explosive start and has cooled off since, and it’s still unclear how organic this payment market actually is. If it turns out not to be overvalued, we can revisit it later. For now, I don’t see a reason to allocate community funds to it.

      • Decentralistdan: I reject as well. Although I find this use case interesting it does feel a bit early for funding for use in the Zcash ecosystem.

      • Zerodartz: It’s interesting but also reject right now. I want to see more adoption of this functionality in other protocols first. I have noticed big developments in AI agents space in last weeks.

      • Gguy: I hope we can explore grants like this in the near future, but unfortunately the industry just isn’t catching up quick enough for these types of micropayments.

      • Rejected.

  • Zcash Support in NUFI Multi-Chain Wallet

    • This project integrates Zcash (ZEC) into the NUFI non-custodial multi-chain wallet, enabling users to manage ZEC alongside major assets such as Bitcoin, Ethereum, Solana, Cardano, Tron, and EVM-based tokens within a single interface. Led by the most awarded team from the Zcash Privacy Hackathon, the project delivers full Zcash functionality—including transparent and shielded accounts, multi-account management, cross-chain swaps, hardware wallet support, and social-login wallet creation—while using grant funds exclusively for Zcash-specific development. By reducing reliance on isolated single-chain wallets and embedding Zcash into established multi-chain workflows, the integration lowers barriers to everyday ZEC usage and strengthens Zcash’s role as a practical, privacy-preserving asset within the broader multi-chain ecosystem. Applicant is requesting $49,000.

      • Decentralistdan: This one is a reject for me. I’m not interested in funding support for Zcash in another multicoin wallet at the moment. But if this team feels inclined to add Zcash to their wallet and start participating in the ecosystem, they could always come back to the table or inquire into the retroactive grant program.

      • Artkor: We’ve recently seen multiple multi-chain wallets show organic interest in adding Zcash on their own initiative including teams that hadn’t done so for years. At this point it’s clear that if you want to remain a relevant multi-currency wallet you should support Zcash. This is primarily in the wallet’s own interest. I vote to reject.

      • Gguy: I would also acknowledge that we have seen lots of wallets organically start supporting Zcash and I think it would be a disincentive for organic adsorption if we start approving grants for every wallet that requests funding.

      • Hanh: Yeah the integration is easier now then before. They plan to use the web version and we have funded the web integration to make it easier now than before. We have funded the web version for hundreds of thousands of dollars. This is an application of that grant. We made an investment to provide the platform for wallets to integrate and to avoid having to pay every wallet to integrate. Therefore it would be illogical in my opinion to go and fund integration one by one.

      • Zerodartz: I’m also not interested in funding more wallets right now that possibly have a small impact on getting new Zcash users.

      • Hanh: After all, Cake Wallet integrated for free. I don’t see why these guys would be different.

      • Rejected

  • SA-SMS: A FROST Powered Gateway for Shielded Humanitarian Aid

    • This proposal introduces Shielded Aid SMS (SA-SMS), a production-ready, FROST-secured SMS gateway that enables humanitarian organizations to distribute Zcash to individuals in high-risk, low-connectivity environments without creating centralized surveillance risks. Built on the modern Z3 stack (including Zebra) and leveraging FROST (ZIP-312) threshold signatures, the system eliminates single points of custody by splitting spending authority across multiple parties, ensuring that no NGO, gateway operator, or compromised node can unilaterally access or redirect funds. SA-SMS replaces traditional custodial SMS gateways with a threshold-authorized relay that preserves on-chain shielded privacy while enabling selective disclosure for compliance, allowing NGOs to prove eligibility and receipt to donors and regulators without exposing recipients’ financial histories or metadata to ISPs, hostile actors, or local authorities. By addressing both the internet access gap and the surveillance vulnerabilities inherent in existing blockchain aid delivery models, the project offers a scalable, accountable, and privacy-preserving solution to the humanitarian “last-mile” digital cash distribution challenge. Applicant is requesting $37,500.

      • Gguy: I don’t believe the grant should be implemented in the way described. I think there are other technologies, techniques, and solutions that are more appropriate and don’t require a grant like this.

      • Decentralistdan: This is a reject from me as well. I like the idea but I would prefer to see the Zcash Foundation continue to flesh out this their shielded aid initiative. As that gets fleshed out it will become clear to us what tools are needed and what support from the ecosystem ZF is looking for to support this initiative.

      • Artkor: Yes, I agree. Setting privacy concerns aside, I genuinely like the idea of enabling ZEC transfers via SMS in regions with limited internet access. However, I believe it needs deeper consideration and design work from core Zcash protocol developers. I’m not willing to vote for an unproven solution, even though I do like the concept.

      • Hanh: I will reject for a couple of reasons. The stuff that they mention about it fulfilling a need in cases where you don’t have an internet connection… this solution doesn’t seem to work either. Encrypted SMS doesn’t in my opinion work either in that situation because it’s not secure/anonymous enough. I think that the solution that they are suggesting here is not the right one and is pretty unsafe for what they want to do. I don’t see the benefit of funding something that in my opinion doesn’t work properly or is not secure. But if they have a legitimate problem, I think they should ask for help in designing a proper solution.

      • Zerodartz: Interesting idea, but as others said, it would need better or different solution to be secure enough. Reject.

      • Rejected

  • Zebra Fork and Reorg Observability

    • This project closes a key observability gap in Zebra by implementing the missing Prometheus metrics for fork heights and fork lengths identified in issue #5297, enabling operators to monitor and alert on fork and reorg behavior using the existing /metrics endpoint and standard Prometheus setups. The work delivers upstream metric families (histograms for recent fork heights and fork lengths, plus any needed best-chain gauges), low-cardinality and operator-safe designs, regression tests using controlled fork scenarios, and brief metric definitions with example PromQL queries. The scope is intentionally limited to upstream metrics, tests, and documentation, with no changes to consensus or network behavior, and success is measured by merged PRs and reliable exposure of the new metrics in Zebra’s production telemetry. Applicant is requesting $20,000.

      • Hanh: Yeah it’s one of these AI generated requests.

      • Gguy: There was nothing in this grant that stood out to me as overly productive so I’m happy to reject now.

      • Hanh: Reject from me.

      • Decentralistdan: reject.

      • Zerodartz: Gustavo from ZF reply in the forum thread is good feedback. Some of these are already being worked on by core teams. Reject.

      • Rejected

  • Zcash Developer Testing and Automation Toolkit

    • The proposed Zcash Developer Testing & Automation Toolkit is a comprehensive open-source infrastructure suite designed to address critical testing and deployment gaps in the Zcash ecosystem. The project delivers a four-component solution—including a shielded transaction testing library, lightweight local testnet runner, CI/CD automation workflows, and extensive developer documentation—to enable reliable testing of Sapling and Orchard shielded transactions, automated consensus upgrade validation, and reproducible local development without complex Kubernetes setups. By providing mock shielded pools, deterministic test environments, and regression and fork detection tooling, the toolkit reduces onboarding time, mitigates protocol upgrade risk, and establishes production-grade testing standards for privacy-preserving applications on Zcash. Applicant is requesting $28,000.

      • Hanh: This is a super weird one that seems to be a clone of another project that we have issues with and somehow they reopen this with different people that impersonate the other project. It’s very confusing.

      • Gguy: I was confused too.

      • Zerodartz: Some red flags. No confidence in this fresh team.

      • Gguy: This looks to be covering the work that was proposed previously in another grant that is ongoing. Given that I vote to reject. If the applicant wants to clarify their proposal and address our concerns they are able to.

      • Hanh: I’m going to reject, it’s too fishy.

      • Artkor: I’m ready to reject.

      • Decentralistdan: reject.

      • Rejected

  • 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.

      • Too early to vote
5 Likes
2

Hi ZCG,

The Zcash Community just participated in a multi-poll process. There seems to be a lot of noise that one of the micro-communities (coin-holders) are not in support of Zcash Community Assets. ZSA’s are not only funded by ZCG it is the largest recipient of funds by far over a three year period.

Can each member of Zcash Community Grants explain how the only elected organization in the zcash community have not received or missed there being no desire or use cases for what has been build?

Does this stop ZCG of current funding for ZSA?

What does it say about stacking so much resources into long term projects?

Is it a problem that Qedit did not build enough community participation into Zcash Shielded Assets?

Thank you in advance