# Coinholder grants need to fund ecosystem work **URL:** \ **Category:** Governance\ **Created:** [November 2, 2026, 4:43pm UTC](https://forum.zcashcommunity.com/t/coinholder-grants-need-to-fund-ecosystem-work/58764 "2026-11-02T16:43:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![iJaack](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/ijaack/32/40052_2.png) [@iJaack](https://forum.zcashcommunity.com/u/iJaack)\ **Post date:** [November 2, 2026, 4:43pm UTC](https://forum.zcashcommunity.com/t/coinholder-grants-need-to-fund-ecosystem-work/58764/1 "2026-11-02T16:43:33Z")
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](https://github.com/zcash/zips/pull/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](https://github.com/zcash/zips/pull/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. ![01-approval-rates](https://global.discourse-cdn.com/zcash/original/3X/a/0/a028c8980be5f5c65ddebc2bd20e2c8935c5e81e.png) 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. ![02-q3-funding-split](https://global.discourse-cdn.com/zcash/original/3X/a/b/ab0708e874ca4ab0df825c61bcfe2cb80d7825c1.png) 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](https://forum.zcashcommunity.com/t/coinholder-directed-retroactive-grants-program-results-nov-2025/53487), [Q1 2026 tally](https://forum.zcashcommunity.com/t/polling-closed-coinholder-directed-grants-program-q1-round/55048/17), [Q3 2026 results](https://forum.zcashcommunity.com/t/q3-coinholder-directed-retroactive-grants-program-results/57909), [finalized Q3 tally](https://zvote.zfnd.org/shielded-vote/v1/vote-summary/2cba66eb16c7581a1692cb0b033785da0131059f645a0d2fb4dc2a5131505e01). ---
**Author:** ![emersonian](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/emersonian/32/42565_2.png) [@emersonian](https://forum.zcashcommunity.com/u/emersonian)\ **Post date:** [November 2, 2026, 6:42pm UTC](https://forum.zcashcommunity.com/t/coinholder-grants-need-to-fund-ecosystem-work/58764/2 "2026-11-02T18:42:21Z")
A huge limitation of coinholder grants today is that they are only retroactive. This centralizes significant contributors to entities with large amounts of time and/or capital they can invest, and to those willing to accept the large financial risk that coinholders may not reimburse them. No method exists yet to poll coinholder sentiment, willingness to reimburse, before starting a project. Currently, contributors can apply for quick-turnaround ZCG grants that are able to fund projects upfront, and disburse funds when certain milestones are met. It’s scary to spend over six figures on something then apply for coinholder retroactive funding. That “will I get reimbursed?” risk places a low ceiling on the ambition of potential contributors. I’m not likely to spend $500k on a “Zcash Village” at a major tech conference and invite our projects to have booths within it, as one example, then hope that coinholders reimburse me. Every retroactive grant applicant should include a ~20% reward for their financial risks taken and the associated anxiety. ---
**Author:** ![strahncryptography](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/strahncryptography/32/46464_2.png) [@strahncryptography](https://forum.zcashcommunity.com/u/strahncryptography)\ **Post date:** [November 2, 2026, 8:06pm UTC](https://forum.zcashcommunity.com/t/coinholder-grants-need-to-fund-ecosystem-work/58764/3 "2026-11-02T20:06:52Z")
> [@emersonian](#): > > A huge limitation of coinholder grants today is that they are only retroactive. 100%. Coinholders need to be able to fund proactive work. This should also be a ZIP presented alongside the Maxime Desalle, the Sean Bowe, the ZAP proposals, to coinholders for the vote in December. ---
**Author:** ![iJaack](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/ijaack/32/40052_2.png) [@iJaack](https://forum.zcashcommunity.com/u/iJaack)\ **Post date:** [November 2, 2026, 10:43pm UTC](https://forum.zcashcommunity.com/t/coinholder-grants-need-to-fund-ecosystem-work/58764/4 "2026-11-02T22:43:51Z")
I agree, and I think this needs a ZIP. Retroactive funding requires contributors to finance the work themselves and accept the risk of never being paid. That limits who can contribute and what they can realistically undertake, particularly for ongoing work such as developer support, business development, or merchant onboarding. A ZIP could address three areas: 1. **Prospective funding:** A path with defined deliverables, milestone payments, and accountability, alongside the existing retroactive model. 2. **Scope:** Explicit eligibility for BD, DevRel, education, merchant onboarding, and ecosystem support. 3. **Evaluation:** Clear guidance on the evidence expected, including how to assess completed periods of ongoing services and avoid double funding. Funding could be a mix of the current model adopted by ZCG and what’s popular in other ecosystem’s grant programs: **the application is accepted before the work has started** , while the payment **only goes through after the work is complete** , with milestone-based eligibility on a case-by-case basis. I’ll start working on a ZIP and update the original post when I do.