Zcash Community Grants Meeting Minutes 8/3/2026

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: August 3, 2026

Attendance:

  • Artkor

  • Zerodartz

  • Paul

  • Gguy

  • Alex (FPF resource, notetaker)

Not present:

  • Hanh (voted async)

All votes this week were unanimous.

Key Takeaways:

Open Grant Proposals

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

      • Gguy: We’re just waiting for an update from the applicant on this one before we make a final decision.

      • Arktor: I think ZCG generally likes this proposal, but we want to make sure the work is properly coordinated with relevant maintainers. We hope the applicant will use technical coordination channels available within the community.

      • Remains open

  • 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: We’re waiting for an update from the applicant about steering this grant in the direction that will provide the most benefit.

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

      • Gguy: Without an end-to-end solution or application in mind, it can be hard to tie the exact needs for technologies like this in with the needs of the applications. At the risk of this being something that isn’t adopted across the community, I’m leaning towards rejecting this one.

      • Artkor: I just want to add that I think the committee had a good opportunity to discuss this proposal in depth, and I rely on the technical perspectives raised here when making my decision. I very much want to see FROST continue to develop and gain broader practical adoption, so I remain open to retroactively supporting any concrete contribution that is recognized as useful by experts in this field and by the community.

      • Paul: I have concerns about adoption and ongoing maintenance and having one person working on this effort. I think it really needs a team. So, too many risks and outstanding questions for me to approve.

      • Zerodartz: FROST is interesting technology and a useful tool. Zcash ecosystem needs it to be used way more but for that to happen there has to be one standard every wallet can use. This grant in some ways tries to fix that, but I think it would make more sense if there was more collaboration with core teams and a proper security audit by multiple auditors. Custody infrastructure needs highest level of trust. I’d also like to see some demand signal from exchanges who would probably need this the most if they were to hold shielded ZEC. Right now I don’t see the need to rush so I’m rejecting.

      • Hanh: For Information, zkool provides end to end decentralized FROST DKG and Signing using Zcash memo as secure transport. Works with Ironwood. So the gap would be org-grade and KS support. Unfortunately, that’s also the part where I don’t see much appetite for standardization and integration. There is too much risk with upstream dependencies for me to approve this, but I see no support for ecosystem shareholders that would lead me to believe otherwise. I decline.

      • Declined

  • Zebra Mempool Adversarial Resilience Suite

    • Applicant requests a forward grant to build a deterministic simulation harness for Zebra’s async mempool — enabling controlled-time reproduction of timeout/concurrency bugs (the exact class of GHSA-65jj and open issue #10684), a composed adversarial scenario library, a ZIP 401 anti-DoS conformance oracle, and Ironwood mempool surface coverage, all left as permanent CI infrastructure. Requesting $18,000.

      • Artkor: After our discussion, it became clear to me that this is highly complex work, while the applicant’s expertise remains unclear and the proposal itself is too vague. For those reasons, I am voting to reject it.

      • Gguy: I agree that many applications like this require the expert teams developing this technology and therefore they its critical they be involved in the process to ensure adoption of this tooling. I do think that there is room to explore work like this more into the future, but I won’t be approving this specific grant application.

      • Paul: It should be noted that one of the factors in this decision here was that the GitHub account for this applicant is new without any track record whatsoever which raises a lot of questions.

      • Zerodartz: I also think the Zakura team has been also doing something related to mempool upgrades and improvements recently, but yeah, the lack of past GitHub history makes me question it. I reject.

      • Hanh: Concurrency/Async, DDOS protection are notoriously difficult to design and verify. Even though I appreciate the seriousness of the issue, I find the applicant has not demonstrated enough expertise in the matter. I decline.

      • Declined

  • Zk-ComsmwasmVm + Community-Led Audit & Design Space Hackathon

    • Applicant requests a forward 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: This one we’re going to leave open. We are just waiting on some feedback from the applicant. Having details about end-to-end solutions is helpful in gaining a vision of what the future of this work could look like. We’ll keep talking with the applicant about the usefulness of the application

      • Artkor: The applicant has now provided several possible use cases. As far as I understand his example, there is some hypothetical app in the Cosmos ecosystem, and his solution would make it possible to track when someone has made a payment on the Zcash network. After that, the app could trigger a smart contract to execute because the service would be considered paid for. Overall, at this point, I’m open to projects that pave the way for collaboration between ecosystems and Zcash.

      • Hanh: True, but the verbiage is overly technical and seems to be highly AI generated. Even though I can see value in the project, I remain suspicious about its end to end implementation. I think a fully functional app that demonstrates both the value and the practicality of this work is needed given the amount requested.

      • Remains open

  • Legitimacy Beyond Transparency: Zcash, Privacy, and Trust in Islamic Digital Finance

    • Applicant requests a forward grant for a comparative research study analyzing how Zcash and HAQQ Network construct legitimacy differently — Zcash through technical privacy/selective disclosure, HAQQ through Shariah-oriented governance — producing a full report, a Zcash-facing brief, and an educational framework for explaining financial privacy to audiences with Islamic ethical frameworks. Requesting $12,000.

      • Artkor: I think that regardless of a person’s beliefs, religion, political views, or other preferences, Zcash is a basic, neutral tool in which everyone can find the value that matters to them. For some, that is protection against inflation; for others, it is a decentralized way to transact where banking services are unavailable; for others, it is the ability to conduct their affairs privately, and so on. This should depend not on other people’s judgments or labels, but only on each person’s own needs and interests. Therefore, I do not think it would be right for us as a community to divide a basic tool that is available to everyone into categories or to invent separate Zcash use cases based on religion or other personal characteristics. I do not want to encourage that approach, and therefore I respectfully reject this proposal.

      • Paul: I concur and reject as well.

      • Gguy: It wasn’t clear to me the outcomes we should expect from this application and I am uncertain to be we’d see any benefits.

      • Zerodartz: I don’t see the exact value of this research for Zcash. Zcash is money, and if your religion supports use of money, there’s not much to research.

      • Declined

  • VibeQuest: Learn, Build, Prove

    • Applicant proposes to build a Zcash Shielded Payments learning track on their existing MVP platform — an execution-first, guided curriculum covering ZIP-321 payment requests, shielded address types, memo privacy boundaries, viewing keys, confirmation/expiry handling, and application-layer privacy risks, with checkpoints, quest flow, mobile UX, beta testing, and distribution. Requesting $22,800.

      • Gguy: In the past we’ve funded similar applications but we haven’t seem much success and unfortunately they just don’t seem to get much engagement. So I’m not looking at funding anything like this right now.

      • Hanh: The grant gives no concrete examples. The repos are mostly generic and AI coded. I couldn’t generate any course or start any lesson. From what I see from the video demo (which is not proof of the platform), an AI generates a course based on the user selection. As a result, the course quality isn’t curated or the content checked. I think the results are robotic and won’t attract many people. I reject.

      • Artkor: I don’t see much long-term value in funding a separate educational platform for developers. What developers primarily need is accurate and well-maintained documentation written by the people who build the underlying software. A third-party course cannot be more reliable than the documentation it depends on, and once good documentation exists, AI can already explain it, answer specific questions, and adapt the material to each developer far better than a fixed course. For this reason, I do not believe this proposal is a good use of ZCG funds, and I reject it.

      • Zerodartz: I agree with others, long term these sorts of learning tools will become obsolete very likely.

      • Declined

  • Zcash UK & Ireland Community Initiative

    • Applicant proposes to establish a regional Zcash community chapter delivering in-person meetups, technical workshops, university outreach, online content, and ambassador development across the UK and Ireland. Requesting $10,000.

      • Gguy: We like to see community groups build a community and relationships with the Zcash community before they ask for grants funding.

      • Paul: I second that. I think there might be some questions about the community’s connection to the local area they are focusing on.

      • Artkor: Building a local community is a long process but it’s also a path that should already be familiar to this applicant. I reject this proposal.

      • Zerodartz: Ireland and the UK are quite separate areas so I wouldn’t think it would make sense to have one community for both. Start small and prove you can start growing a community first and after that you can come back and apply for a grant.

      • Declined

  • ZIP-229 Conformance Suite: Cleanroom Testing for the Ironwood v6 Transaction Format

    • Applicant requests a forward grant to build a cleanroom Rust implementation of the ZIP-229 v6 transaction parser/serializer written from spec text without reference to librustzcash, cross-checked byte-for-byte against librustzcash/zebra-chain on real testnet vectors — applying the validated methodology from the declined ZCG #307 proposal to an active, unstable target rather than stable ZIPs. Requesting $19,000.

      • Gguy: We’ve seen a lot of these type of grants lately but unfortunately we don’t think this application is best placed meaningfully increase the assurances of our Zcash specs or implementations. ZCG will continue to work with the core teams within the community if they need any assistance in improving the security of the Zcash ecosystem which we think is really important priority right now.

      • Hanh: I don’t find this approach particularly effective at finding issues with the spec. If someone finds it ambiguous to the point that it leads to divergent implementations, they should raise an issue directly. The previous similar applicant claimed an ambiguity when in reality they were the only implementation that interpreted the spec in their way. This brings more work to everyone involved: spec writers, reviewers and devs. I decline.

      • Declined

  • Ironwood Sentinel

    • Applicant submits a grant for a three-layer Ironwood readiness harness: (1) behavioral test suite for Ironwood pool operations upstreamed to librustzcash (issue #2617, publicly claimed), (2) a ZIP 318 migration privacy linter checking denominations, residual caps, and anchor-height buckets, and (3) productionized endpoint monitoring (GitHub Action + scheduled public JSON reports) — built on a working Phase 0 CLI that already watched the July 28 activation live. Requesting $27,000.

      • Artkor: I would like to thank Pacu and the members of the technical community who help ZCG evaluate proposals and contribute their expertise to these discussions. Based on Pacu’s feedback and the ZCG discussion, I don’t see a sufficiently clear or practical need for the proposed tooling, and therefore I reject this proposal.

      • Gguy: I’m struggling to find the net value of this grant without taking up a significant amount of core engineer time so we’ll reject this one. We’re happy to receive more applications that contribute towards the security and assurances of Zcash from qualified teams.

      • Hanh: ZIP-318 documents a migration policy. It leaves some room to interpretation. I don’t think that a linter can effectively check.

      • Declined

  • Open Light Nodes

    • 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 — with upstream contributions already made to zcash-stack and positive feedback from Gem Wallet and zec.rocks confirming the geographic gap filled. Requesting $40,000.

      • Zerodartz: I think it’s good to run more nodes but I think two people paid for this almost full-time likely seems too much since much of it can be automated once the nodes are running.

      • Gguy: Going forward I will encourage ZCG exploring ways of contributing towards increasing not only the reliability but also the distribution or core infrastructure. I’m not looking to fund this grant right now, but hopefully ZCG can explore ways to help increase to reliability and distribution of core infrastructure in the future.

      • Too early to vote

  • Shielded Compliance Bridge

    • Applicant requests a forward grant to build a production-grade, audited Rust library and TypeScript/WASM SDK enabling VASPs to reconcile shielded ZEC activity (Orchard and Ironwood, extending a proven Sapling proof-of-concept) 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.

      • Too early to vote

  • Zcash Arabia

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

      • Too early to vote

  • Shielded ZEC Privacy and Trust Architecture Framework

    • Applicant requests a forward 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.

      • Too early to vote

  • ELLIPAL Zcash Ironwood Shielded Transaction Support

    • Applicant requests a forward grant to add Ironwood shielded transaction support to its TITAN air-gapped hardware wallet (QR-code-only communication) and companion mobile app (iOS/Android), 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.

      • Too early to vote
4 Likes
Grant Application (community review): Ironwood Sentinel - Conformance and Readiness Testing for Zcash Wallets and Infrastructure
ZIP-229 Conformance Suite: Cleanroom Testing for the Ironwood v6 Transaction Format — Grant Application Feedback Thread
Grant Application – A Plural Case for Privacy: Zcash and Islamic Digital Finance
Threshold (FROST) custody for shielded ZEC: design check before a ZCG application
Grant Application - VibeQuest: Learn, Build, Prove
Zcash UK & Ireland Community Initiative
Grant Application - Zebra Mempool Adversarial Resilience Suite
2

Hey, ZCG team!

We are the grantees behind Apple Silicon Zero-Knowledge Proving: Mobile Halo2 and Tachyon Acceleration on M-Series and A-Series Chips , and we see that our grant still remains open.

The issue being, Gguy says that they are waiting for an update from us about steering the grant. Problem is, the steering is already done! We pivoted from a Apple-specific architecture to a ARMv8-A general architecture to run on all mobile chips, as well as demonstrated a live benchmark to a committee member (Hanh, which was not present in the meeting).

We would love guidance on where to go from here, especially since our own funding has been burning out for over a month with no clear direction on where to go. What are we supposed to announce or demonstrate?

1 Like
3

Thank you for the feedback, and for considering the proposal. We have taken it on board and updated the application.

@Gguy, your point about increasing not just the reliability but the distribution of core infrastructure is exactly what this project is built around. Beyond running our own endpoints, a central goal is distribution: spreading awareness and making it genuinely easy for others to run a node, through open onboarding guides, reproducible one command setups, and workshops across the Zcash India community. The intended outcome is independent node operators emerging across the Indian and wider Asian region, so the distribution of core infrastructure grows beyond any single team, including ours. This is the part of the work we are most focused on, and it is why we keep a dedicated full-time community and distribution role.

On the budget, we acted on @zerodartz 's feedback: the engineering and operations work is front loaded and automates over time, so we reduced the total from $40,000 to $32,000. The community and distribution effort, by contrast, runs throughout and is the human work that actually grows the number of independent operators.

We would genuinely welcome guidance on how to structure this so it best serves ZCG’s goal of a more distributed and resilient core infrastructure.

2 Likes