NU6.1: Coinholder-Directed Retroactive Grants Program

Governance
1

I’m proposing that the Coinholder Grants Program, which will be seeded by the existing lockbox and receive 12% of block rewards through the third halving in 2028, be structured as a retroactive grants program. This proposal, outlined below, will ultimately require coinholder approval before being implemented. I presented this concept at the Z|ECC Summit in Prague and have outlined the full details below. Thank you to @alex_zf, @joshs, and all Z|ECC Summit attendees for their helpful feedback.

Background

In November 2024, the Zcash community adopted ZIP 1015 as a temporary funding model. This allocated 8% of block rewards to Zcash Community Grants (ZCG) and 12% to a protocol lockbox to ensure continued funding for development while the community worked toward a long-term solution. ZIP 1015 was guided by several principles: ending direct funding to specific organizations, transitioning to a grants-based model, decentralizing governance, and creating transparent processes for distributing funds.

ZIP 1015 is set to expire in November 2025. At that point, the Community and Coinholder Funding Model (C&C) will take effect, directing future block rewards to a Coinholder Grants Program and Zcash Community Grants. The C&C model will remain in place until Zcash’s third halving in 2028 and is intended to support a more decentralized, community-driven funding process.

Community and Coinholder Funding Model

As part of Network Upgrade 6.1 (NU6.1), Zcash will implement the Community and Coinholder Funding Model. Under this model, ZIP 1016 states:

  • 12% of block rewards will flow to the Coinholder Grants Program from November 2025 until Zcash’s third halving in 2028.

  • 8% of block rewards will continue to fund Zcash Community Grants (ZCG) during this period.

  • Initial capital for the Coinholder Grants Program will come from the Deferred Dev Fund Lockbox, which will hold approximately 70,000 ZEC when the C&C funding model goes into effect.

  • Keyholder Organizations will manage these funds via a legally binding multisig wallet. Keyholders are required to execute coinholder-approved funding decisions but retain veto authority if proposals pose legal, regulatory, or community-harm concerns. At the start, the three keyholder organizations will be ECC, ZF, and Shielded Labs.

  • This model places direct control of grant allocations in the hands of coinholders, ensuring funding decisions reflect community priorities. A minimum participation threshold of 420,000 ZEC (roughly 2% of total supply) ensures meaningful voter engagement.

  • While ZIP 1016 mandates a clear, transparent process for evaluating proposals and gathering community input, the specific voting mechanism will be defined separately in a future ZIP. This proposal (outlining a retroactive grants program) represents the process that is intended to be formalized in that future ZIP.

Coinholder-Directed Retroactive Grants Program

I propose that the Coinholder Grants Program be structured as a retroactive grants program. Under this model, grants would be awarded only for work that is already fully completed, rather than funding work based on milestones as ZCG does. This approach is intended to simplify the grants process, reduce administrative complexity, and ensure accountability by paying only for completed and verifiable work.

The existing ZCG model is not a good fit for the Coinholder Grants Program. Milestone-based grant programs like ZCG require constant oversight, fund management, and ongoing coordination with grantees, which makes it too complex for a coinholder-driven process.

For example, when ZCG approves a grant, the Financial Privacy Foundation (FPF), which administers the program, converts the approved amount of ZEC to USD to protect against price volatility and ensure the grant can be fully paid. A retroactive grants program avoids this entirely: since funding is awarded after work is completed, payouts can be made directly from the multisig wallet at the current market price, without hedging or complex fund management. While it may not be suitable for every project, the retroactive model provides a scalable solution that works well with coinholder voting.

FPF will administer the Coinholder Grants Program, but in a more limited role than ZCG focused on managing the grant submission process, performing KYC checks for grants above $50,000, and maintaining transparency reporting. FPF may request a small administrative fee from coinholders to cover these responsibilities.

Benefits of Retroactive Grants

  • Grants are awarded only for work already completed, reducing the risk of paying for incomplete or low-quality work.

  • Simplifies the process by focusing solely on evaluating delivered work, removing the need for milestone tracking or ongoing approvals.

  • Avoids the complexity and high-touch oversight required by milestone-based models like ZCG, making it a better fit for coinholder voting.

  • Minimizes administrative overhead and allows projects to operate independently.

  • Enables direct payouts from the multisig wallet without complex fund management or hedging.

Drawbacks of Retroactive Grants

  • Requires teams to self-finance their work before applying for funding, which may discourage smaller or less-capitalized participants.

  • Higher risk for builders, as they could complete the work but still not receive funding if coinholders decide their proposal isn’t worthwhile. However, if a proposal is rejected, the team can still submit it for consideration through ZCG.

  • Teams may be hesitant to pursue larger or riskier projects without the security of milestone-based, upfront commitments.

Three Distinct Grant Programs

With this new retroactive grants program, Zcash will operate three distinct grant programs:

  • Zcash Community Grants (ZCG): Flexible grants program with a large budget. Milestone-based funding for medium and large projects. Grants are paid as work progresses. The committee is also open to approving retroactive grants in certain circumstances.

  • Coinholder Grants Program: A quarterly grants program structured for retroactive funding, where grants are awarded only for completed work. This program is best suited for teams that can complete their projects before applying for funding. It offers a straightforward process focused on rewarding delivered results.

  • ZecHub Bounty Program: A ZCG-funded program run independently by ZecHub that provides small grants and bounties for grassroots community and educational initiatives. Designed to offer quick and easy funding for smaller contributions.

