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

Community Grants Community Grants Updates
1

Grant Dashboard

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

Attendance:

  • Artkor

  • Hanh

  • Zerodartz

  • Paul

  • Alex (FPF resource, notetaker)

  • Not present:

    • Gguy (voted async)

    • Paul (joined late, voted async)

All votes were unanimous except for Formal Verification which Artkor approved but the other members rejected.

Key Takeaways:

Open Grant Proposals

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

      • Artkor: Committee members, in particular Hanh, have done a substantial amount of analysis on this proposal, both on its own merits and in the broader context of formal verification for the Zcash protocol. The most important signal I think we should send to the community is that the committee takes this area of work very seriously. We are not moving away from the view that formal verification is important and, in the long term, necessary for Zcash. However, we have come to the conclusion that the usual model, where the committee receives a standalone proposal for a defined piece of work, may not be the most effective way to approach formal verification of the code paths that define Zcash protocol behavior. This is an extremely large area of work, and the tools needed to perform it at the required depth are only beginning to emerge. In addition, the core protocol developers are already actively working on this broader direction. For that reason, we believe that formal verification of specific components should ideally be initiated and scoped by the Zcash protocol development community itself, as part of a wider roadmap for this area. The committee remains open to funding this direction when the work is clearly aligned with that roadmap and with the needs of the core developers. Without that alignment, there is a risk that formal verification efforts remain isolated, narrowly scoped, and limited in their practical impact. We are grateful to Runtime Verification for submitting this proposal, and we recognize their expertise and experience in this field. I already understand that a simple majority of the committee will decline this proposal. So my vote in favor should therefore be understood as symbolic, and as a gesture of appreciation to the applicants for bringing this work to ZCG and helping move this important discussion forward.

      • Hanh: Just a couple things to add to this. The grant specifically is about using a tool to reverse some rust code functionality from Zebra into Lean 4 model and use another tool to prove the validity of the Lean 4 model. The idea is sound. However, the problem is that the tool is currently very limited and it’s unlikely that it will get better anytime soon. It’s only able to reverse very basic functions, a maximum of like 10 lines. Functions are isolated, no dependency and purely arithmetic functions. Therefore, the proposal is limited to very small parts of the protocol that we don’t feel (and by we I mean ZF engineers and myself), have risk of being wrong. Therefore the idea is good but it’s just that the execution is too limited. It may even give a false sense of security because the amount of code that would be checked is rather minimal (less than 1% of the code base). The cost is very high too. it would be $30,000 for a few lines of code, and that would be phase one. The entire grant is eight separate phases. The other seven are not costed, but if we interpolate it would be $240,000. At the end we would not be better off than in the beginning because this approach doesn’t scale to any other part of the system. So good idea but unfortunately the execution and the tooling is not powerful enough at this time. I have to decline. If you want a short summary, this is like saying this is a self-driving car, but you can only drive in a straight line.

      • Zerodartz: The idea is good and formal verification is very necessary now and in the future. But as I understood others feedback and ZF developers then this will not be that impactful and given that I’m going to decline. I’m open to have this team work on something that the majority of core Zcash developers would find the most valuable that isn’t being worked on right now.

      • Paul: I second Artkor’s comments. I would like to see activities that drive better community understanding of formal verification including how it can be applied across the core libraries. My sense is that formal verification is important, but I want to see efforts to identify where the areas of focus should be and ensure the work is prioritized correctly for the greatest benefit. Having formal verification included in a broader roadmap would be very helpful.

      • Declined

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

      • Artkor: I think this is an excellent team with strong leadership. I’m looking forward to hearing their updates to the community once they enter the self-sustaining phase, especially what they learn from continuing their work without ongoing grant funding.

      • Zerordartz: The Zcash Turkey team has proven that they can organize and participate also at offline events which is becoming more valuable and they have built a nice team so far that’s becoming more active. I think they’re on a path to becoming one of the strongest forces close to the Europe area for Zcash and they’re maybe following a bit similar path as Zcash Brazil and they’re bringing more and more value to Zcash. I approve.

      • Hanh: I approve as well. They’re following their plan of delivering value to Zcash in Turkey and I think they’re on track to being independent next year or at the end of this year.

      • Approved asnyc

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

      • Hanh: It’s a continuation of a grant for fuzzing that was delivered a while ago. The applicant found some valuable and serious bugs in Zebra. Therefore, based on the success that the project had, we feel like it’s worthwhile to continue, especially since batch processing and batch verification are areas that are typically pretty hard to test because of the asynchronicity and the race conditions that can happen.

      • Zerodartz: I don’t have too much more feedback but I want to see them continue to improve Zebra.

      • Approved asnyc

  • Zenith Full-node Wallet 2026

    • Applicant proposes to add three protocol-level features to its full-node wallet: FROST multisig support via distributed key generation, dynamic network fee adjustment for congestion handling, and Ironwood shielded pool migration support. Requesting $122,600.

      • Artkor: As I understand it, this proposal does not currently have sufficient support from ZCG for several reasons. First, the committee generally does not want to encourage separate grant funding for support of mandatory protocol upgrades, such as the upcoming Ironwood work, because that type of development is part of maintaining the normal functionality of a wallet. Second, it seems that we are all expecting a significant architectural shift with Tachyon. That raises questions about whether the remaining useful lifecycle of today’s full-node wallet model is strong enough to justify allocating community funds to this work at this time. Personally, I am interested in supporting more advanced functionality such as FROST, as well as other experimental wallet features, but only when the work is clearly reusable and broadly applicable across the Zcash ecosystem. For this proposal, my vote is to decline.

      • Zerodartz: My main concern is that this wallet doesn’t have many users as far as we know. And yeah, full wallet nodes are not the most popular for most of the community. There’s just not enough value right now for us to fund it sadly.

      • Hanh: Likewise, I would say that the wallet has a fairly low number of users. It’s not particularly a user-friendly wallet in my opinion. That could be excused by the fact that it’s a full node wallet. So it implies the installation of a full node Zebra. The second aspect is that I’m okay with wallet developers charging some maintenance for network upgrades but I think that the amount requested here is disproportionate compared to the amount of work and the value offered. The only thing that is different from the other wallets is the support for FROST and it seems that their implementation is not necessarily better than what is out there. Also it would tie the users to their platform. It’s mainly a problem related to value delivered and cost that I decline.

      • Declined

  • red·bridge Launch

    • Applicant requests funding to complete final-phase work on a decentralized, community-owned bridge for moving ZEC into and out of the broader DeFi ecosystem — covering marketing/launch, Swiss legal compliance and entity operations, and continued stewardship of Webzjs (including its MetaMask Snap), building on prior funding from ZCG, the Avalanche Foundation, and the founder. Requesting $477,658.

      • Artkor: This grant allows the team to finish the work already started with red-bridge and move it from the software-building stage into the launch stage. In addition, the team is taking on maintenance of the MetaMask Snap and the supporting WebZjs library, which are directly relevant to red·bridge operations and useful infrastructure for the broader ecosystem. After some revisions to the structure, we approved it on Friday.

      • Hanh: We approved because this is the last effort before releasing this major endeavor. We asked the grantee to move the funding that was made monthly into milestones and turn it into an independent contractor agreement. So this will be heavily tied to delivery. We are not going to pay that much unless the grantee delivers on everything that was listed here. This may sound like a lot, but there’s a lot of content in there. And this is essentially a max amount.

      • Zerodartz: The grant seems really big at first but there are a lot of parts to it and one of the main problems we had in the last year was the Metamask Snap and the WebZjs maintenance which was slower fixing bugs than would be ideal. Recently Red Bridge team came in and asked to help with some of that work and they have already fixed some stuff and they’re now taking over the maintenance of it. Also the red bridge is a good alternative for Near Intents in the future when it launches and I’m excited to see it in action soon.

      • Paul: I am in favor of giving this team the resources necessary to get this work to the finish line. DeFi capabilities have proven incredibly important for Zcash over the last year, and we need more as fast as possible.

      • Approved async

  • ZKPay Campus

    • Applicant proposes a mobile, non-custodial Zcash payment app for Kenyan university campuses, defaulting to shielded transactions via QR codes (ZIP-321), with offline transaction signing to handle unreliable campus connectivity, piloted at one or two universities with structured usage data collection and an open-source release. Requesting $13,500.

      • Artkor: The main issue is the offline payments claim. Without a network connection, we do not see a credible way to prevent double spending without introducing trust. This proposal does not give us enough confidence that it can solve that problem safely. For these reasons, my vote is to decline. I also disagree with the premise that existing Zcash wallets are too technical for regular users.

      • Zerodartz: I agree with Artkor. There is no point for us to fund this.

      • Hanh: It makes very bold claims about the state of the ecosystem and their ability to deliver alternative solutions. But the claims are not substantiated by facts or by design documents either.

      • Declined

  • zaino - Stability, Performance & Testing

    • This proposal proposes replacing Zaino’s manual locking and deep-clone snapshot pattern with compiler-enforced immutable persistent data structures (HAMT-based Phm and persistent deque HeightDeque), eliminating the compare-and-swap ceremony and snapshot inconsistency risks, alongside performance improvements (lock-free reads, O(1) ingestion) and a four-tool testing suite for reorg and load behavior. Requesting $50,000.

      • Hanh has recused himself from discussion or voting on this proposal.

      • Artkor: From my perspective, this proposal supports Zaino as a critical part of the post-zcashd light wallet infrastructure. Although ZCG has already funded broader Zaino development and release stabilization, this proposal is more specific. It focuses on stability, performance under load, reorg handling, and testing inside Zaino itself. I do not see this as duplication. I see it as practical engineering work that helps move Zaino closer to reliable production use. I also want to note that the forum thread for this proposal includes a one-hour video with a detailed explanation of the work. My vote is to approve.

      • Zerodartz: I’m also happy to approve since Hahn already communicated with the zaino team who are ready to merge these improvements and the performance and stability gains are pretty big for the amount asked and Zaino needs to work as well as possible.

      • Paul: I can say that I would support that and I think it’s very important for that progress to continue. So I would like to vote in favor of this work.

      • Approved

  • Rozo Merchant POS: Fast Zcash Payments for Real-World Merchants

    • Applicant proposes to adapt their existing audited POS/payment app (with prior NEAR Intents merchant payment experience and a sub-17-second P98 settlement track record) to native ZEC acceptance, building a retail confirmation state model (detected → retail-confirmed → finalized → manual review) with mempool-level detection and a bounded-risk instant-offer policy for small orders, piloted with 1-2 real merchants. Requesting $48,000.

      • Artkor: My main concern is that the proposal improves checkout speed by relying on mempool-level detection and operator-assumed risk, rather than stronger confirmation or finality. That may work for some low-value payments, but I am not convinced this is the right architecture for Zcash merchant payments. I also remain unsure who would realistically adopt and use this product beyond a very limited pilot. For these reasons, my vote is to decline.

      • Zerodartz: I think the proposal is an interesting idea and could be useful but in the way the system is set up in the proposal I don’t think it would be that great UX improvement for people and there won’t be likely to be a big adoption of this tool. So I’m declining right now.

      • Hanh: Yeah, I decline as well. The layout means that one party is going to take all the risk since they are going to accept unconfirmed transactions on behalf of the merchant. There is a risk in doing so, and these risks are not addressed in the proposal. Therefore, it would be the responsibility of whoever deploys this, and I don’t really see their incentive to do so. Moreover, this would sit between the merchant’s current POS and it would require integration with a lot of different platforms. There are two major hurdles that make me believe that this is not going to work in practice.

      • Declined

  • Zcash Reference Flow Kit v1: Android SDK Smoke Paths

    • Applicant requests a grant to finalize a local-only smoke-testing CLI tool for the Zcash Android SDK — providing zrf doctor, zrf smoke-receive, and zrf smoke-send commands that validate environment setup, receive/sync paths, and shielded-send paths against pinned fixture data, with a basic version already built and a public demo available. Requesting $12,500.

      • Artkor: Before funding something like this as a separate grant, I would want to see clearer alignment with the existing SDK maintainers and a stronger signal that this work is needed and would actually be used. I think the work could have more value if it were developed in closer coordination with the teams already responsible for that part of the ecosystem. For that reason, my vote is to decline.

      • Hanh: This is a SDK for Android based on what the ECC has built in the past for third party wallets. I think Unstoppable and Edge were using this. Developers should work with the repo owners which is ZODL.

      • Declined

  • Growing the Turkish Zcash Community

    • Applicant proposes a Turkish-language Zcash educational content campaign leveraging an existing 220,000+ member crypto community across YouTube, X, and Telegram — delivering 7 produced YouTube videos, 20 educational X threads, quizzes with small ZEC reward campaigns, and community engagement directing users toward the existing Zcash TĂĽrkiye community. Requesting $13,500.

      • Artkor: I appreciate the interest in growing the Turkish Zcash community. At the same time, there is already a funded Zcash Turkey initiative with similar regional and educational goals. Our standard view is that the best path forward is closer coordination with the existing team, rather than creating a separate parallel effort. For that reason, my vote is to decline.

      • Zerodartz: I would prefer to see some collaboration first with the Zcash Turkey team. I also think they are too new to Zcash right now. I If they start slowly contributing, we would in the future have more data on which to decide if we would want to fund them.

      • Hanh: We are funding a team pretty seriously in the same region and we’d like to see them complete their plan. If there is room for a second team, why not, but at this point there will be two stores on the same block basically and we don’t want to cannibalize the investment that we put in the first team but again maybe in the future there’s room for two teams. So it’s a no for me for now.

      • Declined

  • 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 $15,000.

      • Artkor: I am still skeptical overall, mainly because this is a significant cost for a small number of articles. I also struggle to see the practical value of writing about Zcash in the context of topics where Zcash does not currently have a clear presence. That said, I do not want to make a final decision today. I will follow Hanh’s suggestion and take a closer look at the applicant’s existing articles before deciding.

      • Zerodartz: While the articles might be pretty good the website itself is hard to find. So I’m guessing it’s not that known or might be actually so new that the number of readers might be very small. So I don’t see the value right now to fund this.

      • Hanh: I’m leaning positive on this because the articles are different from the usual articles in the cryptocurrency space. They are well researched and they didn’t (obviously) use AI to generate the whole thing. That’s a fairly positive thing these days. I do agree that the website is new and the SEO seems to be quite poor. It’s practically impossible to find this website and I don’t think that there will be a lot of readers at this time. So my vote will be just to encourage people to write something of quality about Zcash.

      • Paul: I would be willing to say no today because this doesn’t seem to me to be a lot different than many quality articles that are published on X and other places that I think are much more visible to the community and that this particular site and and this author hasn’t necessarily from what I can tell, you know, been active in the community providing resources already. It makes me question the value of this, like if there was maybe a track record of contributions already and then we saw something that was going to be significantly better or different than what had already been done, then maybe. But I would have expected to see just contributions already aside from grant funded contributions because there’s just a ton of people out there doing this for the community with no support.

      • Hanh: Well the one difference between this guy and the other free stuff is that his articles are more technical. Others, are all about trading. Most of the other stuff is “Zcash is great in privacy and is going to go to the moon”. But I agree with you that it’s fairly niche.

      • Remains open

  • ZK-LoRa: Shielded Micropayments & Privacy Layer

    • Applicant proposes to integrate zk-SNARK identity proofs and Zcash shielded micropayments into LoRa mesh networks, enabling anonymous device authentication and private relay incentive payments for off-grid IoT/AI agent communication. Requesting $24,500.

      • Artkor: This proposal shows very little connection to Zcash, and I don’t see a clear reason why this work should be funded by ZCG. I think it is out of scope.

      • Hanh: It’s a cool project but the connection with Zcash is fairly minimum and I’m not sure it will be deployed much in practice, and I don’t see the Zcash community benefiting from that seems to be more like an application of Zcash as a payment service rather than something that enhances it.

      • Paul: I would concur and vote no for similar reasons.

      • Declined

  • 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: The proposal appears relevant but some parts of the proposed scope should be adjusted before we make a final decision. I suggest that we move the decision to Friday and use this week to clearly formulate the changes we would like to see in this proposal.

      • Hanh: I think in principle we are very positive but there are some priorities that we would like to reassess. For instance, the first milestone is related to securing email of key participants. I’m not sure that this is the most important thing to do and whether it should be done first.

      • Zerodartz: This would be valuable to have for Zcash. Waiting for some small modifications to the proposal before deciding.

      • Remains open

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

      • Remains open

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

      • Remains open

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

      • Remains open
3 Likes
2

Thank you for the feedback for ROZO. I think the concerns are fair around treating mempool detection as an early signal rather than confirmation.

We will make a smaller validation pilot with explicit risk caps, prefunded liquidity, and measured outcomes such as detection latency, confirmation rate, default rate, fee willingness, repeat usage, and traction for digital services or merchant checkout.

1 Like
3

Thanks for the discussion. I wanted to make sure to respond to a few of the points.

On visibility, that’s fair. The site is three months old. But the proposal doesn’t depend on Proof Street’s reach, every piece would be mirrored open-access to ZecHub or whichever community hub ZCG prefers, so the work reaches Zcash readers through channels the community already uses. The publication’s own readership arrives through direct channels and practitioner sharing, which is the normal shape for a trade publication at this stage.

On writing about Zcash in areas where it doesn’t currently have a presence, that is the point. Comparisons between shielding and FHE, MPC, and TEEs are being made largely without Zcash in the room. The series argues Zcash’s case in those comparisons on technically accurate terms, which trading-focused content doesn’t attempt.

If the committee’s hesitation is scale, I’m open to structuring this as a pilot, the first two pieces at proportional cost, with the remainder at ZCG’s option after you’ve seen the work.

1 Like