Zcash Community Grants (ZCG) Meeting Minutes 9/28/2026

Community Grants Community Grants Updates
1

Grant dashboard

Openzcash

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

Attendance:

  • Artkor

  • Zerodartz

  • Paul

  • Hanh

  • Gguy

  • Alex (FPF resource, notetaker)

All votes were unanimous except Zcash East Africa @ Africa Blockchain Festival 2026 (Zerodartz voted against), GraphSense Zcash Shielded Accounting Repair (Artkor voted against), and Human readable version of Ironwood formal verification (Paul abstained).

Key Takeaways:

Open Grant Proposals

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

      • Artkor: I support this grant. This team has been contributing through ZecHub for quite a while, and I think they’ve already shown that they are serious about Zcash. For me it’s time to give them a chance to represent Zcash at a major event in their region.

      • Hanh: I approve as well. I’m looking forward to seeing the reports for this event, since it’s advertised as being the biggest crypto event in Africa.

      • Gguy: I also approve, and I’m interested in seeing how this event goes.

      • Paul: Same here. Approve.

      • Zerodartz: I was initially quite positive and I think the team has shown they are able to lead events well, but we’ve had a lot of events and sponsored quite many already this year and I think a small pause in more events could make sense until the end of the year.. I’m going to decline this one.

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

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

      • Artkor: My main concern is that I don’t think the target audience is large enough to justify spending around $36,000. Core developers already have GitHub, direct communication, and their own tools for tracking dependencies and blockers, so I’m not sure a separate dashboard would change their workflow much. For people like us, it is also becoming much easier to get the same information directly from the code, pull requests, and commit history using AI, and even automate notifications or actions around important updates. For the broader audience, features like a wallet readiness matrix could be useful, but I’m not convinced they would have enough impact to justify a separate project at this cost. If this were integrated into an existing resource like ZecHub, I would see more value. But as a standalone website, I don’t think there is enough demand to justify the funding.

      • Paul: I would just note that there’s some really exciting work happening with OpenZcash, where they’re covering ZIPs, and I think this issue may already be covered there to a large degree.

      • Zerodartz: I also saw Zakura team doing a dashboard for NU7, so I think that covers a small part of this.

      • Gguy: I’ve also shared my concerns about how much of this can be automated and how much of it requires ongoing work. I’ll decline.

      • Zerodartz: It’s a decline from me.

      • Hanh: Decline for me as well. For only ZIPs, I don’t think there’s much demand. This is very technical, and people who are interested in it can follow the progress — I wouldn’t say easily, but there are ways to follow it, and unfortunately that isn’t really automatable. I could change my mind if there were a prototype or an example of what can be done, but I’m very skeptical as of now.

      • Declined

  • 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 would encourage teams doing integrations like this to use existing modules and infrastructure wherever possible, instead of building another specific integration layer. In this case, I think something like WalletConnect is probably a better direction, since it can already provide the transport and session layer for this kind of connection. I would actually be much more willing to fund good documentation, implementation guides, and practical feedback from their own experience, including what was difficult and what changes would make integrations easier for the next teams. That kind of work could reduce friction for everyone who comes after them, instead of creating another solution that is specific to one wallet and one service. So I decline this proposal.

      • Gguy: I agree. When the solution is less general to other products and apps within the ecosystem, it’s less attractive to me, so I’ll decline this one.

      • Hanh: Decline as well. The African payment rails — KuvarSend, Kestrel, all of these — are specific to a particular provider or company, so I don’t see this benefiting anything other than their company. They could do it, but I don’t see why we would fund something that is essentially their business.

      • Zerodartz: In general I’m happy to see more on and off ramps, but this one seems too specific and kind of small at the moment, so I don’t think it’s worth funding right now.

      • Paul: I also decline for similar reasons.

      • Declined

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

      • Artkor: Given the lack of interest from the maintainers of this library, I can’t support this proposal, even at this small ask. That may change if the maintainers show interest later, but right now I reject it.

      • Hanh: You can see from GitHub that the issue was not updated since that person posted. I decline.

      • Gguy: I think this one is declined today.

      • Declined

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

      • Artkor: I think this is technically very interesting research, and I appreciate that this team is doing serious work across several areas. My concern is the path to practical use. In the current Zcash hardware wallet model, proving and signing can already be separated: the heavy ZK proving can happen on a phone or computer, while the hardware device keeps the keys, checks the transaction, and signs it. So there is no clear need today for a hardware wallet to run a full prover itself. And because both Zcash proving systems and hardware architectures are evolving quickly, some of the implementation-specific work could become outdated before there is a clear product use for it. That means this project would mainly explore how far constant-time proving and specialized hardware acceleration can be pushed, without a clear path to a product or integration yet. So I see real research value here, but in the context of a ZCG grant I have mixed feelings about funding work that may remain purely experimental. I would really like to see this team funded for a project where we have a clearer idea of the practical result. I hope we get a proposal like that from them, but unfortunately I don’t think this is the one. I reject.

      • Hanh: In addition to what you said, I would also be careful when someone claims things about another company, in particular about Ledger here, without feedback or confirmation from that company. I don’t think what they say here is true, or that the rationale is correct, and it happens too often that somebody says there’s no such thing, or that they don’t do this or that, and the claim is never verified.

      • Paul: I reject as well. I’d need to see a vendor that’s committed to use, review, or integrate the libraries.

      • Zerodartz: I also can’t see a way that a hardware wallet, even a fast one, could be fast enough for good UX. With the new work from Zakura on the phone the proof takes half a second to a second on most phones, which is a big improvement, but I don’t think hardware wallets would reach anything close to that, so this grant doesn’t make much sense to me.

      • Hanh: I don’t see a reason why you would want to have a proving pipeline on a hardware wallet. It doesn’t bring anything to the security of the system. If he wants to justify this grant, and it’s not a cheap one, he should start with that.

      • Gguy: That’s a good point, Hanh. If we can imagine end-to-end solutions that we would like to fund all the way out to something an end user could get hold of, that’s great, but this feels like research that would require further work and grants to reach an end user. We don’t have a clear vision of that yet, so it’s hard to fund this one independently without a bigger, clearer picture of where this work will lead.

      • Hanh: For me there’s a fear-mongering aspect to it. It says these hardware wallets don’t do this or that, therefore they’re insecure, therefore I would do this — but that’s not necessarily true. The premise is that it’s insecure because it doesn’t do XYZ, and you first have to prove that that’s the case, which is brushed under the carpet. Otherwise you invest in work that is really, really hard, and at the end there’s no payoff.

      • Gguy: I agree. I’d need to see a demonstration of the end user experience and how that protects the user from the existing art. I’m skeptical.

      • Hanh: First he has to demonstrate that there is a security hole, and second that he’s filling that gap. The first part is missing.

      • Gguy: I will add that while I will decline today I am interested in this team being able to contribute in meaningful ways, but this one today just doesn’t quite fit. I prefer grants when I can imagine the deliverable being used by end users.

      • Declined

  • GraphSense Zcash Shielded Accounting Repair

    • Applicant requests a grant to complete the upstream review process for PR #163 in graphsense-lib — fixing missing Orchard and Ironwood value balances in GraphSense’s Zcash ingestion pipeline, with regression hardening, reproducible validation methodology, and operator handoff documentation. Requesting $8,000.

      • Artkor: I really want to repeat one important principle that came up in our discussion: Zcash should not be afraid of better analytics tools, because Zcash cryptography should remain strong regardless of how good those tools become. But I also have to think about what the community expects ZCG to fund. A significant part of the community expects us to prioritize projects that improve privacy, not projects that improve blockchain analytics. I have no objection to this work being done, but I’m not convinced ZCG is the right source of funding for it. There are other users of blockchain analytics who may have a much more direct reason to support this work. I reject.

      • Hanh: I agree with most of what you say. One aspect that makes me think is whether this tool can be used by Zcash community members to get a sense of the privacy of their own transactions. I agree we are not in the business of funding other services or companies to do chain analysis — that doesn’t really benefit Zcash. But if it can help Zcash users see that their transactions are not actually private, that could be a benefit to our users.

      • Gguy: It’s hard to know whether this will lead to any outcomes that will have an impact on the direction of Zcash or on its users. But given the amount being asked and the potential benefit of having these types of tools which sometimes sit behind closed doors in private companies and are not necessarily available to the wider community, I think having access to them matters. I’m also encouraged that this tool is used for research and studies, and I can see many papers have been published that use this tool for privacy of certain cryptocurrencies and ecosystems. Being open to researchers exploring Zcash and its privacy can provide a net benefit. I’m in favor of this one.

      • Paul: I’ve really been on the fence on this, because I’m not a fan of analytics tools. However, I do think the request is very modest, and there is value in having open-source and research-oriented tools for the reasons already discussed. So I would therefore be in favor as well.

      • Zerodartz: I’ve also had mixed feelings about this and I kind of agree with Artkor, but since it’s mostly for scientific papers and open-source projects, I think it’s better to have this fixed than not fixed and then have people get wrong results in Zcash-related research. I’m ready to approve.

      • Hanh: I think it makes sense. It’s a small ask and it’s the first one, so I would approve it, but I would not approve another one. It’s good to have one tool that other tools in our ecosystem can build on — for example, if a block explorer or a dashboard wants to use it to provide a privacy score, that’s something they don’t have to code themselves. So I take it as a tool for our community. I approve.

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

  • Rill shielded ZIP-321 Accept

    • Applicant proposes a grant to build a Zcash-native HTTP 402 payment gate — GET /r/{id} returns a ZIP-321 invoice (unified address, amount, memo=resource_id), a viewing-key watcher confirms shielded payment without spending authority, and a receipt unlocks the resource in standard MPP/x402 shape — with an optional West African fiat off-ramp (XOF via Wave/MTN on lomi.africa) as a final milestone. Requesting $95,000.

      • Artkor: I saw a lot of overlap between this proposal and the work Kenbak has already done in his project. I asked on the forum specifically what the differences were, and the answer didn’t convince me that there is enough additional value here, so I will reject this proposal.

      • Hanh: Reject too. For anything Zcash, this is the same as CypherPay; it just happens not to be Zcash-only, but we’re not very interested in anything other than Zcash.

      • Gguy: I agree, and I think this is quite a high ask for a grant like this compared with what we’ve approved before.

      • Zerodartz: I’m also declining, since the amount is quite high and we have similar features available with CypherPay.

      • Paul: I also decline.

      • Declined

  • 1CAD Protocol - ZK-TLS Proof-of-Solvency Infrastructure

    • Applicant proposes a modular ZK-TLS framework enabling users to generate locally-verified Evidence Packages proving AML/Source of Wealth compliance to institutions without disclosing raw financial documents — using zero-knowledge proofs as a privacy-preserving alternative to centralized document sharing. Requesting $20,000.

      • Artkor: The applicant attached a PDF white paper to the proposal, and honestly it took me straight back to the 2017 ICO era, when every other white paper promised some new blockchain-powered future. More importantly, almost none of the technical substance described in the GitHub proposal is actually in that document. So for me, that document creates more concerns than confidence. I reject this proposal.

      • Gguy: I will be declining this one today for similar reasons.

      • Hanh: This document doesn’t contain anything of substance. You don’t know what they do, and it repeats itself all the time. I wouldn’t even call it a marketing document, it’s so poorly made. Decline.

      • Zerodartz: If the idea had potential users showing demand right now I could see it being worth to fund if integrated into popular wallets. Right now I haven’t seen that.

      • Hanh: It would be great if it worked. The need for something like proof of solvency kind of makes sense, but this is like saying there’s a need for people to fly around the world and then not providing a plane. On the technical part, there’s nothing to be seen. I would love to have that, but this is just an idea.

      • Declined

  • Argos: zcashd Emergency Recovery Phrase Support

    • Applicant requests a grant to harden an existing MVP that adds zcashd emergency recovery phrase handling to Argos — covering legacy Sapling derivation paths (pre-4.7 entropy-based and post-4.7), phrase-derived transparent keys, regtest recovery tests with confirmed sweeps, clear limitation documentation, and an upstream Argos pull request — with Argos maintainers already confirmed as open to review. Requesting $10,000.

      • Artkor: I specifically checked the Sprout chart, and since Argos was presented in June, more than 3,000 ZEC have left the Sprout pool after a long period of very little activity. That is around 12% of the remaining balance, which is a great result, and I think the Argos developers deserve credit for building such a timely tool. So from my perspective, Argos is already useful and already working. I haven’t seen any indication that Argos actually needs the fix proposed in this grant. I reject.

      • Hanh: I reject because the use case is very narrow. As they say, it’s just people who have lost their zcashd wallet but still have the emergency recovery phrase.

      • Zerodartz: I’m going to decline. I could change my mind if anyone with funds stuck because of this problem comes to Argos team and demands this feature.

      • Gguy: I’m going to decline this one too.

      • Hanh: I think the recovery phrase is a zcashd-specific encoding of the seed of the random number generator. For very old wallets, before 4.7, they used a different, non-standard mechanism. I don’t know how many people are in this category.

      • Artkor: I haven’t seen any user requests for this specific recovery feature.

      • Declined

  • Zcash Ghana (October 2026 - December 2026)

    • Applicant requests continued funding for an active community program that has grown since June 2025 to 10 X-Spaces, 10 physical meetups, 6 workshops, 700+ persons educated/wallet-onboarded, and 450+ X followers — with a notable new addition: the maiden Zcash Privacy Developers Residency Programme bringing 10+ developers from Ghana, Nigeria, and Togo to build privacy projects on Zcash, facilitated by ZecHub, Nozy Wallet, Gleyo, Zutility, and ZOERDHUB. Requesting $12,600.

      • Hanh: We were going to approve this one.

      • Artkor: The concerns raised about the team were worth checking, but I didn’t see anything that changed my overall view of their work. I hope they take this incident into account and make their reporting even clearer and more detailed going forward. Overall I’m comfortable supporting them for another three months.

      • Gguy: I appreciate that they asked for three months. I think it’s a good time frame to continue assessing this new team.

      • Paul: I approve as well. Good track record so far, and I really do like the idea of better reporting to ensure there’s less community concern about future activities.

      • Zerodartz: I’m ready to approve, since they have raised their quality of reports in last months. I also looked into the concerns but the person complaining never gave us their evidence and while looking into their claims, most of those seem to be unfounded without any extra evidence. They have organized a lot of events this year, with a lot of people attending. In the future I’d like to see them get even more technical when they can, and continue educating.

      • Approved

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

    • Applicant proposes a DIY air-gapped Zcash signer built from generic Raspberry Pi Zero parts (~$35, buyable with cash, no purchase record) — PCZT/UR QR signing with on-device ZIP-244 sighash recomputation, no vendor supply chain, no wireless hardware, stateless by design — with a working proof-of-concept already benchmarked on real hardware (676ms median per action, no transaction size ceiling). Requesting $30,000.

      • Gguy: I think we declined this one in the past and they’ve come back with a lower request. Has anyone changed their mind?

      • Hanh: It remains a fun project. I don’t think people should use it to store their funds, and that’s my main concern. Of course the price was higher before and it’s now more reasonable, but my concern was also that the work required to put this together is comparable to just buying a hardware wallet off the shelf, and the security of an off-the-shelf hardware wallet is much better. I talked a little bit with this person and I don’t think he really understood my concerns, so I would not vote for this.

      • Zerodartz: If you want to hold a large amount of ZEC you would never use it, and if you want to hold a smaller amount you might as well store it on a hot or cold wallet on a modern phone. The security on the phone could be higher.

      • Gguy: That’s a good point. I think the open question is how much safer this is than storing it on your phone.

      • Hanh: This is definitely less secure.

      • Gguy: I’d hate the idea of ZCG to encourage users to use workflows like this when their phone is likely more secure in most circumstances.

      • Hanh: The part that is less secure is purely practical: the device does not hold a seed phrase. To use it you have to scan the seed every time you make a transaction — it is entirely stateless. That means you need to have your seed phrase next to you to use it, and that’s a recipe for disaster. Either you lose it because the QR code gets scratched, or somebody takes a picture of it. It encourages people to keep a copy of the seed phrase somewhere that isn’t secure.

      • Gguy: Thanks Hanh. I didn’t realize that was the only user flow. I’m declining today.

      • Hanh: It uses a SeedQR, a QR code that holds your seed phrase.

      • Paul: Decline.

      • Zerodartz: Decline.

      • Declined

  • Zcash Network School Kazakhstan

    • Applicant proposes to extend a completed Malaysia deployment to Astana Hub — running technical talks, office hours, workshops, and a build-a-thon, with local Telegram community building, self-custody wallet onboarding tied to session attendance, participant surveys tracking awareness/usage changes, and a local intern to sustain recurring work. Requesting $21,425.

      • Artkor: I’m ready to support this one. For me this is a reasonable way to expand something that has already shown it can work.

      • Hanh: We have sponsored something similar and it led to some good projects.

      • Paul: I’m really excited about seeing the network school activity continue in the new location, and this team has done some good work already. I’d love to see that all continue. Approve.

      • Zerodartz: I also think this team has done a good job so far with the last effort. The budget is reasonable, and it’s great to see they want to continue and onboard new people and educate them about Zcash.

      • Gguy: I appreciate the very reasonable ask. It makes it easy for us to approve grants like this that have impact.

      • Zerodartz: I would add that the school has a lot of builders, who are likely very valuable users, as they might even start building on Zcash instead of just only using it.

      • Approved

