Zcash Community Grants Meeting Minutes 6/8/2026

Community Grants Community Grants Updates
1

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

Attendance:

  • Artkor

  • GGuy

  • Hanh

  • Zerodartz

  • DecentralistDan

  • Danika (FPF resource, notetaker)

Key Takeaways:

Open Grant Proposals

  • Formal Verification of Halo 2 in Lean 4

    • 18-month project to formally verify Zcash’s Orchard protocol and Halo 2 circuits using Lean 4, covering soundness/completeness of five circuit gadgets, protocol-level security properties, and post-quantum migration analysis. All outputs open-source. Requesting $201,600.

      • Artkor- I want to thank him for giving an excellent presentation at the Arborist call. While the applicant provided an excellent presentation, the committee requires the work to be validated by a recognized leader in the field to be credible to serious institutions (details in the relevant forum thread).

      • Hanh- I’m supportive about having formal verification in Orchard, in principle, but I’m not sure if the applicant has the background needed for this difficult job. Con: I reviewed their GitHub (very basic proofs), Pro: the arborist call was positive. But, the Zcash Dev teams are not able to sign off on validating the work moving forward and we cannot verify as ZCG.

      • GGuy- The amount of work involved to bring to completion relies on the devs and they do not have the availability of time.

      • Declined async- The committee decided to reject this proposal due to the significant amount of work required and a lack of available time from developers to support the project.

  • 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 $412,410.

      • GGuy- We are having discussions to amend the grant proposal with QEDIT to get ZSAs merged into Zcash repositories upstream and get them in the hands of end users.

      • Hanh- I vote to reject this grant because it does not have anything to do with merging the code back in.

      • Artkor- I support ZSAs but after hearing my colleagues’ technical concerns, I think the grant should be focused on clear upstream milestones.

      • Zerodartz- We should have a way for users to test and play with ZSAs on testnet. Considering recent changes in network upgrade plans, this current proposal might not fit.

      • decentralistdan: agreed, leave open for team to amend the proposal with requested changes

      • Remains Open- The committee discussed amending the grant proposal with QEDIT to merge Zcash Shielded Assets into Zcash repositories, and ultimately decided to leave the proposal open. The committee agreed that the proposal did not align with their goals of merging code upstream and decided that the applicant should refocus the work around clear upstream merge milestones before resubmitting a grant application.

  • Incrypted Educational content in CIS region

    • Incrypted proposes a one-time CIS-focused Zcash educational campaign: two localized articles (Ukrainian and Russian) and one AMA session, distributed across their YouTube, website, Telegram, and Discord channels. Requesting $5,000.

      • Artkor- We suggested narrowing scope to one video and the applicant did not agree to that approach so I vote to reject.

      • Hanh- We asked them to switch to a single video and they didn’t want to, so I also vote to reject.

      • Zerodartz- Their YouTube channel seems quite nice, but since this proposal doesn’t include video content it’s not the best fit for Zcash. Articles are already being written by many 3rd parties on their own initiative.

      • decentralistdan: reject based on applicant not pivoting the scope of the grant as requested

      • Declined- The committee rejected this proposal after the applicant declined a suggestion to narrow the project’s scope to a single educational video, which the committee deemed the most useful outcome

  • 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- We want to see what happens with coinholder retroactive grant application. If they don’t get this grant passed, then I’d reconsider. I’m not super keen on it because it can be abused because there is no level of identity check. The names are registered by unauthorized parties; other systems typically implement verification measures.

      • Artkor- I’d like to wait to decide until we know the retroactive outcome and am generally supportive.

      • Remains Open- The committee agreed to keep this proposal open while they monitor the outcome of the applicant’s retroactive grant application through the Coinholder process

  • Zcash Privacy Capsule

    • Applicant proposes a client-side encrypted vault built on Zcash combining three workflows: proof-of-existence timestamping via Zcash memo anchoring, encrypted sealed capsules with client-side keys, and time-based release/deadman switch mechanisms — targeting journalists, lawyers, compliance teams, and researchers. Requesting $46,400.

      • Artkor- The project’s goal of proving document existence at a specific time could already be achieved by hashing files publicly. Some ideas in the proposal may be useful, but I would expect them to be implemented in ZODL, as the wallet’s developers have already indicated this direction. I see no need for separate funding for this work.

      • Zerodartz- Without having it implemented in wallets I can’t see many users starting to use this tool on its own.

      • Hanh- The off chain storage solution has the same issues as other ones. There is no incentive to store your doc aside from storing it yourself.

      • decentralistdan: reject, no clear use case and lack of wallet support for the implementation

      • Declined async- The committee rejected this proposal due to a lack of a clear use case and concerns regarding the implementation.

  • 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- I’m not interested in this particular grant but I’m interested in reaching out to this applicant to find a better fit.

      • Hanh- The proposal is not interesting because ZIPs being tested have already been implemented and well tested.

      • decentralistdan: also open to getting in touch with this applicant to see if there is more relevant work they can pursue

      • Remains Open- The committee decided to leave this proposal open to reach out to the applicants and discuss a better fit, as the specific Zcash Improvement Proposals (ZIPs) being tested were considered core to the system and already well-implemented.

  • Zcash Shielded-Identity Adapter

    • Applicant proposes a Rust adapter crate that derives sovereign AI memory identity from a Zcash z-address holder’s shielded key chain, enabling Zcash keys to anchor encrypted AI memory cells in the SAIHM protocol without requiring on-chain transactions. Requesting $50,000.

      • Artkor- I do not see a practical use case or a clear Zcash-specific need in this proposal, so I vote to reject.

      • GGuy- I don’t see it being widely used or that it solves a problem that doesn’t have other solutions.

      • Hanh- It’s not necessarily bound to Zcash technology. The proposal involves encrypting memories for an AI engine using Zcash keys, but there is currently no technology capable of performing AI or transformer operations on encrypted data without first decrypting it, rendering the local encryption unnecessary.

      • Zerodartz- The idea is interesting, but not something that seems to be needed right now.. I also can’t find much about the history of this team online.

      • decentralistdan: reject as out of scope

      • Declined- The committee rejected this proposal because it lacked a practical use case and did not address a specific Zcash need.

  • Zaino June 2026 - June 2027 Maintenance and Upgrade Budget

    • Applicant requests one year of dedicated maintenance funding for Zaino — the indexing and chain-state serving layer critical to the Z3 stack (Zebra + Zaino + Zallet) — covering security triage, bug fixes, protocol update integration, release engineering, CI/DevOps, and inter-org coordination across nine 4-day/week functional roles. Requesting $1,501,471.38.

      • GGuy- I’d like us to reach out to ZingoLabs to make adjustments to the grant structure to align on work to deliver software.

      • Hanh- I agree.

      • Zerodartz- Zaino needs to be in good state very soon when Zcashd gets deprecated, let’s have a discussion with them soon.

      • Remains Open- The committee decided to reach out to Zingo Labs to amend the current grant structure and align the team’s work with the committee’s desired outcomes for software delivery.

  • Chain-Agnostic Cross-Chain Atomic Swaps

    • This proposal requests a forward grant to build an open-source atomic swap MVP between EVM chains and transparent Zcash UTXOs using standard HTLC logic, delivering a protocol spec, EVM swap contract, Zcash UTXO script, client application, and matchmaking server. Requesting $37,200.

      • GGuy- I suggest the grantee apply for a retroactive grant if it’s successful.

      • Artkor- If the team builds a working implementation then the community should support it retroactively.

      • Hanh- It’s about the same model as Atomic DEX. It’s difficult to find liquidity in this kind of model.

      • Zerodartz- Agree, liquidity determines a lot of how much usage a swap service will be used.

      • Declined- The committee rejected this proposal and suggested the applicant apply for a retroactive grant instead.

  • Aweb Zcash Private Agent Receipts

    • Applicant proposes to build an open-source privacy receipt schema and tooling for AI agent execution, defining a redaction model, TypeScript helpers, CLI validator, JSON schema, sample corpus, and lightweight viewer — designed to preserve accountability evidence without exposing prompts, addresses, or private workflow context. Requesting $48,000.

      • GGuy- Rejected as out of scope.

      • Artkor- I don’t see a clear reason for ZCG to fund this work.

      • Hanh- I agree it’s out of scope.

      • Zerodartz- AI agents are becoming more normal now. But this proposal is not the right fit for Zcash right now.

      • decentralistdan: out of scope

      • Declined Async- The committee rejected this proposal, concluding that the work was out of scope and that teams could build these tools independently without requiring ZCG funding.

  • PCZT Interoperability Test Suite

    • This proposal requests a forward grant to build canonical PCZT test vectors for zcash-test-vectors and a cross-implementation interop harness, enabling wallets and hardware devices (OneKey, Ledger, Hito, Keystone) implementing PCZT to verify they actually interoperate across Creator → Signer → Finalizer roles. Requesting $33,250.

      • GGuy- I’m uncertain if they can deliver on this initiative.

      • Hanh- It seems to be a copy of the one before but has nothing in it.

      • Artkor- It was developed by the Keystone team which has a respect for security and it was audited by Least Authority. There isn’t a need to repeat work done by a competent team so I vote to reject.

      • Hanh- It’s mostly true but having more tests could be good. I’m not sure if there is only one test for PCZT, there must be more. This proposal doesn’t demonstrate competence in delivering based on the sample code they provided.

      • Zerodartz- It could be a retroactive grant if they demonstrate it’s written and useful.

      • Declined- The committee rejected this proposal, noting that the work appeared to duplicate efforts already successfully handled by the Keystone wallet team, which had been independently audited.

  • 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- My main reservation is the overlap with existing funded education initiative in Nigeria.

      • GGuy- I agree that encouraging cooperation is a big first step.

      • Zerodartz- It makes sense that they try to collaborate with the current Zcash Nigeria team first. Having too many separate teams in 1 big region doesn’t make sense at the moment.

      • decentralistdan: yes, would like to see them collaborate with the current Nigerian team and potentially ZecHub

      • Remains Open- The committee decided to keep this proposal open for further consideration.

  • Zpath a Zcash Whatsapp Bot

    • Applicant proposes a 3-month productionization and onboarding pilot for Zbot-core, a WhatsApp-based bilingual (English/Kiswahili) Zcash onboarding assistant already built and running, targeting East African users with zero-friction wallet setup and shielded transaction education through structured onboarding cohorts in Kenya. Requesting $25,000.

      • Artkor- The economics of the grant doesn’t make sense and it’s not sustainable. I vote to reject.

      • Zerodartz- I like the idea but the grant amount is too much and the statistics are a bit off. I’d rather have ZecHub implement an AI chat if there is demand for it than have a bot in a channel where it’s hard to first find users who would use it.

      • Hanh- They could create a Telegram bot but WhatsApp isn’t a good fit. 600 hrs is too much. Once you write the bot then you shouldn’t have to handhold it. Having a good source of info is good, so I like the idea. I reject it but a Zcash knowledgeable chatbot could be useful.

      • GGuy- They mention RAG as a way to make these bots more reliable but I’m yet to see one perform better than free and well utilised existing systems like Google AI search. I’m also unconvinced that talking to AI bots or WhatsApp is something users do. Happy for the community to reach out if talking to AI bots on Whatsapp is a new trend I’m unaware of.

      • Declined- The committee rejected this proposal due to concerns that the unit economics were unjustifiable, with the proposed costs being too high for the expected output.

5 Likes