Coinholder Grants Program: Process Overview

The Coinholder Grants Program will operate as follows:

  • Public Call for Proposals: At the start of each quarterly cycle, a public call for proposals is issued via forums, social media, and blog posts. Proposals must be submitted via GitHub and mirrored on community forums for visibility and feedback. FPF will administer this process.

  • Proposal Structure: This program uses a retroactive grants model. Applicants submit proposals for work already completed. Funding requests are denominated in USD, but paid in ZEC from a multisig wallet.

  • Submission Deadlines: Proposals must be submitted at least 30 days before voting begins. Keyholder Organizations conduct an initial review and retain veto authority if proposals pose legal, regulatory, or community-harm concerns.

  • Proposal Summary: Before polling, a summary of all proposals is published by FPF. This includes total requested funding, potential treasury impact, and historical funding outcomes to help coinholders evaluate spending decisions.

  • Voting Process: Each proposal is voted on individually as a Yes/No question. A minimum participation threshold of 420,000 ZEC per proposal is required. Proposals require a simple majority to pass. An open question remains whether partial funding should be permitted if a proposal’s full request cannot be met.

  • Voting Results / Approved Proposals: Approved proposals are ranked by total “Yes” votes and funded in sequence until the treasury budget is exhausted. Payments are made directly from the multisig wallet, without requiring fund management or hedging.

  • Disbursement & Oversight: Payments are made only after deliverables are verified. KYC checks are required before disbursements above $50,000. Keyholders retain authority to pause or veto payments post-approval if legal or ethical issues arise.

Implementation Timeline

  • July 2025 – Gather Community Sentiment: Collect feedback at the Z|ECC Summit and from the broader Zcash community.

  • August 2025 – Coinholder Ratification Vote: Continue gathering community input. Also, open the coinholder registration period and vote to ratify the retroactive grants program and resolve open questions (e.g. whether partial funding should be allowed if a proposal can’t be fully funded).

  • September 2025 – Call for Proposals: Issue a public call for proposals via Zcash Community Forum and other community channels.

  • October 2025 – Proposal Review Period: Proposals are discussed publicly on the Zcash Community Forum and GitHub. The submission deadline is set for 30 days before the vote.

  • November 2025 – Coinholder Vote on Proposals: Open a coinholder registration period followed by a vote to approve or reject submitted proposals.

  • December 2025 – Fund Distribution: Funds are distributed to approved proposals via the multisig wallet.

1600×905 212 KB

Conclusion

This proposal outlines a scalable, easy-to-implement retroactive grants program that’s designed to put funding decisions directly in the hands of ZEC holders. Please let me know if you have any questions, comments, or feedback. I’m looking forward to a vibrant and productive discussion!

PS: We need a name for this program. Please let me know if you have any suggestions.

Questions For Coinholders

  • Should the Coinholder Grants Program be limited to retroactive grants only?
  • Should partial funding be allowed if a proposal can’t be fully funded?
  • Should the Coinholder Grants Program accept transparent ZEC or be limited to shielded ZEC to incentivize shielded adoption (after Ledger adds shielded support and/or once engagement is assessed after the first round of grant polling)?
30 Likes
2

Thank you for pulling this together @aquietinvestor!

9 Likes
3

i support more like this

3 Likes
4

Love it, but I have a question on who will conduct the coinvote. Should it be independent parties? Should they get paid for providing important infra? Can anyone help trustlessly? What does the verification of the vote process look like and how can the community follow up and verify results?

Thank you!

5 Likes
5

Shielded Labs will run the first round of the process, since I’m familiar with it and can help get FPF up to speed on how to manage it. The goal is to transition this role to FPF as part of their responsibility for administering the Coinholder Grants Program. FPF should receive funding to cover the cost of providing administrative support.

Multiple independent parties should serve as Voting Authorities and run BFT nodes to help maintain the integrity of the process. I think at some point in the future, it would be ideal for the program’s administration to be handled by independent community members acting on behalf of coinholders, but for now, FPF is best positioned to manage this role.

The Coin Voting 2.0 protocol has an audit mechanism. Anyone can run an audit by downloading the audit tool and entering in the election seed phrase and URL. See the post below for more information.

5 Likes
6

I think a small public bounty could help participation whilst futher decentralizing the process. I love FPF, but they shouldn’t be holding all the cards if we can avoid it.

2 Likes
7

I am curious if there any limits to the grant request? If someone requires amount A and its greater than whats currently avail in the fund, does that imply they will keep getting paid until fufilled?

8

@dismad, agreed there is an opportunity for further decentralization with this project. We’ll say this: if another administrative option doesn’t present itself then FPF would be happy to provide the support Jason details above. If an existing group in the Zcash ecosystem would like to talk through the legal and other ramifications for providing this type of support then please reach out and we’ll share our perspective.

