Zcash Community Grants (ZCG) Meeting Minutes 7/20/2026

Community Grants Community Grants Updates
1

Zcash Community Grants Committee Google Meet Meeting: July 17, 2026

Attendance:

  • Artkor

  • Zerodartz

  • Paul

  • Gguy

  • Alex (FPF resource, notetaker)

Not In Attendance:

  • Hanh (voted async, comments added)

Key Takeaways:

Open Grant Proposals

  • Zcash in the privacy stack

    • Applicant proposes a six-part long-form explainer series situating Zcash within the broader privacy-preserving computation landscape — comparing shielding to FHE, MPC, and TEEs, and covering sync/scaling bottlenecks (Tachyon, oblivious sync), post-quantum migration, circuit-failure implications, and the real limits of selective disclosure for compliance — published open-access on Proof Street and mirrored to a community hub like ZecHub. Requesting $5,000.

      • Artkor: He updated his proposal. I had concerns with the broader original proposal because I was not sure how Zcash naturally fits into all of the proposed topics, but the applicant then revised it into a smaller standalone pilot with the budget reduced proportionally. On that basis, I support approving this revised pilot, mainly as an exploratory effort. I would like to see an experienced privacy-stack writer examine how Zcash may or may not fit into areas where it has not been widely represented or discussed. I don’t view this as a commitment to future work, but as a limited test of whether this perspective can be useful for the ecosystem.

      • Paul: I’m inclined to approve it given the changes in scope and I agree with in general what Artkor just described.

      • Gguy: I’m ok with that and I’d approve it too.

      • Zerodartz: Yeah I’m ok to approve just as an experiment and see how the articles turn out. Probably a good idea for ZecHub to share these articles once ready for more attention.

      • Hanh: I like the more technical approach to explaining Zcash without going too deep into mathematics. I approve too.

      • Approved

  • Offensive Security

    • Applicant proposes black-box (and optionally white-box) penetration testing of Zcash ecosystem deployed infrastructure — websites, email, light client servers (zec.rocks, Zaino, lightwalletd), CI/CD pipelines, wallets, and payment tools — plus darknet personal information searches for Zcash MVPs and employees, drawing on a proprietary 94-billion-record breach/infostealer dataset. Requesting $88,000.

      • Artkor: This proposal was well received from the beginning, although there were some requests to change its scope and structure. During the discussion, Phill understood the concerns and prepared a revised version that takes them into account. We have not funded this type of work before, so I’m interested to see what the results will be. I am happy to approve it.

      • Paul: I’m in favor of approving too. I like the way the proposal was changed to have less focus on MVPs or individuals and more focus just on general offensive security. So, I’m in favor.

      • Gguy: I agree and I’m ready to approve conditionally so long as we tidying up the milestones. I’ll reach out with feedback on adjusting the deliverables.

      • Zerodartz: I’m also ready to approve since I don’t think Zcash has anything like this on the security focus and hopefully this fills an important gap.

      • Hanh: We had a call during which we talked about an exploratory milestone. He would look for weak points while the teams are hard at work on shipping Ironwood. This is a unique opportunity to test social engineering attacks since our guard may be lower. I approve too.

      • Approved

  • Constant-Time Hardening and Explicit Timing Semantics for Zcash Rust Cryptography

    • This proposal requests a forward grant for a documentation-first constant-time hardening audit of librustzcash — making timing semantics explicit (labeling constant-time vs. intentionally variable-time paths, documenting threat model assumptions, introducing compile-time guards and regression tests) without forcing constant-time behavior universally. Requesting $10,000.

      • Artkor: I’m generally supportive of this work. I would just like to see confirmation that the core maintainers are involved and willing to review it, because otherwise the proposal would have limited practical value.

      • Remains open - waiting on feedback from core teams

  • Zcash Indexer Observatory

    • Applicant requests funding to harden and maintain a working public dashboard that monitors known lightwalletd/Zaino endpoints for sync lag, uptime, latency, and height regressions — already live with 11 endpoints, automated gRPC polling, health classification, 7-day history, and a REST API. Requesting $4,000.

      • Artkor: At first glance, this looks useful, but I become less convinced when I think about the practical side. I don’t think latency measured from a single hosting location is useful for users in different regions, because the best server in Europe may not be the best server in North America. Also, users would need to know that this separate service exists and check it themselves. I think this functionality would be more useful inside wallets, where the wallet could check several servers and automatically choose a reliable option for the user. For these reasons, I don’t support funding this proposal.

      • Gguy: I agree that the application as it stands is not something I’d like to approve. I think there is a need for accurate data to be made available to users and think ZCG should explore how best to fund and structure projects like this in the future.

      • Zerodartz: I think it’s useful to have this type of data but not specifically for end users (if the wallets auto change servers)but more like developers and ecosystem participants to see that things are actually working. We already have a similar dashboard from emersonian so I don’t see as much demand right now. I’m going to decline.

      • Paul: I also decline. We see some of this work in wallets I believe and that’s probably where it’s most useful.

      • Hanh: I think a lwd discovery service should ultimately be baked into the protocol. It would make the ecosystem more resilient. Today, the popularity of some LWD servers make them primary targets.

      • Decline

  • ZECsy Team in Amsterdam

    • Applicant proposes a week-long grassroots presence at Cypherpunk Week Amsterdam (Aug 31–Sep 6, 2026), centered on 2–3 guided evening walking tours through Amsterdam’s privacy history, ending at bars for Zodl onboarding with starter ZEC and tip-the-guide mechanics, alongside brand activation across Common S3nse (confirmed Zcash partner), Web3Privacy meetups, DashCon, and Solana Startup Village. Requesting $30,000.

      • Artkor: I liked the team’s previous events. We received a lot of positive feedback and engagement, so I support continuing this work.

      • Gguy: I also support this work.

      • Paul: I think it’s really important work reaching out to a community that has very high potential to use Zcash and that there’s not many activities like this that I’m aware of that are reaching potential users that seem to be making a lot of traction. So, I’m highly in favor.

      • Zerodartz: I’m ready to approve and they have done a good job so far. I reminded them today to update GitHub that they can work the booth at the event.

      • Approved conditionally based on GitHub update

  • Zcash Turkiye RLAY HUB Event

    • Applicant proposes a 3-day presence at Rlay Blockchain Week 2026 — technical presentation, ZODL wallet onboarding, and a 24-hour hackathon with prizes — targeting university students and developers in Turkey. Requesting $6,870.

      • Gguy: I’ve been impressed with this team and their contributions and support this grant.

      • Artkor: I’m confident in this team too based on their previous work and I support approving this proposal.

      • Paul: I support the proposal.

      • Zerodartz: My only concern is about the event itself. I don’t seem to find too much information about it. It seems like it’s a new event. I’m ready to approve.

      • Hanh: The team has delivered strong results and a low budget. I am confident that they will continue to do so with this proposal. I approve.

      • Approved

  • Zcash Explained Educational Media Series

    • Applicant proposes a 12-week Zcash educational series — 12 articles, 12 YouTube Shorts, and 4 live show segments — targeting retail crypto users through an existing daily news publication with distribution across YouTube, X, and Instagram. Requesting $6,000.

      • Artkor: I reviewed the applicant’s website and social media channels and the current reach appears limited. I don’t support this proposal.

      • Gguy: I don’t see the net benefits of funding this work so I’ll vote to decline.

      • Zerodartz: Same. There are not that many viewers and the video quality isn’t up to our standards. I’m not approving this.

      • Paul: I concur.

      • Declined

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

      • Artkor: I think there is still a gap between how this team measures success and how the committee evaluates community impact. For us, bigger numbers don’t automatically mean stronger results. Sometimes a small event with genuine discussions and meaningful engagement can be more valuable than much larger social media metrics. My recommendation would be to take some time to reflect on the feedback the committee has provided over the past several proposals before submitting another application. I think that would make future proposals much stronger.

      • Gguy: Agreed

      • Zerodartz: My main problem with this proposal is that they’re focusing only online so far. They mention now that they plan to organize real life events, but I’d like to see like a pilot from them before, could be a small local gathering by like 10-20 community members, which doesn’t need big funding. Once they can manage that, I’m ready to change my view on this team’s work and give them a new chance.

      • Paul: I like the idea of a pilot very much too.

      • Gguy: I think there are two ways ZCG can measure the impact of community grants like this. There is the only broader-reach, lighter impact community building that can occur online. And then there’s attempts at higher impact in person community building. Currently this group is focused on online community building, but it’s not clear the approaches taken are building lasting impact. I’m not ready to fund this team.

      • Declined

  • KeepKey: Orchard Shielded Zcash Signing on Hardware + Zingo & ZODL Integrations

    • Applicant requests a grant to harden their demonstrated Orchard shielded signing prototype into a production-ready, auditable product — covering firmware production hardening, mainnet validation, audit remediation, and Zingo/ZODL wallet integrations via direct protobuf transport, with the spend-authorizing key never leaving the device. Requesting $135,000.

      • Gguy: There are some concerns about the viability of the product and ongoing support for this product. Typically we don’t fund hardware wallets that don’t have an existing customer base so funding this project feels more speculative. I also have concerns that approving this grant may lead to an ongoing need for ZCG to fund ongoing maintenance work and network upgrades. I decline.

      • Paul: I agree. I think developing a hardware wallet is extremely competitive and although I very much like the idea of having something like this that’s open I believe we have to have a better plan for long-term viability and sustainability. So I’m certainly open to the idea. I just would have to have more confidence in the long-term vision.

      • Artkor: I am open to supporting this proposal because I want to see Zcash available on every hardware wallet, even if the product is still at an early stage. However, I agree with the concerns raised by the other committee members. Approving their proposal in its current form, at a higher cost than other grants for adding Zcash support to hardware wallets in a similar category, may be difficult to justify. This is especially true because those devices were also existing products before their Zcash integrations were funded. We also noticed the very low retail price of the device. This may be good for users, but it raises questions about the long-term viability of the project. So at this stage, the overall risk appears too high for approval in its current form. I hope the applicant and the committee can find a compromise. My vote in support, although in the minority, is mainly symbolic and shows that we are open to reconsidering a revised proposal.

      • Zerodartz: I’m also overall supportive of new hardware wallets and this one seems like a good one, even though it’s not that popular but at this budget I think it’s not the greatest fit. Hanh: It seems to me from their proposal and attached video, that the product is in early stage. I don’t see what it offers that really differentiates it from other popular HW wallets. I decline for now. Once they have something more production ready, it would be easier to approve.

      • Declined (Artkor in favor, all other decline)

  • Zcash Light Client Privacy Transport Library

    • This proposal requests a forward grant to build a Rust library and reference proxy binary providing privacy-aware transport for Zcash light-client lightwalletd traffic — reducing metadata leaks via Tor/SOCKS5 routing, compact-block range windowing, local caching, and request coalescing, without modifying any upstream Zcash repositories. Requesting $18,500.

      • Gguy: We have concerns around the viability of this proposal fitting in with existing tools. I think it’s better for the application developers to lead the work. Without a 0day users I’m worried the solution design won’t fit the needs of applications and lead to poor adoption. I’ll decline this proposal.

      • Artkor: I think it is clear that the ZODL team gives this area a high priority. IP hiding is already used for several sensitive network operations, and from what I have seen, they have also been working on this in their library. If anything from this proposal can be integrated there, it should clearly be done in coordination with that team. So my general recommendation is simple: if you want to improve key Zcash network infrastructure that supports a large part of the ecosystem’s network communication, make sure the work is aligned with the roadmap of the core Zcash developers. This gives the committee a reliable basis for approval. Otherwise, we risk funding something that is either unsafe to use or never used by anyone. For this specific case, I would also note that if a node operator wants to make the service publicly accessible, they should use a domain name and protect the origin IP through an appropriate proxy or protection service. This would normally provide a more stable public connection than relying on Tor. I decline this proposal.

      • Paul: That’s a great point, being aligned with core teams and community development teams. I decline.

      • Zerodartz: Idea is good to improve security, unsure about this team’s ability to make it to the end to get all the code also merged. I decline.

      • Hanh: That doesn’t bring much additional privacy considering that some wallets already use TOR/Sock5. The other improvements would do little to defeat a motivated attacker.

      • Declined

  • Zcash Onboarding @ Web3Lagos Conference 2026

    • Applicant proposes a Gold Sponsorship activation at Web3 Lagos (800+ attendees, hybrid, 2 physical days + 1 virtual), anchored by a Z3 Stack/Zingolib technical speaker session, a 2-day developer workshop with mini build challenge, a privacy panel, and an interactive developer booth — leveraging Web3Bridge’s established developer pipeline that has trained thousands of Nigerian/African developers. Requesting $8,140.

      • Artkor: After our discussion and considering the points raised, I’m ready to support approving this proposal.

      • Paul: I will support but I’m less interested in reaching the general crypto audience, web3 and others. I feel like we need to reach beyond that. So although I want this to proceed and I would like to see more of the similar approach of the ZecSy team and reaching those who are not going to be exposed to Zcash at all; those would be things that I would be much more interested in funding going forward.

      • Zerodartz: Since they have been active in Zcash I’m ok to approve it although I think the impact might not be huge I still think we should experiment and see what outcomes they can get.

      • Gguy: I agree, I see this as something that’s a bit more experimental. We haven’t funded this team or event before. I’m excited to see what impact this team can have.

      • Approved

  • FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets

    • Applicant proposes a Rust SDK wrapping ZF’s existing FROST stack (frost-core, reddsa RedPallas, frostd/frost-client) into a wallet-ready API — generate_threshold_group(), start_signing_session(), submit_share() — with session lifecycle management and network resilience patterns, so wallet teams can add t-of-n shielded custody without becoming FROST protocol experts. Requesting $22,000.

      • Gguy: Because of the complexity of using FROST and the protocol I think it’s too optimistic to believe an API can meet the specific needs of many different Zcash applications. I think this type of work needs to come from the application developers who are focused on their specific use cases and UX. My concern is that without perfect fit with developer needs this work would have low adoption and low impact. I believe for a project like this to be successful we would need to closer involvement from the application developers using this in their products.

      • Paul: I think that sums it up pretty well. I think we just need to understand that a solution like this is actually going to have a need to fulfill in users and demand.

      • Gguy: I imagine that this area will become more important in the near future as we continue to see increased Zcash adoption. FROST can provide many interesting use cases but until we get to that point in the adoption phase I believe it’s too hard to predict the exact API flows that we’re going to need.

      • Hanh: This proposal skips over the hard problems of bringing FROST to Zcash at scale. What’s the secure p2p messaging mechanism? How do participants get the tx they need to sign (securely)? How do they backup the shares? How do we recover when a participant disappears? Etc. I decline.

      • Declined

  • Pure Go Zero-Dependency Zcash Transaction Blob Parser

    • Applicant proposes a pure Go, zero-dependency library for Zcash transaction blob serialization/deserialization covering v1–v5 (v6 post-ZIP 246), with streaming parsing, comprehensive fuzz testing, and test vector validation against mainnet transactions — directly addressing the fragmented, incomplete Go parser landscape currently forcing every project to reimplement parsing from scratch. Requesting $7,200.

      • Gguy: I think that if there is a specific need for resources like this in Go there are enough resources available that make this work trivial.

      • Artkor: I don’t think funding simple libraries like this makes much sense anymore. First, ZCG has funded several libraries in the past, including for Go, and very few of them were actually used. In practice, when someone is building a real product, the lack of a library is usually not a serious obstacle. Developers simply build what they need, test it as part of their own product, and the result is normally much more useful because it was created for a real use case. Second, in the current environment, I don’t think a library at this level is worth more than about $200, basically the cost of one month of Codex Pro. Codex built a functionally similar library for me in seven minutes, and the code review took another fifteen minutes. I decline.

      • Paul: Nothing to add, I decline.

      • Zerodartz: This would have been interesting a few years ago but right now there’s enough of these already and it’s much easier for each project to implement thanks to AI help so I don’t think it’s needed as much now. Declined.

      • Hanh: Tx parsing is not very useful except for transparent data. For shielded data, the library would need to do trial decryption at the very least. By then it would have re implemented a lot more crypto. I decline.

      • Declined

  • Chadwick Bailey

    • Applicant requests funding to produce YouTube videos about Zcash, covering technical and community topics, from a creator whose channel currently focuses on geo-arbitrage. Requesting $22,000.

      • Gguy: I appreciate this applicant. We’ve seen some applications from this applicant before but unfortunately these types of channels are just not something that I think ZCG can fund for a number of reasons. There are potentially lots of channels like this and I don’t think ZCG is in a position to be funding this type of content.

      • Paul: I would definitely agree. I certainly appreciate the initiative that Chadwick has and the work he’s doing, but it just doesn’t seem right for ZCG to be funding this type of activity that, as you know, different people react to very differently. I just don’t think that there would be broad support across the community for us to be picking and choosing the KOLs that um receive the community’s funding.

      • Zerodartz: I think he is doing good job with some of the Zcash videos they have made in the past. But the current format of his videos is not the best fit to fund by ZCG in my view. I hope he continues doing what he does as he seems very passionate otherwise.

      • Declined

  • Educating Communities by Educating Their Leaders

    • Applicant proposes a structured 6-week cohort program recruiting, training, assessing, and coordinating community educators globally — using existing Zcash educational resources (Mastering Zcash, official docs) rather than creating new content, with Google Forms-based contribution tracking, performance-based rewards from a community pool, and an @ZcashCLN X account as a permanent hub. Requesting $15,500.

      • Gguy: I’m going to decline this one. I don’t think this proposal is the right fit for Zcash right now. If there is a need for this type of educational content in the future I’m open to ZCG exploring options.

      • Paul: I’m not against the concept. In order for me to feel like I could fund something around this, I would have to see that there was some success in building a community of leaders and and there was already some progress made on that and that I felt more confident that it was even possible to bring all the leaders together in a community to be prepared to consume the the materials they’re proposing to develop. So, until I see more work and building this kind of a community, I don’t think I could fund it.

      • Zerodartz: I think some things that this proposal proposes is already done or in work by ZecHub and other community groups so I think we might see something similar to this proposal come out in near future. I decline.

      • Declined

  • Turnstile Migration Integration Kit

    • Applicant proposes a forward grant to build a reusable Rust crate and CLI providing property-based tests, fuzz harnesses, and invariant assertions (value conservation, no double-migration, no stuck funds) for Orchard-to-Ironwood migration client code, plus a plain-language integration checklist and 2–3 public wallet/exchange integration reviews. Requesting $19,500.

      • Gguy: Without a developer who is ready to adopt this work I’m worried we’re just not going to see much adoption. I believe development for these use cases will come organically from application developers. I vote to decline.

      • Zerodartz: And ZODL has their own migration tool so maybe others will learn from that.

      • Gguy: I haven’t heard of a need for this solution or this SDK integration kit.

      • Hanh: There is a draft ZIP and a couple of migration design docs. I think the workflow would benefit from standardization (in the visible phase O/I), but I doubt it can be enforced by a machine/library. I decline.

      • Declined

  • Apple Silicon Zero-Knowledge Proving: Mobile Halo2 and Tachyon Acceleration on M-Series and A-Series Chips

    • Applicant proposes to port an already-proven NEON-optimized Montgomery multiplication kernel and Pippenger MSM pipeline from Apple Silicon Macs to A-series iPhones, delivering a Swift Package Manager library (FUJI.swift) with thermal-aware proving modes, integrated into the Halo2 proving pipeline via SwiftRust bridge. Requesting $62,000.

      • Gguy: Very ambitious project but as it stands I don’t think this is something that anyone is asking for. Running accelerated proving systems on this hardware is something that may happen in the future, but we should only fund this work when there is a need. I don’t think now is the right time to fund this work.

      • Artkor: I don’t think we need to rush this proposal, we should continue the discussion.

      • Zerodartz: I like this idea but I’m not sure how realistic it is or if the code they produce actually works. If someone checked and said it worked I’d be more inclined to approve but right now I’m very skeptical.

      • Artkor: I want to better understand whether the team has the technical capacity to deliver this. The proposal is very ambitious.

      • Remains open

  • Threshold (FROST) custody for shielded ZEC

    • Applicant requests a forward grant to build Ironwood-correct org-grade shielded threshold custody — COCKTAIL-DKG key generation (ZIP-2005 conformant), qsk backup/recovery, rerandomized FROST-over-PCZT signing on Ironwood, a coordinator service, and Keystone hardware integration — from a solo developer who has already reproduced the full flow on Ironwood testnet and filed the upstream signing-path fix unbilled. Requesting $47,000.

      • Remains open
6 Likes
2

Hey ZCG team,

Thanks for your hard work.

I saw the threshold FROST custody proposal stayed open, and I just wanted to check in: if there’s anything you’d like me to clarify, expand on, or adjust, I’m happy to do it.

If it was mostly a matter of time this round, no worries at all, I’ll keep an eye out for the next meeting.

Thanks either way for the consideration.