Zcash Community Grants Meeting Minutes 9/14/2026

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: September 14, 2026

(Part 1, Part 2 follows in the first comment)

Attendance:

  • Artkor

  • Zerodartz

  • Paul

  • Hanh

  • Gguy

  • Alex (FPF resource, notetaker)

Votes split where indicated.

Key Takeaways:

Open Grant Proposals

  • Taking Zcash to the Streets: Education & Real-World Feedback in Türkiye

    • Applicant proposes a 10-part Turkish Zcash YouTube education series published on the Crypto Epoch channel, followed by a 3-day Istanbul street interview campaign gauging crypto/Zcash awareness and directing interested participants to the series, with small Zcash-branded rewards for engagement. Requesting $6,955.

      • Artkor: I haven’t really seen crypto education done through street interviews before. It might work, but I’m not comfortable funding it up front without seeing the quality first, or knowing if this format can work as a series and keep people interested. In its current form, I reject this one.

      • Gguy: This is the kind of thing I’d like to see proven first before funding, so I’m going to reject this.

      • Zerodartz: I would also like to see an example first episode or something in that style before funding.

      • Hanh: Reject as well, based on the other videos from the website. They don’t seem to add a lot of value compared to the other videos we have.

      • Declined

  • Recoverify: Pre-Loss Backup Recovery Verification for Zcash Wallets

    • Applicant proposes an open-source Rust CLI and local web UI that generates a non-secret Recovery Record from a working wallet, then later verifies a saved backup against that record — testing whether the backup reproduces all recovery-relevant state (accounts, addresses, derivation ranges, pool coverage) before the original wallet is lost, with classified results (Verified / Incomplete / Additional material required / Unable to verify / Verified empty). Requesting $2,990.

      • Gguy: Technically speaking it doesn’t add much value and I have some security concerns.

      • Artkor: I agree. The developers of each wallet are in the best position to design and test their own backup and recovery features, so I don’t think we need a separate tool for this.

      • Hanh: The best way to test whether your recovery works is to recover into another wallet, which gives you 100% certainty because it also does the synchronization. Since you are already installing an app (Recoverify), you might as well install a wallet. Second, I don’t want to recommend that people enter their seed phrase into an application just for the purpose of verifying their seed phrase. That is exactly what a scammer can ask you to do, and it would be very confusing for users. (Not implying Recoverify is a scam)

      • Zerodartz: Agree with others on the security concern. Reject.

      • Declined

  • Zcash World, Mumbai (Devcon 8 week)

    • Applicant proposes a multi-phase Devcon 8 week program anchored by a one-day fully shielded ZEC environment (registration requires a wallet, Z-BAZAAR accepts only shielded ZEC, 250–300 wallet onboards, live device benchmarking on entry-level Android hardware), followed by merchant onboarding of 20 Mumbai businesses during Devcon week, ecosystem engagement on the Devcon floor, and content capture throughout — with the benchmarking dataset released open-licensed and an after-movie published within 72 hours. Requesting $20,300.

      • Artkor: I liked that this proposal includes practical use of shielded transactions, testing wallets on low-end devices, and an attempt to onboard local merchants. It also comes from an active team we’ve already been following, so I’m happy to support this proposal.

      • Hanh: I approve as well. It has a concrete plan, a known team, and a very reasonable budget. Everything looks very good.

      • Gguy: I agree. I’m excited to see how this event goes.

      • Zerodartz: I will also approve, since this team has a proven track record in the Zcash community already. They have done some onboarding in India, and they will also collaborate with the WebZero hackathon. That is great to see.

      • Paul: I think it’s a really cool idea, and hopefully it can be used for future events as well. Looking forward to seeing how it turns out.

      • Approved

  • Zcash Privacy Literacy Lab Canada

    • Applicant proposes a free, account-free web learning module with 12 interactive privacy scenarios (transparent vs. shielded transfers, viewing keys, selective disclosure, exchange touchpoints, metadata limits), a Rust scenario generator using real Zcash libraries on regtest/testnet, and a dated Canadian regulatory source map (30+ records covering recordkeeping, reporting, and consumer protection) — with independent technical and Canadian legal review, public correction log, and MIT/MIT-compatible licensing. Requesting $15,000.

      • Artkor: I think this overcomplicates a fairly simple education problem. If the goal is just to explain the difference between transparent and shielded transactions and show what information is visible, existing Zcash tools and content can already do that quite clearly. I reject.

      • Zerodartz: These sorts of educational projects are cool, but in the current age I don’t think they’re worth as much anymore, and it’s much simpler to build these tools if the need arises for a specific event for example. If you don’t already have a user base who will start learning these things, the impact will also be very marginal.

      • Declined

  • 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets

    • Applicant requests a grant to expand and harden a working non-custodial local-currency-to-ZEC ramp already live at 0xramp.app — $13,381 settled USDC across 220 orders in August 2026 across 8 corridors (BRL, INR, IDR, ARS, VES, NGN, COP, Ecuador-USD), with ZK social verification instead of KYC, NEAR Intents swap leg, zero interface fees, and Noir Wallet integration — targeting NGN/COP/ECU production launch, shielded-first delivery, Tor onion service, public metrics dashboard, and integration with ZCG-funded community referral paths. Requesting $206,000.

      • Gguy: I had some concerns about the tooling and safety for users. Because it is not completely decentralized, there may be a custodial risk across the payment systems involved, so I can’t approve this one today.

      • Paul: For me this falls into a category where it’s a business they’re trying to start that should be revenue generating. I really don’t like ZCG being in the position of helping people start a business that needs to be self-sustaining. I think that could be a bad investment.

      • Artkor: I know there are real risks with this proposal, but I still want to support it because I like ambitious ideas and people who are willing to take a real shot at them. I approve this one.

      • Hanh: I reject. The connection between these companies is not clear enough for me. Users will put their funds into various systems, in particular P2P.me, which is in charge of the fiat settlement, and the added value for Zcash is not clear — all the work is actually done by P2P.me. I’m afraid that if a user has their account blocked, they would not know that it’s because of some third party.

      • Zerodartz: I think it’s a great project, but in practice the user takes all the risks, and their accounts might get frozen along with other funds they didn’t even transfer with crypto. That’s a bit too risky for ZCG to fund in my view. The risks should also be much more clear on the site when users do their swaps or on and offramps. Decline from me at the moment.

      • Hanh: Some people compare this to NEAR and Red Bridge. In my opinion the difference here, and the reason I’m not approving this one where I approved the other ones, is that this one is fairly centralized around the company P2P.me, whereas the other ones are decentralized solutions. It is a bit scary when a regulator can block a bank account.

      • Declined (Yes: Artkor; No: Gguy, Paul, Hanh, Zerodartz)

  • ZecBit - NFT Infrastructure for ZSAs

    • Applicant requests a grant to publish three open ecosystem infrastructure components for Zcash Shielded Assets — ZMD-1 (open metadata standard for ZSAs, already in use on testnet), a key-less deterministic indexer (reproducible catalog anyone can run), and shielded payment intake tooling (lightwalletd scanning, trial decryption, memo-tag matching, reconciliation) — built on top of an already-running marketplace, with the marketplace itself explicitly excluded from the funded deliverables. Requesting $48,000.

      • Gguy: Unfortunately we’ve had to decline this one. It doesn’t fit with the current state of ZSAs, and I don’t think it is going to practically work or provide value for Zcash users.

      • Artkor: Additionally, I think most people in the community probably noticed the red flags around this proposal on the forum, and that’s why we declined it too. I’d also remind anyone who wants to put their own money into projects like this to do their own research and be careful.

      • Hanh: There are also reports of people who put money in to buy these ZSAs, which were backed by testnet, and they were not refunded. Unfortunately it seems like our worries materialized.

      • Declined async

  • ZEC Invoice Preflight: ZIP-321 Validation for Zcash Merchants

    • Applicant requests a forward grant to move a working self-funded prototype (live demo, 20 tests, CLI doctor, handoff schema v1) to a reproducible public tool — adding GitHub CI, CONTRIBUTING.md, npm packaging (zcash-invoice-preflight), acceptor outreach/validation loop, expanded malformed input fixtures, and 12 months of demo maintenance — providing compose-time validation for single-payment ZIP-321 invoices before errors reach the customer. Requesting $3,000.

      • Hanh: It’s a library that would check the validity of payment URIs — ZIP-321 is about payment URIs. I don’t think this is needed, because the payment URI is generated by the merchant using a library that interfaces with librustzcash, so the validity of the payment URI is pretty much guaranteed.

      • Declined async

  • Security Audit of Zaino

    • Applicant proposes a scoped public security audit of Zaino — covering core indexing/chain-state tracking (zaino-state), gRPC/JSON-RPC service layer (input validation, DoS surfaces), privacy-relevant data paths (wallet/transaction linkage inference), and Rust dependency/supply-chain review — delivered as a public report in Cyfrin’s standard format with severity-rated findings. Requesting $120,000.

      • Gguy: Unfortunately the Zaino team isn’t ready for an audit yet. But we will keep an eye on the Zaino project and explore any auditing needs in the future.

      • Declined

  • Zcash SeedSigner: DIY open source air gapped signer for shielded ZEC

    • Applicant proposes to build a Zcash-capable DIY hardware signer based on the SeedSigner platform (Raspberry Pi Zero + LCD + camera, ~$35 in generic off-the-shelf parts) — implementing PCZT/ZIP-374 signing with on-device ZIP-244 sighash recomputation, RedPallas spend authorization, ZIP-32 key derivation, and QR/UR transport compatible with existing Zodl releases, with a working proof-of-concept already on GitHub (libzcash-signer, 676ms median for derive+sighash+sign+verify on real Pi Zero hardware). Requesting $65,000.

      • Artkor: I think it’s a cool technical project and honestly I’d like to play with it myself, but it feels too niche for ZCG funding, especially at this budget. I don’t think an air-gapped DIY signer is a priority for the community right now. With so many hacks in crypto, I think most regular users will prefer hardware wallets from well-known companies. So I reject.

      • Gguy: I agree that this is a fun project, but unfortunately I don’t think the value matches the ask. I’m going to reject.

      • Paul: I agree to reject. There are also the concerns about hot wallet integration mentioned in the proposal. The proposal mentions upstream integration with ZODL, and until that were agreed upon I think it would be premature to make that assumption.

      • Zerodartz: It’s reject from me as well, even though it’s probably a cool nerdy project. It’s not worth the funding from us right now with a very limited user group.

      • Hanh: The ZODL integration is a bit of an issue, but he did mention that only a small change is needed, so maybe he can do it without. I agree it’s a bit too expensive. It’s really a hobbyist project, because in terms of cost it isn’t really cheaper than buying a hardware wallet once you account for the parts you have to buy and assemble, and the result will be less secure because it doesn’t have a secure element. For a hobbyist project, this request is way too high for me.

      • Declined

  • Colosseum | Crypto World’s Fair | Zcash Track

    • Applicant proposes a Zcash-dedicated track within a multi-chain online hackathon (September 14–October 12) to attract startup founders to build on Zcash protocols, with a dedicated prize pool and post-competition support for promising teams. Requesting $250,000.

      • Gguy: I think this is an interesting application. Unfortunately there are some things I would like to discuss and address before we entered something like this, around total funding, and given that Zcash is not a smart contract or have scriptable computable blockchain like some of the others we fit a little bit differently into the hackathon compared with the other cryptocurrencies. I have concerns about funding into a joint pool when Zcash is a little separate from the other cryptocurrencies. Given that this hackathon started today, I think we should continue discussions, so we can be rest before the next round starts. That way we can iron out some of these details and think about projects that we can get the community and participants interested in. So unfortunately a reject from me today, but I’m looking to the future for this.

      • Hanh: I will reject for similar reasons. Of the $250,000 total, only $100,000 is assigned to properly Zcash projects. The rest will be split between potentially other coins, and $50,000 will go to the team. If they plan to do this kind of sponsorship for many projects, $50,000 feels like a lot to pay for operations. I would understand if the operations were just for us, but if they run ten different coins then I don’t see why we pay so much when it’s split with the other coins. I would rather have more going to the top Zcash projects. The other concern is what we are going to get, since we don’t have programmability.

      • Paul: I would come at it a little differently. We’ve seen a lot of really good things come out of hackathons recently in the Zcash ecosystem — it’s been quite a surprise to me. People have reached out to me and told me about this team and their track record in the Solana ecosystem, and apparently it’s been very successful. It’s not only a hackathon; it actually follows on to help fund the teams to become viable projects, so it’s almost a combination of a hackathon and a startup incubator, which I think is pretty cool. Given that, and that having them come into the Zcash ecosystem would be a pretty big deal, I would approve.

      • Hanh: But then Zcash would get more. I just think it’s too much overhead — you pay $250,000 but only less than half will go to Zcash.

      • Paul: That is a good point for sure.

      • Zerodartz: Wouldn’t it also be an issue that they’re starting today and we haven’t even decided yet? It’s a bit too rushed, I think. Maybe next time would make more sense if we had a longer head start. This time I’m rejecting.

      • Gguy: Their request was to have someone from the ZODL team involved as well.

      • Artkor: I’m positive on this one. I support the idea of funding this specific hackathon in the future because it will help attract more talented developers to Zcash.

      • Approved (applicant revised grant post-meeting and ZCG voted async to approve)

  • Zcash East Africa @ Africa Blockchain Festival 2026

    • Applicant requests funding for a a staffed Premium booth at Africa Blockchain Festival 2026 (October 15–17, Nairobi, 3,000+ registered delegates), a side event at Western Delicacy (an already-onboarded Nairobi restaurant accepting shielded ZEC), a 30-day virtual 3-day onboarding session with task-based retention, and developer cohort recruitment — targeting 65+ ZODL onboards, 40+ verifiable on-chain z2z transactions, 100+ new community members, and 200+ documented conversations. Requesting $11,040.

      • Gguy: I have concerns around the structure of this grant, especially that a lot of it — or all of it — is startup funding. I want to confirm that first.

      • Artkor: I reviewed the recent activity of this team and I think I’m ready to support this proposal in its current form.

      • Hanh: I’m supportive too. I’m a bit concerned as well about all the funding being up front, but on the other hand they have to pay for this before they attend. I would suggest a 50/50 split: 50% up front and 50% on delivery.

      • Artkor: The materials are prepared in advance, and the booth also has to be paid for upfront.

      • Paul: I think it’s reasonable to do the 50/50 split, and I would support it if we can take that approach.

      • Zerodartz: I did some research on the team and they have some track record already. Maybe the 50/50 option won’t work — the booth would still have to be paid up front, I think — but some of the other costs could be paid afterwards. Leaning to approve, but I would like to see some adjustments.

      • Hanh: I also share the concern that they seem to push their KarSend integration. Since I don’t know what it is, I would rather not have ZCG associated with that product if it turns out to be a scam.

      • Gguy: It sounds like we have a few things to work out first. Does someone want to reach out to the team?

      • Artkor: I can, tomorrow.

      • Remains open (pending a revised payment split; Artkor to contact the applicant)

  • Zcash Integration in Coin Wallet (WebZjs + lightwalletd)

    • Applicant requests a grant to add first-class Zcash support (Unified Address receive, z→z/z→t/t→z with memos, on-device scanning/proving/signing) to an existing 25+ chain wallet (browser, Electron, mobile) using WebZjs with Ironwood support, backed by self-operated lightwalletd infrastructure including a Tor endpoint. Requesting $100,000.

      • Artkor: I don’t have a problem with adding Zcash to Coin Wallet, but I find the full $100,000 request difficult to justify. Coin Wallet is already a commercial product with transaction fees and an existing swap business, so adding ZEC can create value for them as well. It is also a very competitive wallet market, and their own target is only a few thousand ZEC users. If this were breaking entirely new ground, the request would be easier for me to support. That is also why I think it is useful to look at what similar Zcash wallet work has cost. While the projects are not directly comparable, Noir recently built a Zcash wallet from scratch for about $54,000, which is a useful reference point.

      • Hanh: We checked both proposals — this one and the next one go together. This one is a wallet based on the Zcash JavaScript library that they are proposing to build as part of the second grant. It would be a pure-JavaScript wallet that runs in the browser, and for security reasons I don’t think it’s appropriate to have secret keys stored in the browser. Independently of that, the amount of work to reimplement all the logic of zero-knowledge proofs, Halo 2, Ironwood and so on in JavaScript seems to be a very wasteful effort and actually provides less security and less benefit than what we have. In my opinion this is not very worthwhile.

      • Artkor: To clarify on the first proposal, I reject.

      • Gguy: I generally agree with the other members’ feedback.

      • Paul: I agree.

      • Zerodartz: I also agree. Coin Wallet isn’t the biggest wallet we have seen apply, so in that sense there’s less impact on Zcash users, and the JavaScript library doesn’t seem secure enough for Zcash standards.

      • Declined

