Assuming the community moves forward with the joint ZCG restructuring proposal, coinholder grants will become more important to funding work across Zcash. ZCG will retain a treasury, but its recurring funding will end while the coinholder stream continues. PR #1428.
Coinholders should be prepared to fund the work needed to turn Zcash into something more people can build on and use. That includes business development, developer relations, merchant onboarding, education, regional communities and ongoing support, alongside protocol and application development.
At Zcon, discussions returned to several practical gaps: people unaware of existing products, external partners unsure whom to contact, developers struggling with integrations, and users needing help after onboarding. Addressing these gaps requires people who work with partners, builders and communities over time.
Daira-Emma’s Zcash Adoption Pool proposal, PR #1431, is relevant here. It takes a different funding approach by retaining ZCG’s 8% stream, but points to a purpose already present in ZIP 1015: supporting independent teams and a range of work that improves usability, security, privacy and adoption. That broader purpose should carry into coinholder grants as their role grows.
The funding record gives us a starting point. Across the three completed rounds reviewed—Q4 2025, Q1 2026 and Q3 2026—23 of 52 proposals passed. Grouped by their main purpose, developer tooling received no approvals across seven proposal votes; messaging, identity, accounting and related applications received none across eight.
The Q3 amounts were more concentrated: $7.81 million of $8.39 million in approved requests, or 93.1%, went to security work and core protocol or operational infrastructure. All other categories combined accounted for $578,000.
Q3 included emergency work following the Orchard vulnerability, which explains much of that allocation. These results do not establish rejection rates for BD or DevRel, or whether rejected projects deserved funding. They show what has been rewarded so far; they should not become an assumed template for everything worth funding next.
The question for future rounds is whether someone who delivers useful BD, DevRel or support work has a reasonable prospect of being paid for it.
For BD, a proposal could document a partner integration that is deployed and used, explain the contributor’s role, and identify the benefit to the wider ecosystem. For DevRel, it could show external teams helped through integration problems, documentation maintained and projects that continued building. Community work could demonstrate merchant use, useful local education or support delivered.
These contributions need evidence and scrutiny. Their value will often emerge through other people’s work and over a longer period, so immediate transaction growth cannot be the only measure. Evidence should also respect the privacy of the people being helped.
Ongoing services need a clear route through the retroactive model. A documented quarter of developer support or merchant onboarding is a period of completed work, even if the service continues. Applicants should know how to present it, distinguish it from previously funded activity and request compensation.
For the next rounds, I would like to see:
- Calls for proposals that explicitly include BD, DevRel, adoption and ecosystem support.
- Published examples of the evidence voters would find persuasive for each type of work.
- Feedback that helps rejected applicants understand what would improve a future submission.
If coinholder grants are expected to fund the ecosystem’s public goods, their decisions need to support the people doing this work too.
Data notes: this analysis covers coinholder grant votes only, with no ZCG decisions included. Repeated applications and bonus nominations count separately. Categories were assigned by primary project purpose, are open to review, and do not measure project quality. Approval means passing the vote; the earlier ECC request passed and was later vetoed. Dollar amounts are approved requests, not verified payments. Q2 2026 was postponed into Q3 and is not counted again.
Sources: Q4 2025 results, Q1 2026 tally, Q3 2026 results, finalized Q3 tally.