2 Likes
Grant Application - Zebra: auditing and closing the peer-supplied-count allocation class
Grant Application - Zcash Wallet State Integrity: Self-Healing Transaction History
Grant Application - Rill shielded ZIP-321 Accept
Grant Application - Research on a fully constant-time proving pipeline for open-source hardware wallet architectures, reusable for standard computers
Grant Application - 1CAD Protocol: ZK-TLS Proof-of-Solvency Infrastructure
Grant application - Zcash SeedSigner, a DIY open source air gapped signer for shielded ZEC (resubmission)
Grant application: ZIPs For Nerds, one explainer per ZIP
Grant Application: Verified Pasta Curve Operations, Poseidon R1CS Constraints, and Folding-Based Recursive Proof Architecture
Grant Application: Zcash Selected-Payment Receipts SDK
Grant Application — ZecScope (Zcash network upgrade / ZIP tracker)
Kestrel + ZecAuth: Open Zcash Wallet Connectivity with African Fiat On/Off-Ramps
Grant Application - Argos: zcashd Emergency Recovery Phrase Support
2

Part 2

  • ZIPs For Nerds

    • Applicant requests a grant for six full-depth explainers on NU7 candidate ZIPs — section-by-section spec readings with original diagrams, affected parties, and strongest objections stated plainly — published open access under CC BY 4.0, mirrored to the forum, with source in a public repo. Requesting $7,500.

      • Artkor: I think the idea is fine, but AI can already do this at whatever level of complexity the user wants. I reject.

      • Paul: Also, continuing to emphasize that OpenZcash already has that function. I reject.

      • Zerodartz: I also reject, since I don’t see enough new value in it as AI can help understand ZIPs much easier.

      • Gguy: It may sound simple up front, but what I sometimes see with projects like this is that it can be very quick for things to become stale and require ongoing work for them to remain valuable. So there’s an issue on both ends: is someone going to maintain this long term, and if they are, is that a task better automated with systems that exist today? While I agree there is value, unfortunately I’m going to decline this one today.

      • Declined

  • Verified Pasta Curve Operations, Poseidon R1CS Constraints, and Folding-Based Recursive Proof Architecture

    • Applicant requests a grant to package a completed bilingual golden-oracle verification methodology as a reusable toolkit for Zcash developers, and complete a production-scale instantiation (full Poseidon rounds, production SMT depth, epoch at k=476 / 6.4M constraints) — built on top of an already-verified Pasta curve proof system (41 modules, 34 passing gates, 1,032 test cases, 162 defects caught during development). Requesting $150,000.

      • Artkor: Given the amount being requested, I think we should get input from someone like Sean, who is directly working on Ragu. He’s probably the right person to tell us whether this work would actually be useful for Zcash or not.

      • Hanh: We can ask him. I think the main thing is that R1CS is a very old system that has been superseded by PLONK and Halo, so I’m not sure why we would use it.

      • Gguy: Does Ragu use the same curves? This grant describes verified Pasta curve operations. The project description says they can be used for Tachyon and Ragu.

      • Hanh: R1CS isn’t about the curve — it’s the arithmetization. I’m pretty sure it isn’t for Halo, because Halo has custom gates and R1CS doesn’t. I think Ragu is a constraint system, but it’s not R1CS, and I don’t understand what the value of this particular proposal is.

      • Zerodartz: I think it has no real measurable value for Zcash.

      • Hanh: On the forum, someone (forgot his name… s-crypto) says that Tachyon has superseded R1CS, and the applicant replies thanking him for confirming that Tachyon uses R1CS, which is the complete opposite of what was said.

      • Gguy: That’s interesting, because he does not say that within the application. I’m not confident that this will deliver something that will end up in users hands, or that the system as described will work rather than be superseded by later technologies in the era of Tachyon and Ragu. Unless the applicant wants to come back and provide us with more details regarding our concerns about project deliverability and utility within Tachyon, I’m going to decline.

      • Declined

  • Zebra: auditing and closing the peer-supplied-count allocation class

    • Applicant requests a grant to complete a systematic sweep of Zebra’s peer-supplied count allocation bug class — publishing a complete inventory across zebra-chain and zebra-network, upstream PRs for unbounded sites (beginning with issue #10566 and the connection.rs preallocation facet), and a regression harness enforcing the documented invariant — closing the class rather than remediating individual instances reactively. Requesting $28,000.

      • Hanh: We asked the ZF developers to give us feedback, and based on their response I decline.

      • Gguy: I struggle to see $28k of value in this, so I decline.

      • Paul: Decline.

      • Zerodartz: Decline.

      • Artkor: Me too.

      • Declined

  • Human readable version of Ironwood formal verification, first steps - bulletproofs in the AGM

    • Applicant requests a small forward grant to write a 6–8 page mathematical note presenting the simplified bulletproofs protocol proof (using the Algebraic Group Model) contained in the Ironwood formal verification Lean code — making the proof human-readable and citable as a standalone academic contribution. Requesting $8,000.

      • Hanh: To me it was very strange, and I would approve because I’m curious to see what’s next. In itself I don’t see much value, but it could be the beginning of a beautiful story.

      • Gguy: I would approve. Because of the reasonable ask I am willing to fund this.

      • Paul: I’m going to abstain from this one.

      • Artkor: I think it’s interesting and I hope it works out.

      • Hanh: I’m really curious to see how he’s going to pull it off, because it’s a human-readable version of the Ironwood formal verification, and there are very few things more complicated than that. The first step is bulletproofs in the Algebraic Group Model. It’s also only the first part: to understand the whole Ironwood work this is just step one, and considering how hard step one is, I wonder what steps two and three look like.

      • Zerodartz: I would consider it a success if I can read the outcome and understand exactly how part of Ironwood works. I am a bit mixed on the larger scale impact of it. Approve.

      • Approved (Abstained: Paul)

  • Zcash Selected-Payment Receipts SDK

    • Applicant proposes an open-source Selected-Payment Receipts SDK — user-controlled, scoped evidence export for individual shielded payments, with a defined evidence format, local export with disclosure preview, independent verification library/CLI, reference wallet, and consuming reference application — explicitly narrower than viewing keys and explicitly not claiming to prove payer identity. Requesting $42,000.

      • Hanh: This is the one where he wants a protocol that allows people to verify a transaction payment by giving the outgoing cipher key. Last time we talked about this, what I said is that there is something similar in Sapling, and maybe even in Sprout: a ZIP was opened but never implemented. I was wondering why it was never implemented, considering that it doesn’t seem to be very hard, and it’s been a long time — we’ve had Orchard and Ironwood since. So maybe we are missing some difficulty or some privacy edge case.

      • Gguy: While I’m a big supporter of receipts like this, and I do know there have been ZIPs for it, we haven’t actually seen any implementation in a wallet. I think this is the type of thing that usually needs to come out of a wallet team. I’m not sure a third-party SDK is necessarily going to get wallet integration. If there is interest in this, I’d like to see one of the wallet teams show their support for a project like this.

      • Hanh: For me, as a wallet developer, I’m not super keen on implementing this, because I would need to have a ZIP — not because it’s hard. It’s more that I’m concerned it’s going to break privacy in some subtle way. It’s really not hard: if you give your outgoing cipher key, you can decrypt.

      • Gguy: Correct, and I imagine many other wallet developers would have similar views. It can be very hard to adopt third-party SDKs like this while trying to protect your users.

      • Paul: I’m interested, but I agree. I’d like to see a ZIP and coordination with the protocol developers.

      • Hanh: We could ask him, if he’s interested in being funded, to take over ownership of the ZIP and make it Ironwood-compatible. As it is, it would be declined, and if he does something it would be very different, so he might as well open a new proposal.

      • Gguy: Agreed. Let’s decline this one today.

      • Declined

  • P2P Cash-to-ZEC Onboarding via Bank CDMs

    • Applicant requests a grant to build a cash-deposit-machine (CDM) based P2P ZEC on/off-ramp for India — physical cash at bank kiosks paired with shielded ZEC payouts to unified addresses, using NEAR smart contract escrow, a $10,000 bootstrapped liquidity pool, and a ZEC buyback treasury funded by protocol fees. Requesting $40,500.

      • Remains open

  • Zebra-Native Non-Custodial Mining Stack

    • Applicant requests a grant to open-source and productionize a working non-custodial Zcash mining pool engine (live at zec.robotbase.cc since September 2026, Zebra v6.3.0, ZIP-244 mode-2 coinbase, 2,700+ shares at 99.7% valid rate), plus a validated independent deployment runbook and a public monitored lightwalletd endpoint with six-pool telemetry API. Requesting $19,500.

    • Remains open

  • Bitcointalk Signature Campaign & ZEC Community Engagement

    • Applicant requests a grant for a 3-month Bitcointalk signature campaign — 40 high-rank accounts (Legendary, Hero, Sr. Member) carrying a Zcash banner for 12 weeks (~14,400 banner-carrying posts), plus three monthly ZEC price prediction contests ($1,000 prize pool each, entries requiring a shielded address). Requesting $90,000.

      • Artkor: In my view this is one of the worst forms of paid promotion.

      • Zerodartz: Agreed, this in no way is worth it.

      • Declined

  • Zcash Africa Privacy Engineering Residency Pilot

    • Applicant proposes a 6-month Zcash Africa Privacy Engineering Residency Pilot — a staged funnel from online discovery (150+ applicants → 75 foundation) through technical academy (40), physical residency in Lagos (25), build challenge (10–15 teams, 5–8 prototypes), and 3 months post-residency support — targeting privacy-preserving payment use cases for African contexts (mobile money, remittances, merchant payments, aid). Requesting $49,000.

      • Remains open

  • Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve

    • Applicant requests a grant to build an independent NSM reserve and supply accounting tool — a command-line recomputer fed only raw block bytes (getblock 0), reconciled height-by-height against Zebra and Zakura, with test vectors for ZIP 259’s open “Add reference implementations and test vectors” issue, a full-history ledger, Testnet/Mainnet NU7 block-by-block reconciliation, and a proposal to run daily verification after Zebra’s weekly Mainnet sync. Requesting $50,000.

      • Remains open

  • Mexico Tech Week October 2026 - Zcash México

    • Applicant proposes a ~50-person masquerade-themed Zcash community event on October 31 as part of México Tech Week — introductory talk, expert privacy panel, ZEC quiz with prizes, live music, costume contest, networking with food/drinks, and ZEC distribution to attendees — pre-approved on the México Tech Week calendar pending venue confirmation. Requesting $7,980.

      • Remains open

  • Zcash Privacy Ecosystem Mapping & Adoption Data

    • Applicant requests a grant to close the measurement gaps explicitly flagged in the June 2026 summit edition — live wallet testing on real devices with real funds (time-to-first-shielded-transaction, proof generation time, sync behavior, error rates), reproducible derivation of the shielded adoption figure, and an updated ecosystem mapping — published as standalone open datasets under CC BY 4.0. Requesting $5,000.

      • Remains open

  • Shielded x402: private machine payments for Zcash

    • Applicant requests a grant to bring shielded ZEC into the x402 AI agent payment ecosystem — delivering a “Shielded x402” specification mapping x402 semantics to Zcash shielded transfers, a reference facilitator with testnet demo, and zshield-spendguard (spend limits, allowlists, audit trail for shielded agent wallets). Requesting $42,000.

    • Gguy: While I’m very open to funding Agentic AI work this is not one of them. ZCG is not ready to fund projects in this way yet. We are also aware that this agent has been contacting other users inappropriately. Declined.

    • Declined

  • Zcash Türkiye University Tour 2026 — ZCG Grant Proposal

    • Applicant proposes a 10-university pilot campus tour (~3,360 km across Istanbul, Bursa, Kayseri, Elazığ, Muş, and Van over ~30 days) — Zcash 101 presentations, Zodl wallet setup with first shielded transaction, starter ZEC incentive, quiz, networking, and a Campus Representative selected from each university with a follow-up online event within 30 days. Requesting $27,000.

      • Remains open
4 Likes
3

Literally 100% expected lol, this went like 100% what I predicted in my head it would-

Then again I am at fault here too, this was sort of a bogus proposal to be honest, I wouldn’t have accepted myself