We’d consider it a win if we could help another group step up and take this on, but, in the absence of another option, we’d be happy to provide the support as proposed.

7 Likes
9

I was more refering to folks running nodes, I sincerely hope that is still legal. BFT works better with moar nodes :slight_smile: Thanks for all your hard work :shield:

2 Likes
10

That’s an awesome start, thanks for the great work @aquietinvestor! Let’s try this for a year, gather feedback and fine tune where needed.

I think transparent voting is important for various reasons and I would like to make sure it remains an option, could you please clarify this aspect?

SGG: Skin in the Game Governance

3 Likes
11

Thanks for putting this together, @aquietinvestor. I strongly support this initiative.

As a side note, it’s refreshing to see a proposal that wasn’t obviously assembled in its entirety by an LLM!

I like @outgoing.doze’s SGG, but propose an alternative:

ZERG-E: Zcash Ecosystem Retroactive Grants Endowment

4 Likes
12

Agreed. I think the Coinholder Grants Program should include both shielded and transparent ZEC to the extent possible, similar to the Dev Fund and Funding Model polling from May 2025.

I’ll draft the voting process into a ZIP once the process details are finalized and the grants program is ratified by coinholders.

2 Likes
13

I would like to see us incentivize shielded storage, though I can see the argument of waiting until Ledger adds shielded support and/or after the first round of grant polling to see the level of engagement, given the min threshold.

7 Likes
14

Caution: Hot! :hot_springs:

This feels like a significant moment. We’re seeing broad consensus continuing to form around incremental but definitely non-trivial upgrades to our funding model. This appears to be another example of continued contributions and participation that fills in gaps with proposals that are workable and practical. This is a clear reflection of the increase in positive, constructive collaboration that has been building.

Huge congrats to @aquietinvestor and everyone who contributed. This has “Zcash is winning” feels :tada:! Let’s keep this momentum :person_running::dashing_away:! :shield:

14 Likes
15

I see both sides of the argument. Curious to hear what everyone else thinks?

I’ll start keeping track of open questions like this at the end of the OP for discussion and to potentially include in the poll next month when we ask coinholders to approve the retroactive grants program.

Here’s what I have so far:

  • Should the Coinholder Grants Program be limited to retroactive grants only?
  • Should partial funding be allowed if a proposal can’t be fully funded?
  • Should the Coinholder Grants Program accept transparent ZEC or be limited to shielded ZEC to incentivize shielded adoption (after Ledger adds shielded support and/or once engagement is assessed after the first round of grant polling)?
2 Likes
16

Cool proposal, I like it.

I’m kind of torn between the two, I can see both sides of the argument. I’m leaning a bit more towards incentivizing shielded storage, but only after Ledger has shielded support and ideally voting integration into Zashi. I think one can only expect widespread coin holder voting if it’s both easy (Zashi integration) and safe (hardware wallet support) and then it would be justified to kill transparent voting.

I think that’s a good idea. ZCG already allows to apply for milestone based funding. Such grants are not only a lot of work for the people assessing them, but also for the people applying for them. Retroactive grands would be more efficient for both sides (for applicants that can handle the financial risk), and ZCG is available for milestone based funding (for applicants that cannot or do not want to).

I suppose you mean if a retroactive grant was voted on as “yes”, but there are not enough funds to be dispersed in the program this quarter? I think in that case partial funding should be allowed, since coin holder voting was clear and something of value has been delivered. It just raises the question of how to do the partial funding in practice. Cut all approved retroactive grants proportionally to their size until they fit into the budget for the quarter?

5 Likes
17

I’ve been going back and fourth on this issue.

Indeed, there shouldn’t even be a consideration of shielded only voting if we don’t have a good shielded offline wallets. Good means many things but for me support for SSSS is one, having a decent track record over time is another, etc.

Just as importantly, @zooko had convincing arguments regarding keeping the transparent mechanism. Sometimes, we do want transparency, and there are a few cases for that. Hopefully I can delegate my votes at some point, but if I cannot verify how that person is voting it may unnecessarily introduce trust. Also with the pools deprecation, some people may prefer to keep their tokens in transparent addresses to avoid the risk of having their tokens deprecated should they ever blink too long.

Basically, while for deprecating Sprout we are mostly all in agreement aside from the method to do it, removing the transparent mechanisms is a lot more of a divisive issue with both sides having good arguments. Sounds to me like we should keep discussing this, keep our options and the discussion open until we eventually have a higher level of support of either side.

2 Likes
18

I think this model is very powerful, especially if it’s well-articulated as a complement, not a replacement. It values results and encourages autonomous creation, but it can’t be the only model if we want a diverse community, with creators from a variety of backgrounds.

1 Like
19

Consent-based transparency is available through viewing keys.

4 Likes
20

Okay, sounds good. Looking forward to the day I can delegate that way!

To the other point, assuming I have kids, I want to be able to put some ZEC into a wallet they’ll access when they are 18 without having to wonder if the ZEC devs have decided those tokens are no longer worth their time or something.

For now and until a sensible solution is found, those tokens will stay in a t-addr, and my vote will push for keeping a pool that actually works as a SoV.

1 Like