Zcash Community Grants Meeting Minutes 6/22/2026

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: June 22, 2026

Attendance:

  • Artkor

  • GGuy

  • Hanh

  • Zerodartz

  • DecentralistDan

  • Alex (FPF resource, notetaker)

Key Takeaways:

Open Grant Proposals

  • Feature Branch Testnet and Compatible Developer Tooling

    • Dedicated testnet for NU7-deferred features (ZSA, NSM), starting single-node and expanding to multi-node, synchronized with mainnet changes. Fills the gap left by the main testnet. Requesting $455,000.

      • Artkor: I’m happy to approve this proposal in its current form. I think the committee has already done important work to clarify expectations with Qedit, especially around upstream merge deliverables, and I believe this is now a reasonable path forward.

      • Hanh: I would prefer to have to take 100k from the retroactive part and distribute it into the milestones. This would create a strong incentive to deliver on the merger. I don’t think that $200,000 accurately represents the amount of work that they have done so far. Considering that there’s no code that has been pushed back upstream and that the ZIP 248 is work very much under progress.

      • Gguy: I’ll vote to approve this grant today.

      • Decentralistdan: Approve, this proposal has undergone the requested changes after a long discussion period. I would like to see this work continue forward.

      • Zerodartz: I’m going to vote to approve although I see Hanh’s point of view and yeah it’s probably not perfect but also I’d like them to not delay this and get it done with and merge the code.

      • Approved (Hanh opposed, remainder of committee in favor)

  • Zcash Name Service

    • ZcashNames requests a forward grant to harden the trust model of their live ZNS beta, replacing keypair-based authorization with TEE-hosted minting, removing front-end key exposure, and producing on-chain cryptographic proofs of name bindings verifiable without trusting the resolver — delivered across a whitepaper, orchard fork, TEE mint, resolver, verification crate, SDKs, external audit, and mainnet launch. Requesting $92,200.

      • Hanh: There were pros and cons. Starting with the con, the protocol does not provide any strong way to verify the authenticity of the identity claim and it’s first come first serve. The lack of identity verification is both a pro and a con because then it is completely anonymous/private. The con is that anyone can go and claim, for example the ZCG identity, and if they are the first they will have it. But I still approved this grant. Originally we were waiting for the Q2 coinholder voting to go through, but it has been delayed to Q3. There’s visible community support for this proposal to justify my grant approval.

      • Artkor: I have been impressed with how quickly this team has built bridges in the technical community. I have high expectations for this work, and I hope they can find the right compromise between the two architectures. And I look forward to their progress reports on this grant.

      • Gguy: I also approve and hope that some of the more well known names are reserved for the right individuals to claim.

      • Zerodartz: I’ve already seen on Twitter some discussions they’ve had and I think they have taken some feedback and are planning to have some rules for well-known community figures and trademarks etc. So hopefully that will be smoothed out and the community has been super supportive of this project. The project is not without risks. I approve.

      • Decentralistdan: with the delay of Q2 coin holder vote, and obvious community/ecosystem support, I approve.

      • Approved async

  • Cross-Implementation ZIP Conformance Test Suite

    • Applicant requests a 6-month grant for two engineers to build a public cross-implementation conformance test suite covering five core ZIPs (ZIP-244 sighash, ZIP-225 wire format, ZIP-32 HD derivation, ZIP-321 payment URIs, ZIP-316 Unified Addresses), delivering ≥5,000 test vectors, cleanroom C++ and Rust implementations for independent cross-checking, multi-language bindings (Rust, Go, JavaScript, Python), and spec audit notes documenting discovered ambiguities. Requesting $45,000.

      • Gguy: We’ve reached out to this applicant. While we are not ready to approve this grant in its current state we are having ongoing discussions about ways that they might be able to contribute within Zcash.

      • Hanh: The reason we haven’t approved this yet is that the ZIPs that are covered are small in scope and well tested. These are not the risky ones.

      • Remains open

  • Zcash Privacy & Digital Freedom Education Initiative

    • Applicant proposes a community education initiative in Nigeria delivering physical workshops, wallet onboarding sessions, and online content to introduce students and young developers to Zcash, financial privacy, and zero-knowledge concepts, targeting 500 direct participants. Requesting $7,000.

      • Artkor: I would encourage the applicant to explore partnership with Zcash Nigeria and potentially ZecHub before submitting a separate grant.

      • Zerodartz: We already have a team who works on education and events in Nigeria, not sure more small teams is reasonable right now.

      • decentralistdan: agree, would like to see collaboration with already established teams working in this area.

      • Declined async

  • Zcash Studio

    • Applicant proposes a visual drag-and-drop development environment for building Zcash-powered applications, combining reusable Zcash-native workflow blocks, an AI-assisted natural language app builder, a sandbox testing environment, and code export to React/Next.js. Requesting $45,000.

      • Hanh: This was declined because the tooling that it offers is possible to do with standardized development tools. There are already interfaces to work with wallets using AI, and the rest of what it offers is rather standard user interface and backend services; I don’t think we need a dedicated app just for this.

      • Zerodartz: We probably just need more and better documentation for many tools and things instead of this currently.

      • Gguy: I worry about the adoption and use of this tool.

      • Declined async

  • Zallet Operability Features (Z3 stack)

    • This proposal requests a forward grant to implement three maintainer-labeled E-help-wanted operability features in Zallet: a getwalletstatus RPC method, readiness/liveness HTTP endpoints, and translatable CLI messages via the existing Fluent framework. Requesting $19,600.

      • Artkor: I believe if the applicant wants to work in this area, they should coordinate directly with the teams already responsible for Zallet and Z3. Otherwise, it risks adding unnecessary coordination overhead.

      • Hanh: Exactly. They want to work on GitHub issues and ZCG isn’t managing this project.

      • Declined

  • Z-Vault

    • Applicant proposes a local-first, client-side encrypted metadata toolkit for Zcash users — storing address labels, memo templates, recovery instructions, and backup references in an encrypted browser-based vault, with optional shielded memo anchoring for backup integrity commitments. Requesting $30,000.

      • Artkor: After their clarification, my understanding is that their MVP is a standalone manual companion app that lets users keep Zcash specific wallet metadata locally encrypted like address labels, memory templates, encrypted exports and related recovery context. I think the practical UIX would be clearer if this were tied to an existing wallet workflow. However, we are increasingly seeing standalone or third-party ideas later adopted by popular Zcash wallets. So if others on the committee see any practical volume in this MVP I will be comfortable supporting him. If not then I reject it as well.

      • Hanh: I think the problem is that the data they want to backup is private data from the wallets, and it’s not normalized. So even if they wanted it’s not clear how they would get that information. For example, something as simple as the address book of a wallet is going to be stored in the application data in a proprietary format. That’s under the application secure directory, not something that one mobile application can read from the other for obvious security reasons. So unless they have a partnership with the wallet developers, I don’t see how they can implement that stuff.

      • Zerodartz: Yeah I think it’s more likely that the wallet developers themselves will build these sort of tools by themselves and they don’t want to rely on third parties that much.

      • Hanh: Most of them don’t backup their own data so I can’t imagine them providing a stable interface for other applications to read their data.

      • Gguy: Unfortunately while there is value in the general idea, a lot more would have to be fleshed out including having a wallet ready to integrate this type of technology. I worry that wallets would prefer to use their own architectures than adopt this approach.

      • Declined

  • ZPAD-20 — Open Asset Indexing & Discovery Infrastructure for Zcash

    • Applicant proposes an open, deterministic indexing and discovery layer for application assets on Zcash — a published spec, reference indexer reconstructing state directly from chain blocks, conformance test vectors, a public read API/explorer (aggregates only, no addresses), and a ZSA-compatibility adapter — extracted from real product work on ZecPad, a bonding-curve launch application. Requesting $24,000.

      • Artkor: The core issue is the proposed assets will not be enforced by Zcash consensus. Their validity would depend on an external indexer interpreting memo data as a token-like state, which makes the system fragile and not equivalent to native assets. In my view, this is not a sound foundation for asset infrastructure on Zcash. That’s why I don’t support this proposal.

      • Hanh: Technically they are not saying they are implementing the ZRC-20 validation rules. They are doing the indexer only, which is kind of like a block explorer if you want, for these kinds of assets. The problem for me and the reason why I don’t want to approve this are because this is based on the ZRC20 inscription protocol, which is essentially Bitcoin ordinals. They don’t work with Zcash shielded transactions. In any case, ZRC20 is much less powerful and useful on Zcash than ZSA. This will not work obviously with ZSA because ZSA are shielded. Building something on a technology that goes contrary to the principle of privacy is not something that I would like to fund.

      • Zerodartz: I don’t see demand for this right now. There were some projects that used this last year but since then those projects have been silent. The developer themself doesn’t seem to have too much background, so it’s a decline.

      • Declined

  • Zcash Hostile-Companion Clear-Signing Fixture Pack

    • This proposal requests a grant to build a small open-source hostile-companion clear-signing fixture pack for Zcash hardware wallet implementations — 12 fixtures covering malformed/hostile companion app scenarios, a CLI runner, mock signer adapter, reference stub, and threat model documentation. Requesting $12,750.

      • Hanh: What they want to do is to create a test suite of payloads that should sign or not sign. I think it’s actually tested pretty well in the PCZT crate and the PCZT crate is basically a serialization transport format for transactions very similar to the Bitcoin partial sign transaction format. Therefore, the security is really coming from the usual protocol features zero knowledge proofs and signatures. I don’t think that we gain much from this because the tests are already in there and the security is not going to be tested by this either. And the third thing is it is pretty hard to automate since you require a hard wallet like a dod test to flow.

      • Declined

  • Zcash Ghana (July 2026 - September 2026)

    • Applicant requests continued funding for an active community building program launched June 2025, with documented prior delivery: 7 X-Space events, 7 physical meetups, 3 workshops, 400+ persons educated and wallet-onboarded, and 400+ X followers — proposing to continue monthly meetups, developer workshops, roadshows, X-Spaces, community challenges, and social content across Ghana. Requesting $12,600.

      • Gguy: We’ve provided positive feedback to this team in the past and I appreciate their ongoing contributions. I vote to approve it today.

      • Hanh: Yeah likewise.

      • Zerodartz: They’ve proven they can do quite well with events and I want to see them continue and grow. I approve.

      • Artkor: I’m happy to support this proposal. The team has been consistent and did a good job with the previous grant. So I’m comfortable approving continued funding.

      • decentralistdan: approve.

      • Approved

  • Formal Verification of Consensus Arithmetic and Parsing in zebra-chain

    • Applicant proposes a second formal verification engagement for Zcash — this time targeting Zebra’s consensus-critical arithmetic layer in zebra-chain: Amount monetary arithmetic (checked_add, checked_sub, Mul, Neg), CompactSize64 round-trip and panic-freedom, and Height block-height arithmetic — producing ≥18 machine-checked Lean 4 theorems via their validated Rust → Aeneas → Lean 4 pipeline, with CI-backed public artifacts and a final report. Requesting $30,000.

      • Gguy: ZCG continues to review this proposal and how best this applicant can contribute. We’re interested in exploring this a bit more and will need some more time to explore how best this applicant can contribute to the ecosystem.

      • Hanh: I think if we want to proceed with this stuff she shouldn’t work in isolation because the stuff that she proposes here are very basic primitives that I’m sure the protocol team has already done. These are very common low-level types that are used everywhere in the code whether it’s sapling orchard or ironwood or anything. Even Bitcoin has compact size. Therefore, if she wants to contribute then maybe the ZODL team would like to have an extra resource rather than somebody who works on exactly the same stuff with a totally different verification pipeline.

      • Remains open (meeting being setup)

  • Zcash Arabia (June to September 2026)

    • Applicant proposes to scale an existing Arabic-language Zcash education and community initiative across the MENA region, expanding educational content, user onboarding, and developer engagement for Arabic-speaking audiences. Requesting $16,000.

      • Gguy: I’d like to see them do more community building before they ask for more funding.

      • Zerodartz: Yeah it’s not easy. I appreciate this team’s work so far. But for me it doesn’t yet have the same growing energy behind it compared to many other more successful smaller community teams, so that is the main reason I don’t see the value of funding this team going forward. I know the region is an important one, so if there is someone out there from that region who thinks they have that sort of energy to grow the community and have done so in the past they should reach out to Zcash Arabia maybe.

      • Hanh: We funded them through May, right? We did tell them that we were not impressed and we wanted to terminate in May. So I would say that our message was fairly clear that already then we were not keen on continuing. We have told them beforehand that we were not super interested in the same stuff.

      • Declined

  • Zinfra — Sovereign Zcash Infrastructure Platform for Africa and the World

    • Applicant proposes to build and permanently operate a sovereign, on-premise Zcash infrastructure platform in Lagos, Nigeria — delivering a free, load-balanced Zcash RPC pool (zcashd + Zebra, testnet + mainnet, 100/1,000 req/min tiers) and a permanent free VPS program for Zcash-first developers, powered by a solar/wind/battery energy system on El Limited-owned premises with five-ISP MPTCP bonding. Requesting $42,003.

      • Artkor: Reference this Forum thread.

      • Hanh: First of all, his interaction on the Forum was very aggressive. Even if this goes through, it’s likely that working with that person is going to be problematic. That’s already a big red flag. Another one is that I think his proposal is not that good. It offers two things. It offers RPC for developers to try connecting to Zebra directly. But if you are a developer and you are using Zebra and you want to create an app, the number of queries that it offers is not going to help you much. If you want to scan the blockchain, it’s gonna need thousands and thousands, if not millions, of requests because the blockchain is enormous. If you want to do something that is really testing development, you don’t need all this stuff. You just run a regtestnet and you’re in charge of your blockchain. The offer here is too small. It’s larger than the other ones, true, but it’s not enough for real development. It sits at a point where it’s not useful. And the second one is the free Zcash privacy VPS. I thought that they would offer a server where the zcash stack is all pre-installed. But that’s not the case. What you get is a regular virtual machine with 200 GB of disk space. 200 gig is too small for the zebra blockchain. So, all in all, the service would have been interesting if it was designed better. As it is, I don’t see it useful for a real developer, and that is assuming that the service is going to be up, which is also a risk. I don’t have a real problem with rejecting this proposal for all these reasons. It’s not super interesting, and the execution is unclear.

      • Gguy: I’m ready to decline this today.

      • Zerodartz: The idea is actually good, but it seems too big for a start of something like that. Starting with little funds to make a prototype of this type of project would make more sense.

      • Declined

  • Zaino Release Stabilization

    • Applicant requests funding to upgrade Zaino from prototype to production-grade quality, with regular interval innovation releases and adaptive hotfix releases as the primary deliverables. Requesting $200,000.

      • Gguy: ZCG recognizes the importance of Zaino and wants to ensure this team is funded through the upcoming releases. This grant will hopefully get us to the finish line while ZCG continues to discuss the best path forward for maintenance funding in the future.

      • Decentralistdan: approve.

      • Approved

  • Zcash Türkiye 2026 Q3-4 - 2027 Q1-2-3-4

    • Applicant requests continuation funding for an ongoing community initiative (active since Q4 2024) covering regular social media content, monthly in-person activities, and educational materials for Turkish-speaking audiences, for the first two quarters of 2026. Requesting $26,400.

      • Hanh: The only question I had for now was that he said he wasn’t going to ask for funding again.

      • Artkor: There are some inconsistencies with the early self-sufficiency concept, but I checked them and I don’t think they are critical. The original Zbase proposal said we would transition to the new model in the 4th quarter 2026. In the new proposal, they are effectively asking for two additional months of funding, through November, starting in December and throughout 2027, where milestones are listed with no compensation from ZCG. So I see this is more like a two months timeline shift than a real contradiction. It still leaves questions about whether the model will actually work, but it doesn’t look like they are abandoning the early commitment.

      • Hanh: Got it, thanks.

      • Gguy: We will continue to review this grant. I appreciate the contributions this team’s made and continue to view their efforts as positive for Zcash.

      • Zerodartz: They have done a good job in the last months overall. I know they have mentioned becoming self-sustainable in the past but this proposal doesn’t explain it too well. I think the goal in the past was to find other sponsors who could fund some of the ongoing costs.

      • Remains open

  • University of Ibadan Zcash Bootcamp: Privacy, Shielded Finance, and Real Adoption

    • This proposal requests funding for a single four-hour in-person Zcash education bootcamp at the University of Ibadan, Nigeria — combining lectures, a hands-on Zingo wallet setup session, a Q&A, and brochure/gift distribution — targeting students and the surrounding community, with a two-stage pre-event outreach campaign. Requesting $13,780.

      • Remains open

  • Batch-vs-Single Verification Equivalence: Continuous Soundness Fuzzing for Zcash Shielded Verification (incl. Ironwood)

    • Applicant proposes a grant to build a continuous differential oracle for Zebra’s shielded batch verifiers, asserting that batch verification (BatchValidator) and single-item verification (Item::verify_single) always agree across Orchard halo2 proofs, Sapling/Sprout Groth16 proofs, and RedPallas/RedJubjub signatures — closing a soundness gap the current fuzz harness explicitly does not cover, and integrating the check permanently into CI. Requesting $45,000.

      • Remains open
5 Likes
2

@hanh Hello,

I’m currently not at my computer, so I will provide a more detailed response tomorrow. However, in the meantime, could you please find and share here the specific statement from my previous proposals that you believe contains the expression you mentioned, so that everyone in the community can see it?

At this point, there are two possibilities: either there is some confusion, or my previous proposal and forum posts may not have been fully reviewed.

Of course, it’s possible that something was overlooked or misremembered. However, since we are discussing a concrete statement, clarifying the exact wording will allow for a much healthier and more accurate evaluation by the entire community.

Thank you.

3

I was referring to ## **Zcash Türkiye – Sustainability and the ZBase Vision**

The primary goal of this proposal is to ensure that starting from the last quarter of 2026 (November–December), the Zcash Türkiye team transitions into a sustainable, self-financing model.

I got the timeline wrong and Arktor clarified it.

1 Like
4

Great work to the ZCG committee going through all these proposals.