Zcash Funding Bloc : A Dev Fund Proposal from Josh at ECC

Josh I agree with your comments. I appreciate your candid comments.

I too am disappointed with the results of the current grant program.

Zcash has made a lot of progress, but it hasn’t seen the light of day on the price side. Zcash marketcap outside the top 200 is a serious problem.

This suggests that we have a problem.

The percentage of developer funding should not increase any further.

The amount of money we have spent on grants so far is by no means small.

Just looking at the forums, it seems that most people are only actively participating in the developer funding, while regular Zcash holders are disappointed with the price and are not participating.

This seems wrong - the Zcash Forum is a forum for Zcash holders, not a forum for getting developer funding.

Thank you Josh. It’s great for the Zcash community to have Josh back.


I can’t get behind this retroactive funding model. In my opinion it sets up a huge barrier for developers outside of the two main orgs to start work on an idea.

1 Like

A couple more thoughts on this subject matter. This funding bloc will essentially turn ECC/ZF et al into contractors.

Does this mean they will have to change their legal structure away from a not for profit entity?

Also, where does the money come from for all the unsexy stuff like maintenance/lobbying/other things generally unseen however important? Does all that get cut?

I could even see this model go a step further and have the road map and direction of zcash controlled by funding bloc participants, of which coin weighted voters would have an equal vote to the orgs, then each roadmap item can be put out to tender for anyone and funding is issued by approval of the bloc.

Overall I like this system the best out of all the proposals, there may be some bugs to work out though.

1 Like

@Dodger sick him :point_up_2:

“You should put all the stake into the development fund because I’m going to hold onto ZEC forever.”

Whoever puts forward a DEV FUND proposal based on this idea should be the winner :trophy:.

Hi Zeeps,

I have received questions about the dev fund decision process and my grant-based idea.

1. Dev Fund: July Decision for November Activation

Why do we need to decide by the end of July?

If a new development fund is to be activated in November, it must be decided this summer. This will allow enough time for engineering and audits, migration to testnet with an activation height set, and then adoption by exchanges and miners well ahead of a November activation.

How will the community decide?

There must be clear social consensus across the community. To achieve this, the ZF, ECC, and others may run polls or surveys in different forms (ZCAP or ZAC polling, forum polling, etc.). Ultimate consensus occurs by what software the majority of nodes choose to run.

What happens without clear social consensus for a new dev fund or the structure of a new dev fund?

The current development fund expires in November as planned.

If no dev fund exists, what will happen to ECC, ZF, and ZCG (and the downstream grant recipients)?

They must raise money through outside sources or ramp down over time.

2. Grant-based: 2025 and forward

What is your proposal for this year?

The summary is here. I recommend extending the current development allocation for one year with a mandate that the community move to a decentralized grants-based model no later than November 2025.

Why a grants-based model over the status quo or something similar?

The current model is brittle, too centralized, and not sufficiently decentralized. Here’s a summary of today’s model with a better future for Zcash.

Extending Today’s Model Grants-based Model
Apathy where the community doesn’t push for better outcomes because they don’t feel empowered Engagement where the community has more voice and more opportunity.
Ineffectiveness where organizations aren’t pressured to deliver Achievement where organizations must deliver tangible outcomes
Misallocation where organizations only deliver what they want Alignment where the community’s voice is continually reflected based on where they allocate funds
Centralization and Fragility where a few funded organizations control direction and can be captured or shut down Decentralization and Agility where funding is based on more voices and can be adapted as more voices enter or leave the ecosystem
Easy Regulatory Targeting: today ECC and ZF are both under SEC subpoena, opening the community to a myriad of risks Resilience: a legion of participants around the world who are driving Zcash forward
Deviancy where the goodness and health of specific organizations can change or erode over time Accountability where the community can easily change course based on who is delivering and how

I posted a more complete rationale on our blog.

What does a grants-based model look like?

A possible model is posted here, at the top of this thread. The remaining FAQ is based on this model. In summary, the dev fund is placed in a multi-sig wallet. Keys are distributed to various independent community participants. A majority of key holders (k/n) must sign a transaction to signal affirmation for any decision. Decisions include support for a grant, adding or removing key holders, and disbursements. It might also include protocol changes. It might look something like what is shown in the following diagram. This is just an example of potential participating decision bodies.

How does a grant get approved?

A grant request is posted to a central location, like the forum. Each member of the Zcash Funding Bloc independently determines whether a grant should be approved. Once a member approves a grant, they sign their key. A grant is not approved until a majority has signed. Funds are not dispersed at this time.

How are funds dispersed?

A grant will likely include milestones and accountability requirements. Once those are proven, members are asked to sign their key to release funding. The funds will not be dispersed until a majority has signed.

Are there different types of grants?

Yes. A grant might fund an entire organization’s operating expenses for a year or a specific project. It could be anything, really. It’s up to all the members to decide whether the grant best supports the best interests of Zcash.

For small grants, say less than $100k, a small grants body (such as ZCG) could unilaterally decide to fund the grant up to a cap. Someone might even apply for a grant to create their own grant pool!

Who decides who gets a key to participate in decision-making?

Anyone can ask to become a member. The majority of existing members must approve new membership by signing their key.

Do coin holders get a say?

Coin-holders are envisioned as having the means to vote on their coins, which would, in turn, sign their key.

Could some members have more than one key?

It’s possible, but we want to avoid a concentration of power.

What happens if a key holder misbehaves or ceases to exist?

The other members could vote to remove their key.

Can signers delegate responsibilities?

Members may choose their own method of making a decision. For example, in a DAO, voting members may make a decision.

Can this also be used for protocol governance?


Are there any legal issues with this type of structure?

There may be issues with providing grants to certain parties or limiting decision-making power to too few parties. Further research is needed.

