Zcash Community Grants Committee Google Meet Meeting: August 17, 2026
Attendance:
-
Artkor
-
Zerodartz
-
Paul
-
Hanh
-
Gguy
-
Alex (FPF resource, notetaker)
All votes this week were unanimous with the exception of Apple Silicon (3 declined, 2 passed, no approvals)
Key Takeaways:
-
Open Grants
-
Constant-Time Hardening and Explicit Timing Semantics for Zcash Rust Cryptography
- Remains open
-
- Declined
-
Zk-ComsmwasmVm + Community-Led Audit & Design Space Hackathon
- Declined
-
- Declined
-
- Declined
-
- Declined
-
Shielded ZEC Privacy and Trust Architecture Framework
- Declined
-
ELLIPAL Zcash Ironwood Shielded Transaction Support
- Approve
-
ZECsy Community Building: 12 Months of Zcash on the Ground
- Remains open
-
- Declined async
-
- Declined
-
Test-Effectiveness Audit for Zebra: an independent regression witness for consensus-critical code
- Too early to vote
-
Rvess Pay ZEC to Mobile Money Integration
- Too early to vote
-
Zcash WalletConnect Integration
- Too early to vote
-
Open Grant Proposals
-
Constant-Time Hardening and Explicit Timing Semantics for Zcash Rust Cryptography
-
This proposal requests a 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.
-
Gguy: I believe the applicant was going to attend an Arborist Call. So We will check in and see if that’s occurred.
-
Remains open
-
-
-
-
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.
- Hanh: I had a conversation with Dev from Valar Group. They are working on similar optimizations. They forked Orchard. But that raises the problem that if we approve this grant, where will it land? It’s unlikely that wallets will use it if it’s not going to be in one of the official releases. Ideally it should end in the Orchard crate, but for that it means approval and review by the core team. Or it lands on a fork and is unlikely to be used by anyone. So, I think that we still need to figure out if the gain is significant enough. Otherwise, is it worth doing all this work when we are most likely not going to see it implemented by any wallet? Essentially the chances of having PR in orchard are fairly slim. So, what do you guys think?
-
-
Gguy: I agree. I think our major concern with these types of grants is getting value with a merged upstream. At the moment it doesn’t seem likely. Unless we’re able to see this work contribute to an upstream project, then it’s hard to see where this is going to get used within an existing application.
-
Hanh: The problem is that this is going to discourage a lot of similar work. You’re basically saying that this is very, very hard to have any part of the crypto libraries modified. Which is true, but that’s not a very good message (and probably the right one).
-
Artkor: At the same time I’m also reluctant to reject it because the applicant has demonstrated a good understanding of the problem and has already invested a significant amount of time in this work.
-
Hanh: I think the work is reasonable but I’m pretty sure from experience that it’s not going to be used. It’s too hard to PR for the benefits it provides.
-
Artkor: Can they work together in this direction? Maybe they have a different approach for this work?
-
Artkor: Looks like a reject.
-
Hanh: If you want to cover our bases, we could at least ask if the core team would consider merging that into Orchard. If so, with what time frame?
-
Gguy: Let’s see what we can do.
-
Hanh: Paul, would you have a special connection for that?
-
Paul: Probably not. I don’t get involved in things like this on the ZODL side. Maybe someone can comment about what we’ve seen in the forum on this. I don’t have that off the top of my head, but unless we’re seeing traction and interest there based on everything I’ve heard in this conversation, I believe this is a rejection. So that’s where I would land. I’m happy to try to bring it up to others on the engineering side of ZODL but I think we’re having to take steps that shouldn’t be necessary if there’s community support.
-
Hanh: Yes, but I think that for these types of projects community support would be minimal because it’s very technical. It’s easier to give an opinion on something you understand, and this is hard to understand.
-
Paul: Yeah. And I personally don’t feel like I’m qualified to opine on it really. So that’s why I would say there’s got to be a better path for this to be considered by the community. Maybe it’s the Arborist Calls or some other path where this can be where this can gain some attention and get some consensus before it gets funding.
-
Hanh: Ok what I hear from you maybe the path forward is to have this person attend the Arborist Call like the other technical proposals we’ve been on the fence about.
-
Artkor: To be honest we’ve already reached out to people that do this work but they weren’t interested in this proposal. Dev’s team.
-
Hanh: Yeah, that’s not absolutely fair though. Somehow they could have a conflict of interest. They work on something similar.
-
Artkor: But they don’t want funding for this work.
-
Hanh: They can apply later on a retroactive grant or something. The ask is fairly reasonable if the value is there. There are two values. There’s an immediate value which is speeding up proving and verification on Apple silicon and that’s like today right about 30 to 50% faster. And the second thing is you’re giving a message that you’re accepting contributions from technical people regardless of where they come from. And the other problem here is that if you don’t, then it means anyone will have to go through approval from the core team.
-
Gguy: I think it’s worth exploring this one a bit more.
-
Hanh: So are we still on the Arborist suggestion or do we think he won’t want to do that?
-
Artkor: I have already suggested he go to Arborist Call but he said that his English is not good for this.
-
Hanh: In that case, it gives us another reason to reject. It’s technical but also has logistics and teamwork elements. This proposal has to fit all aspects, but it’s not strong enough from a technical perspective to overcome limitations.
-
Paul: Sounds to me like what would be very helpful here is for this individual to have a partner, a colleague, someone to help navigate our ecosystem a little bit better.
-
Hanh: Seems like it’s a reject?
-
Paul: It is for me, yes.
-
Hanh: I’m ok rejecting.
-
Gguy: I’m not going to vote to reject it today. We haven’t reached out to ZF yet, that would probably be the last attempt.
-
Hanh: ZF wouldn’t help them much because even with ZF support they can’t be added to Orchard.
-
Zerodartz: I’m ready to reject today because otherwise it’s just going to stay open. I do like the idea of faster proofs, but if there are also others working on similar speed improvements now, it will be hard to get this work merged and used by everyone.
-
Paul: I reject
-
Artkor: I pass
-
Hanh: I reject it because I don’t think it’s going to change.
-
Declined (3 to 2)
-
Zk-ComsmwasmVm + Community-Led Audit & Design Space Hackathon
-
Applicant requests a grant to extend CosmWasm with multi-curve Halo2 proof verification, modular verification-key storage, and IBC light clients tracking Zcash under Crosslink hybrid finality and PoW confirmation depth, enabling Zcash-native cryptography and headers to be used in CosmWasm smart contracts, DAOs, and cross-chain applications. Requesting $230,000.
-
Gguy: I’m not convinced with the end to end projects that were proposed. I’m happy to explore this again at some stage, but the times when ZCG receives the most value is when we do have those end-to-end projects that users can actually start to use in meaningful ways, but I just haven’t seen the interest in that as of yet. So, today this will be a reject, but happy to explore in the future.
-
Paul: Same here.
-
Artkor: I agree, I’m not negative on this direction but I still don’t see a strong reason to fund it now. My impression is that this proposal may be part of a broader project and I may be missing some of the context needed to understand how this module is expected to be used in practice because of that I don’t feel I have enough information to approve it in its current form. At the same time I respect the work already done and remain open to supporting retroactive funding in the future If this module of this direction proves useful in practice and brings clear value to the Zcash users.
-
Zerodartz: I would also agree that the current practical value is hard to see for Zcash, but there might be some cool use case in the future, but yeah, currently I don’t think it’s the right time for this. So, I reject.
-
Declined
-
-
-
-
Applicant requests funding to expand a self-funded, already-live Mumbai light client endpoint (Zebra archive + lightwalletd, TLS, client IP logging disabled) into a maintained multi-region Asian network with reproducible benchmarking, public health monitoring, and wallet integration support. Requesting $32,000.
-
Gguy: As it stands for me, ZCG has received a couple of these region based applications for infrastructure type applications. We would like to explore this more. We think that it’s important. We think that decentralization is important. And I would like to explore something that is more structured so that we can support infrastructure across the ecosystem rather than single projects. So I will start exploring how we can do that. That does mean that today I’m not ready to approve this application.
-
Hanh: Likewise. I think this is very critical and even more important now than ever to decentralize the light wallet infrastructure. For instance, I would welcome a framework of discovery of nodes as well as a platform for registering and adding independent nodes because I feel like today the dominance of Zec.rocks is too high. It’s good to have something that is reliable like that and we made great progress since like a year or two ago where we only had a handful of servers. I am grateful for their work. It was needed. But I think that we have traded reliance for centralization, and now we’re very, very dependent on the zec.rocks servers. Um, so I personally think that ZCG should invest quite a lot into this, like hundreds of thousands of dollars easily, to build something that is future proof. I will reject this one, but because I think this is not ambitious enough.
-
Paul: I very much like that framing and that we need a very ambitious way to attack the challenge of this. And I think that also applies to some of the other topics for grants that we’re going to be discussing and considering today is that they’re important, they reflect some very large challenges and in some cases I think maybe we will proceed and make small progress where we can. I think I’m falling on the side of we need to first figure out a bigger approach before we fund the smaller efforts.
-
Artkor: I just want to note that this team from India has been very active and their work has not gone unnoticed. We value this kind of approach, where community members look for different ways to contribute to Zcash and I hope we can find a structure that works well for everyone.
-
Zerodartz: I would say it’s a good team so far and it’s a good idea but maybe the proposal itself is not the right fit right now. Lightwalletd nodes are crucial part of Zcash infra so we should fund this sort of projects but we need to figure out a better framework that makes sense for more communities to run servers.
-
Declined
-
-
-
-
Applicant requests a grant to build a production-grade, audited Rust library and TypeScript/WASM SDK enabling VASPs to reconcile shielded ZEC activity against KYC’d accounts, with pluggable AML screening interfaces and IVMS101 Travel Rule record construction — addressing the compliance gap that drove 73 exchange delistings in 2025. Requesting $17,500.
-
Artkor: I don’t see a clear demand for a general purpose solution of this kind. In my experience, compliance integrations are usually shaped by the requirements of exchanges or institutions that will actually use them and teams often build much of the surrounding infrastructure themselves. There are also still no common standards or approach in this area. In many jurisdictions the regulatory framework is still very basic and does not address the specific differences between blockchains in much detail. While at some places there is effectively no clear framework at all. Without a specific partner asking for this approach I’m not convinced that the proposed solution will be adopted in practice. For that reason, I don’t support funding this proposal.
-
Paul: I would agree that Artkor really nailed it and that for something like this we need to know that there’s going to be demand for it and it has a partner and it’s going to be using it. So I would reject.
-
Zerodartz: I think it’s not the right fit right now. I reject.
-
Declined
-
-
-
-
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 $27,000.
-
Gguy: ZCG is funding many community groups right now and unfortunately we can’t fund all community groups and this one is a reject from me.
-
Artkor: I appreciate that the team has continued trying to build activity around Zcash in the region, and I do not want to dismiss that effort. But I want to be honest. This has become a difficult case for me, and I am not sure where I stand today. On the one hand, addressing individual concerns raised in our previous reviews does not by itself give me confidence that the community activity is sustainable and organic. On the other hand, I also do not want our previous rejections to become, in themselves, a reason to reject the proposal again. At this point, I think broader community feedback would be especially useful. If people believe this team should receive continued support, I would encourage them to express their support publicly.
-
Zerodartz: I agree. The team has shown they can make stuff happen but its efforts have been quite uneven over time. This team’s work has not gone unnoticed. But there has been very little overall support shown from other Zcash communities for this community project until now. Building a strong and active community is very hard.
-
Declined
-
-
-
Shielded ZEC Privacy and Trust Architecture Framework
-
Applicant requests a grant to produce a public privacy and trust architecture framework for shielded ZEC consumer applications — comparing browser-local, provider-assisted, and off-ramp-coordinated patterns across trust-boundary matrices, data-flow diagrams, security assumptions, and a U.S. legal issue map reviewed by qualified digital-asset counsel. Requesting $49,500.
-
Artkor: I don’t support this proposal. I have not been able to identify a clear practical need that this framework would address for Zcash or how its deliverables would be used in practice. I reject.
-
Gguy: I also haven’t seen much interest or need for this proposal so I reject.
-
Zerodartz: I don’t see enough value from this project right now. I reject.
-
Hanh: Same here. Quite a lot of buzzwords and not too much feedback from the community. No interest from either wallet developers, exchanges or users so hard to see who would use.
-
Paul: I reject it based on that rationale.
-
Declined
-
-
-
ELLIPAL Zcash Ironwood Shielded Transaction Support
-
Applicant requests a grant to add Ironwood shielded transaction support to its TITAN air-gapped hardware wallet (QR-code-only communication) and companion mobile app, covering firmware Pallas/RedPallas/ZIP-32 integration, PCZT parsing and clear signing, UFVK export, and full mobile app flows for shielding, deshielding, and fully shielded transfers. Requesting $95,000.
-
Gguy: We’re leaning positive on this. Initial thoughts?
-
Artkor: Some time ago, I wrote on Twitter that many of the best technologies enter our homes without us really choosing them. We, as users, do not always decide which technologies we will use. Sometimes they simply become part of the devices we already use. Today, the community has given me an opportunity to help bring shielded Zcash to some of the most popular devices. I know that these hardware wallets have strong sales in a number of regions. For that reason, I support this proposal, and I would like to thank the team for taking this step.
-
Gguy: Despite our previous attempts funding to get shielded support on hardware wallets it’s a hard task to do. So I would support this team in making those efforts to get Ironwood support.
-
Zerodartz: I’m ready to support this since Zcash right now is only on one hardware wallet and we probably will have more soon and we need to have more even though I’ve become more skeptical about hardware wallets lately since a lot of data leaks have happened. I still think some people who already have those wallets would benefit from having the opportunity to use shielded Zcash directly. I will say that probably in the future we will not be as open to supporting more hardware wallets since most of the top ones should already have Zcash support.
-
Paul: I would agree with that thought. If this proceeds it’s a relative modest ask compared to some of the others we’ve seen for hardware wallet integration. So, I’m willing to vote in favor of it, but I’m very skeptical in general of funding these activities for entities that are in the business of providing such hardware to customers for their own profits. it just something about that doesn’t make a lot of sense to me. And they should be able to justify investments like this without being subsidized in my opinion. But I would in this case let it go.
-
Hanh: I agree that it’s pretty high for something that has been done by Keystone. It’s a similar design to Keystone. It is going to be no USB, no Bluetooth and exchange via QR codes only. That’s the model of Keystone. I hope that they’re going to use most of the code that has already been written. The ask, even though it’s not astronomical, seems to be higher than necessary. Plus it seems like we shouldn’t have to subsidize the entire work anyway. It seems like we’re actually paying more than it costs. To me a more reasonable ask would be around 30 to 40k, but on the flip side, this is a very popular wallet. It’s not the top one, but I think it’s in the top five. And I also agree that eventually I think we would have to stop funding all the hardware wallets out there. But if we have funded Keystone, this is more popular and very similar to Keystone. I don’t really see a reason to stop now. I hope that after Ledger we will have Trezor and then we can stop funding hardware wallets. But I approve this one.
-
Approved
-
-
-
ZECsy Community Building: 12 Months of Zcash on the Ground
-
Applicant requests a 12-month full-time in-person events program (September 2026–August 2027) — committing to a rolling cadence of 8 mainstream crypto/tech events, 4 adult-industry activations (Exxxotica circuit, AVN, interNEXT), and 8 weekend workshops, with a 4-person field crew, apprentice training program, flexible city-specific side events, and a standing feedback channel routing real-world user problems back to ecosystem teams. Requesting $588,000.
-
Gguy: There are a lot of positives with this grant application. I like the clear ambition and direction and leaning into problems that actually need to be solved in the real world. Having said that, I do have concerns about the mix of events that have been listed. There are a lot of generic Ethereum events among others. So I would encourage the team no matter what the result today to lean in towards the industry focused events. So I’m not quite ready to vote today based on those issues. But is anyone else ready?
-
Paul: I’m ready. This is what I alluded to earlier where I think we need better structure around activity that would be a larger program. In this case, I really do agree that I’m not thrilled about the mix of events that have been put forward. But there’s a lot of work this team is doing that is extremely valuable in my view and I think it’s worth that investment to encourage them to do what they see as required to ensure they’re they have the right credibility and experience to proceed with the work that they focused on in the adult industry. So, I’m in favor of giving this the funding to proceed even though if I were putting the proposal forward, I would have done it probably a little differently, but I think it’s important work that we need to support. And I also just want to note that the community support that I’ve seen has been very strong. So that really does affect my thinking on this.
-
Artkor: 100% agree, I see clear value in the work of this team and the level of community support is meaningful to me. At the same time the current proposal is very broad and I’m not comfortable approving the full scope as submitted. I will prefer to identify the parts of the program where the expected value is clearest and work these the team on a more focused structure rather than reject the proposal outright. At least this approach worked well for us in the past and the positive community response suggests that the results were quite impressive.
-
Hanh: My point of view, it’s clear the team is well-liked by the community and they have the support of many known community members. They have good results, they’ve connected with a bunch of people. I think the quality of their work is pretty high. That allows me to identify two things that I think they are doing very well and things that they are not doing as well. So the stuff for me that went very well is the web zero stuff. Well it’s not technically their stuff, but they participated, and it shows that if you have an event that is branded with Zcash and it’s entirely Zcash, you make more impact than if you go to an Ethereum convention and you have your booth and you talk to people who walk by. So I would like them to do more of that. Second thing is when they are also the only ones who engage. For example, when they were at Exotica in Chicago they had ~700 conversations. I think that’s their highest success so far. I would say that we should separate the events that have high value, like these ones, from the ones that have lower ROI like the ETH stuff. That would reduce the budget allocated to travel and of course accommodations, but more importantly, refocus the efforts where they are more impactful. I would say that we asked them to focus on the four adult industry events for a total of 60k. Then we do a few mainstream tech events. We keep the workshops and for the local events we ask the local community to engage to send their people so that makes the entire stuff a bit cheaper, not really like just 100k. What I’m trying to say here is that the budget is not that different. It’s just restructuring the ask so that it becomes more productive. We keep them on the same retainer; basically, their pay is the same. It’s still a full-time job for Milo and his team for 160K, but we ask them to focus more on the adult stuff and reduce the trips. That would be my counter proposal. Plus, every quarter we can reevaluate if we’re making progress because the big question here is whether the adult stuff is working out. Not so easy to figure it out but worth a shot. What do you guys think?
-
Gguy: I agree. Having a clear focus seems to drive outcomes and if we can make that proposal stronger. I think that will lead to better outcomes.
-
Zerodartz: Yeah I agree with most of your points. I think the best course forward is to have a call with them to make some adjustments. I do think clearer focus on the adult events and workshops is likely more effective way to go for this team.
-
Remains open
-
-
-
-
Applicant proposes to establish a permanent physical community hub in Brussels — a walk-in space for support, training, and meetups — paired with ULB campus visits, city outreach, and business/merchant engagement, with supporting materials already produced (podcast, GitHub documentation, handbook preview). Requesting $36,305.
-
Artkor: I think Batuhan already gave the best recommendation in the forum thread and I agree with his advice.
-
Gguy: I think building contributions within the community first before applying for a grant is a good idea.
-
Zerodartz: There’s no clear Zcash history for this applicant yet. Start with small contributions and work slowly on building a small community first is the best way. Reject now.
-
Declined async
-
-
-
-
Applicant requests a small starter grant to stand up and operate an independent Zebra + Zaino light-client endpoint in Singapore (asia-southeast1), operated from Nepal, with a public verifiable status page, fully reproducible open-source deployment, and quarterly forum transparency reports. Requesting $5,760.
-
Artkor: I agree that we should move away from funding individual nodes separately and instead propose a fair and scalable incentive system for this kind of infrastructure across the community.
-
Gguy: Given the multiple applications we’ve received in this area it’s best to think of a way to fund these more broadly.
-
Hanh: It falls under the same category as the light nodes grant we discussed earlier.
-
Gguy: This one will be rejected today but we’ll be happy to hear back from the team when we find an approach that can fit more broadly across these teams.
-
Declined
-
-
-
Test-Effectiveness Audit for Zebra: an independent regression witness for consensus-critical code
-
Applicant requests a forward grant to build a targeted mutation testing layer for Zebra’s consensus-critical code paths — using operators derived from real Zebra defect shapes (not random mutation), manual adjudication of surviving mutants, and a verified negative-control regression test for every confirmed gap, specifically addressing the pattern of test-exists-test-passes-defect-recurs documented in four Zebra security advisories. Requesting $45,000.
- Too early to vote
-
-
Rvess Pay ZEC to Mobile Money Integration
-
Applicant requests a grant to add Zcash shielded payment infrastructure to an existing Cardano-piloted mobile money off-ramp platform, targeting KES, UGX, and TZS payouts via Relworx, with a Rust scanning service consuming compact blocks via lightwalletd, diversified Unified Addresses per quote, ZIP-321 payment URIs, and an idempotent state machine — with real-fund launch conditional on provider approval and KYC/AML controls. Requesting $32,000.
- Too early to vote
-
-
Zcash WalletConnect Integration
-
Applicant proposes a browser wallet for Zcash with WalletConnect v2 integration — enabling wallet discovery, QR code/link connections, and shielded transaction signing from dApps — plus Zcash lending as a planned ecosystem feature. Requesting $50,000.
- Too early to vote
-