1 Like
  • zcashlib: A Pure-JavaScript Zcash Library

    • Applicant requests a forward grant to build the first pure-JavaScript implementation of Zcash’s shielded protocol — transparent transactions, shielded key hierarchy/viewing keys/Unified Addresses, trial decryption/commitment tree/background scanning, and a JavaScript Groth16 prover for Sapling circuits — validated against official test vectors and librustzcash, with no WASM or native bindings. Requesting $150,000.

      • Artkor: In addition to the concerns already mentioned, everyone who has ever served on ZCG knows how expensive it is for the community to maintain libraries over time. In this case I don’t think it makes much sense to support two similar ones in parallel. The library we already have, and that is already being used, is enough. So I reject the second proposal too.

      • Gguy: As stated for the previous grant, we’re rejecting this one as well today.

      • Declined

  • Zcash Awareness, Education & Community Growth Campaign

    • Applicant requests a grant for a social media marketing campaign on X and Binance Square — educational threads, posts, and articles about Zcash’s privacy features and technical updates, with community engagement and query responses. Requesting $5,000.

      • Artkor: I didn’t find anything in the accounts that were provided that gave me confidence this project makes sense, so I decline this.

      • Gguy: I also struggled to see the value in this project.

      • Paul: I would reject. I can’t imagine that we need a growth campaign on X at this point. If everyone else’s feed is like mine, it’s dominated by Zcash. I just can’t imagine there’s value in funding more education on X.

      • Zerodartz: Agreed. Decline.

      • Declined

  • Zcash Flutter Wallet SDK

    • Applicant requests a grant to build a production Flutter plugin for the Zcash Android and Swift Wallet SDKs — a stable Dart API with typed platform bridge (Pigeon), Swift/Kotlin adapters to official SDK public APIs, lifecycle management, capability matrix, automated CI, and 6 months of post-release maintenance — explicitly not a wallet UI, not a new wallet engine, and not direct Rust FFI. Requesting $10,000.

      • Gguy: A year or two ago this might have been something I would have looked at more closely, but as it exists today, and given the changes in AI and software development, I don’t think this is something I’m willing to fund at this amount.

      • Hanh: There actually are a few wallets out there that already use this technology. YWallet uses Flutter for the UI with librustzcash and some private Rust code for the back end, so this is not new. Lately we have a couple of other wallets doing the same thing — Vizor is also on Flutter and Zkool is also on Flutter. The approach we have all taken differs from this one, because we have the back end and business logic in Rust and use code generation to bind between Flutter and Rust. What they propose to do here is fairly manual binding. If they do manual binding, the price they quote is too low; if they do automatic binding, it is too high, because obviously you can do it automatically. And if they do automatic binding it would actually be not that useful, because librustzcash does not have the abstractions that are needed to call it natively from Flutter. Long story short, this doesn’t really fit anywhere, so I reject.

      • Declined

  • 24 Videos @zkMarketer

    • Applicant requests a grant to fund 12 weeks of 2-per-week short documentary-style films (24 total) assembled from existing ecosystem footage — clips from protocol engineers, co-founders, outside commentators, and institutional voices threaded into single-argument 2-minute films, with everything downloadable at full quality, no credit required. Requesting $60,000.

      • Gguy: I think we were impressed with some of the content we’ve already seen, and we’re looking to approve this one today.

      • Artkor: He has already shown that he can make good Zcash content, and I’ve seen in practice that this is exactly the kind of content that tends to spread organically and reach a wider audience. I approve.

      • Paul: I approve. I really appreciate the approach taken here to demonstrate the kind of product that can be created and give us something concrete to evaluate before asking for ZCG funding. That is super helpful in this case. I think the content is great, the price is reasonable, and it’s generating a lot of content in a short amount of time with milestones. I think it’s a really good project. Happy to approve.

      • Zerodartz: The strength is that a lot of Zcashers have already supported these videos by sharing them on Twitter, and they have done quite well also numbers wise — they’re very well edited and put together. So even though the budget is a bit on the higher side compared with the industry average for short-form videos, it makes sense, since the quality and research of the topics is there. It’s $2,500 per video. I approve.

      • Approved

  • ZecScope (Zcash network upgrade / ZIP tracker)

    • Applicant proposes a public open-source website tracking Zcash ZIPs, network upgrade roadmap, wallet readiness matrix, and ZCG funding/resourcing view — modeled on Ethereum’s Forkcast, with automated sync from the zips repo and PR-based wallet team submissions, plus an 8-week post-launch stabilization window. Requesting $36,300.

      • Hanh: I’m not clear what it’s going to do. I like the idea, but I don’t know if it’s going to work out, because a lot of the data is not easy to collect.

      • Gguy: I also had concerns that a lot of this information might require manual input and can’t be automated or sourced from GitHub or a document that already exists. I may reach out to the applicant to make them aware that this might not be possible, even though I like the idea.

      • Hanh: When they say network upgrade roadmap, we were concerned that we don’t have a roadmap for network upgrades as far as I know. The ZIP tracker is also very challenging, because there are tons of ZIPs in different states — some abandoned, some in progress — and you can’t really tell from GitHub. The wallet readiness matrix is also challenging, because some wallets report things that are not exactly correct and some don’t report anything; I’m one of the ones who doesn’t report much. It would be good to have, it’s just very challenging.

      • Zerodartz: That’s good feedback for developers and the community — we should have a clearer roadmap for the network upgrades.

      • Remains open (data availability concerns; Gguy to contact the applicant)

  • Kestrel + ZecAuth: Open Zcash Wallet Connectivity with African Fiat On/Off-Ramps

    • Applicant requests a grant to productionize three integrated components: ZecAuth (scoped wallet-to-application authorization protocol), Kestrel (production self-custodial Zcash wallet derived from their ZecWallet prototype), and KuvarSend’s ZecAuth integration (first production fiat↔ZEC on/off-ramp using ZecAuth, targeting African local currencies) — with 1,200+ registered users, 600+ transactions, and $30,000+ volume already on KuvarSend. Requesting $12,000.

      • Artkor: I don’t have a clear decision on this one yet, but I’m inclined to decline it, because a big part of the project seems to depend on KuvarSend’s existing payment infrastructure, and from what I understand that infrastructure already exists and is already being used — at least based on the East Africa proposal we discussed today. So I’m not sure what exactly ZCG would be funded here.

      • Too early to vote

  • Zcash Wallet State Integrity: Self-Healing Transaction History

    • Applicant requests a grant to fix three specific transaction-history integrity defects in zcash_client_sqlite — nullable trust_status in v_transactions (causing complete history query failure in mobile SDKs), unusable stored transaction bytes blocking re-retrieval, and missing shielded output attribution when funding account is discovered after storage — with regression tests and mobile SDK validation for each. Requesting $8,500.

      • Hanh: He’s offering to fix a couple of bugs. In cases like this it’s a matter of knowing whether these bugs are worth fixing. There are a bunch of things in the GitHub issue database which are old issues that nobody really cares about anymore. It’s not worth just picking a bug, and the price is very high — several thousand for one bug.

      • Too early to vote

  • Research on a fully constant-time proving pipeline for open-source hardware wallet architectures, reusable for standard computers

    • Applicant requests a grant to research and implement architecture-specific constant-time alternatives to algorithms in the Halo2 proving pipeline — targeting STT chips/FPGAs for AST parsing and potentially full proving, with secondary x86-64 and ARM implementations for desktop/mobile, motivated by the hardware wallet context where full circuit validation is currently impractical. Requesting $96,000.

      • Too early to vote
2 Likes