Does this help with current regulatory issues?

It removes centralization and jurisdictional risks, including risks where organizations need to cease operations. It also distributes power, which would be of benefit. Further research should be conducted.

What steps will ECC take next?

We will write ZIPs for community consideration, conduct research on legal and regulatory risks, and continue gathering community feedback.


Love where this is headed.


  • What incentives will be in place ( if any ) , to insure active participation on key votes?
  • Is there a quorum? If so , what happens if its not reached.
  • Is it possible a tie happens? What happens if multiple re-votes are still tied?
  • Will voting be public or private?
  • What is the min vote needed to pass a given proposal?
  • Are key holders eligible to submit proposals?
  • Do key holders have term limits?
  • Does it matter how each group forms its members? ( coin holders need to have a certain amount of coins for example, or do the coins need to be shielded)
  • What percentage of the vote does each theoretical group hold?
  • Does the core engineer group have any special veto powers (because of their critical nature) ?

Thanks for any insight :heart_eyes:


Hi @Josh, glad your considering the legal risks. It’s possible that four of the seven key holders mentioned could be considered non-US entities in the future as we try to hedge again US based risk, either by operating as DAOs or by being registered in other countries. These entities could potentially leverage this status to fund initiatives beneficial to the Zcash community, albeit with questionable legal risks within the US.

My understanding has always been that the developer fund’s inclusion in the protocol rules protects entities from each other’s legal troubles. For instance, under a direct funding mechanism, if the Zcash Foundation (ZF) encounters legal issues, it doesn’t necessarily mean ECC will face the same issues. However, if ECC approves a transaction to fund ZF and it can be argued that ECC was aware of ZF’s intended actions, would ECC then also be implicated?

My understanding as a non-US citizen was that the best protection in the US is code because it’s protected as free speech. Is it in our best interests to move to a key based approach that doesn’t offer those same protections?


Thank you for the questions. My responses reflect the current iteration, but this is all open to different ideas and alternatives.

The community will be able to see whether they are active. If key holders aren’t living up to their obligations, they can be voted out by the other key holders.

If a majority consensus is not reached, nothing happens. You have to get enough yeses (signatures) for anything to move. A non-signature isn’t necessarily “no.” It might be, but it also might be that the signer is still deliberating or waiting for additional information before making a decision.

I think a signature (approval) should be public.

A simple majority

Yes, but they can not approve anything for themselves. For example, assume there are seven keyholders, and one of the keyholders submits a grant proposal. In that case, four of the other six keyholders must sign to approve the grant.

Not as envisioned. A design goal was to expand the number of voices by adding more ecosystem participants over time.

It’s up to each group that requests to be a key holder to communicate how they are structured and will determine what to approve. It’s then up to the existing members to approve adding the new member.

It’s equally distributed, and the percentage is based on the number of members. If there are three, then they have 33.3%, if there are seven, each has 14.3%.

Not as envisioned


This has been proven to not be the case. Both are currently facing the same regulatory issues.

I’m not sure why this would trigger anything. All key signings would be public and not concurrent, meaning everyone would know how and when a member signed for a given action.

The cleanest approach is to let the dev fund expire in November. Full stop.

Any other approach has regulatory implications, which should be assessed. While ECC will get legal and regulatory advice on the grants approach, I recommend that any new dev fund proposal be reviewed in light of the current regulatory climate.


I prefer a model where funds aren’t systematically taken from blocks in advance but only once projects are approved and need them.


I agree with @hanh , we need a less aggressive rupture, giving time to adapt to the new reality.


It seems that a good number want the development fund to be terminated, but in my opinion, a very aggressive rupture could equally demotivate everyone who receives financial benefits from the development fund. I believe that the people involved and beneficiaries of the development fund need time to adapt to the new reality, knowing exactly when the development fund will end and organizing themselves in this period of time until the fund ceases to exist, seeking new forms of financing.

1 Like

I favor a model where the dev fund is removed. When projects need funding, they raise it from any source they want including mining rewards. In the current model, this feels like a budget that must be used up, leading to inefficiency.


nothing prevents the the current organizations receiving additional funding or from seeking donations outside of the block reward. I am not aware of any of them doing this.


I like the idea of ending the development fund, this will reduce the selling pressure on Zcash a little, I believe that after the migration to the POS the selling pressure will decrease even more, putting an end to the miners.

it seems that many agree with the inefficiency of the developer fund, I can’t give much of an opinion, as I am new to the world of cryptocurrencies and Zcash was the first and only currency I have in my wallet, I discovered Zcash in 2020/2021.

I feel that Zcash needs to renew, eliminate, change the culture, be more decentralized, be less burdened by the policies of the United States.

I will only ask one thing, please do not change the total supply of 21 million coins, this will cause shortages, increasing the market value. the rest, any changes that come are good. Zcash is an amazing currency and for me it is better than Bitcoin and I prefer to buy Zcash and have it in my wallet.


I believe this is a red line for 99% of the Zcash community as well as a deal breaker for potential future Zcashers.


1. Dev Fund: July Decision for November Activation
Why do we need to decide by the end of July?
If a new development fund is to be activated in November, it must be decided this summer. This will allow enough time for engineering and audits, migration to testnet with an activation height set, and then adoption by exchanges and miners well ahead of a November activation.

Urgency - Is what creates action. All organizations an individuals have known the November timeframe. Why should the zcash community contribute to the culture of delay by extending the deadline. The urgency of the November deadline creates the demand for compromise. Should ZF & ECC hold urgent meetings to flush out any differences, present the findings to the community.

I would like to see no delays or extensions to November Deadline.

Drive hard for common solutions, now!

1 Like

Is “core developers” an hypothetical group of signers or is it part of the proposal?

If so, would you mind expanding a bit on it?