Thanks, that does make it clear, I was assuming that you’d intend additional 1-year extensions 
After the one year extension, you’d recommend that block subsidies are ended (until the governance system is completed).
Does this mean you’d suggest, then after the governance system is complete, a new debate about how much (newly instantiated) block subsidy would have to happen?
ECC is not funding Qedit. They have one grant and have asked the ZCG for another. Beyond that is hypothetical.
Each organization is responsible for its own treasury. Under this model, these aren’t somehow pooled into a Zcash collective, and their balance sheets may change over time as they pursue additional means of funding for sustainability.
What governance system are you referring to? Are you talking about Zcash governance (i.e. what goes into the protocol) or funding allocations (this proposal)? I am only proposing the latter and presuming something like this is achievable before Nov 2025.
No, I am not presuming any further debate or the need for one.
Amen to this!
I meant “Zcash Funding Bloc” as a the governance system. Unrelated to the current, smaller/ technical governance processes that involve the protocol.
The coin weighted voting implementation is what has me feeling skeptical. Coordination among the three existing orgs would also be a challenge, but I think it is doable on a 20 month timeline.
I tend to be less optimistic with estimations, same was as you are. I do believe that it would be professionally irresponsible making a foundational change like this be on the shoulders of one Org. ZF, ECC and others should work on this together to make it less centralized, have more developer headcount and more eyes looking at the same codebase.
9 women don’t make a baby in a month, it’s true. But developer times can be actually lowered with more headcount when the right processes are in place. It doesn’t happen magically neither overnight. But it’s possible because most teams do. Zcash has a rather small development community.
The one year cliff on funding makes sense assuming the community understands that time will be taken away from other things to accomplish the “self-sustaining” model. A year should be more than enough time to get each org’s cards in order, and if they can’t then maybe it wasn’t the right structure to begin with.
Shining light on the use of Zcash Funding Bloc member organizations financials is one of the most effective tools of community and legal accountability. Hence the stellar leadership decision of your predecessor setting up:
### Why release a transparency report?
Electric Coin Co. is committed to openness and transparency — as we help evolve and support the Zcash digital currency, and in support of our mission to empower people with economic freedom. This transparency report details company income, expenses, and use of funds.
This theme match by your peer organization should be matched by the Zcash Funding Bloc members.
Joshs: Why this limit on the total grant size? It’s conceivable to me that advantageous grants may exist well in excess of this amount.
In theory its conceivable, however in practice the funds have been captured by a very limited few. The ecosystem needs growth and much more broad adoption and development. I completely agree and thank for your statement:
Joshs: I agree that we must avoid assuming all activities will be funded completely by block subsidies. This model is intended to encourage more resilient participants and community accountability.
By limiting the the grant size to $500k , its conceivable we get much faster software development an educational deployment with substantial increased accountability and reduce the culture of continuous delay and extend.
Good work on engaging the community, it would be great if you reach out to your network an ask the largest grantees to comment on your proposal.
Hey Zcash! I don’t know if this is the right place to put this comment, but as I’ve been watching the community have lots of good talks the last few months about where Zcash is now, where it’s going, and how best to get it on the best path, I just want to add one thing to your discussions.
Here at Birdcalls / The Internet Phone Booth, when we did our deep dive into Zcash’s infrastructure, we found that there was a lot of software that had been developed for a Zcash grant that was then never maintained after the final grant payout. So a lot of great stuff that was nearly or all the way unusable. Crumbling buildings.
If I were restructuring the way Zcash does grants, I would allocate a huge swath of capital to the maintenance and improvement of existing infrastructure. Grant payments that have maintenance payouts allocated over at least 2 - 5 years.
Best of luck! Keep holding down the fort of being the good guys in privacy-focused payments.
Cheers,
Sunny @ Birdcalls
This is exactly the problem with trying to build a subsidy based ecosystem. They collapse under their own weight because capital is not allocated optimally with what customers want. I’m not saying customers don’t want birdcalls. But the grantee needs to have a model that charges customers directly so that it can be self sustaining without dependence on inflationary funding provided by block rewards. The Zcash ecosystem cant support an unlimited number of edge use cases each with its own maintenance and ongoing improvements, all charging 0 to their customers when the blockchain itself has real mining and ongoing development costs of its own. Zec price should be able to go to 0 and the grantee wouldn’t care because they collect directly from customers. if it’s a product customers want, they will pay for the service. This mechanism to enable edge use cases such as Birdcalls to charge customers directly is either missing from a fee based ecosystem or to the extent the grantee is able to charge customers, it should be vetted as part of the grant process to only fund (actually seed is a better word) viable, self sustaining services being created on the Zcash blockchain: ultimately these edge use cases should expect to pay fees to the Zcash blockchain as well.
Sure! Thanks! 
Thanks for the update.
I finally signed up for this forum after being invested in Zcash since the beginning. I believe it is asking a lot from investors and holders to continue with the current funding for another year. Although I still believe that Zcash has the potential to be significant and is needed by everyone, I would expect to see much more progress in terms of adoption, tools, and more.
I do believe funding is a good thing and unique, however, with the funding everyone should be able to vote independently and multi-sig should be used to release funds.
I wonder if it would be possible to fund based on transaction fees instead of the block reward. This way, funding would be directly tied to zcash usage.
Another interesting grants option is to make them retroactive, similar to what Optimism is doing.
Retroactive funding of public goods has its challenges due to the need to bootstrap some things, but I think it could be quite a powerful tool.
In this case, the Zcash Funding Bloc would define spending categories (protocol, dev tooling, user tools, education, etc.). Grants would be given retroactively once the team delivers and demonstrates value. This would help reduce speculation and waste, while generously awarding participants that move the needle.
Optimism has allocated 20% of its total issuance for this—850 M OP, or about $2.7B at today’s price.
See their Twitter thread here.
More information here.
I love the idea of retroactive funding, and think it should be explored 
For examples see Namada, and for a more local solution even Dao.Dao has a retroactive module that can be played with.
For example, we can create a cycle that lasts a month for anyone to submit work they think is valuable to the community. When created, the cycle will set aside a certain amount of funds to distribute and after the deadline all submissions are voted on by the DAO.
This is a sure fire way to trim the fat and moochers of the dev fund, IMO. I’m all for it.
I assume a premium is required to incentivise organisations to take risks on retroactive funding? Are we talking 20%, 50%, 100%?
My worry is to make this work QEDIT’s grants now cost the community $4m instead of $2m. I think that engulfs most of the cost savings this program might produce. That’s assuming QEDIT are even interested in retroactive grants 
.
Or are you suggesting when the community want coin weighted voting we ask Hanh to “pretty please develop coin weighted voting we promise we will give you a retroactive grant if you deliver”? Is that better than what we have now?
What about Least Authority? Can we rely on community resources for security and auditing to be attracted to and contribute when faced with retroactive funding?
The issue is we should be begging these types of people and organisations to continue to contribute to Zcash. I believe limiting funds to a retroactive model adds barriers to entry into the Zcash ecosystem and pushing these types of people and organisations away.
This is a fair point, but it doesn’t have to be binary.
I am disappointed with the overall results of the current grant program. It’s not the fault of the members but something structural. Several large grants were given without any or negligible impact on ZEC adoption (Arti/Tor). In some cases, recipients started and stopped (Trezor). Some deliverables were garbage (Blockchain Training Alliance).
In contrast, a notable example of demonstrating value before receiving a grant was Hahn’s work on YWallet and Warp Sync.
In the case of Qedit. I love the idea of ZSAs, but 1) they haven’t been delivered yet, and 2) we don’t know if they will be used. It’s speculative. It could be a massive driver of adoption. It might be a dud. As a Zcasher, I’d rather pay more if they deliver a ton of value to the network.
Who bears the risk of ZCG grants, ECC or ZF not- or under-performing?
ZEC holders do.
Who makes the decisions about what is funded and delivered?
A small group of ZCG members, ECC and ZF.
There is a clear lack of alignment. I believe the proposal for the Funding Bloc addresses, and retroactive funding can potentially improve outcomes.
In the proposal, I suggested the following: “The ZCG will be solely responsible for grants under a certain threshold. I suggest starting with a per grant cap of $200k and an annual cap of 20% of the grant-based development fund.”
While these might be retroactive, it could be up to the ZCG to determine its policies. The caps help keep things in check while allowing a lot of discretion. Retroactive grants could, in my opinion, improve ZCG’s effectiveness while giving it another tool for filtering and guiding the ecosystem.
For the remaining grants, the Bloc might do something like the following (somewhat arbitrary %s):
Set up a speculative investment fund (10%): seed funding innovation with significant but speculative upside. This might fund things like post-quantum cryptographic research or some untested business model that drives ZEC adoption. Speculative funds are given to proven parties without the expectation of specific milestones.
Maintenance fund (30%): protocol, community, security, etc., to keep things up and running. These might be longer grants, open to competition annually, or when SLAs are not met.
Retroactive grants fund (40%): based on demonstrated value to the network.
Again, at this point, these are just ideas for discussion and logic testing rather than a formal proposal. I appreciate the engagement.
Thanks for engaging @joshs I truely appreciate it 
.
So who funds Ledger, Maya, and Nym? Do you think it’s good for ZCG to fund these projects as milestone grants based grants or do you believe any of these teams would develop this work under a retroactive funding model?
A portion of the treasury is earmarked for bounties which will be in a multi-sig wallet.
Bounties are determined by a committee that works closely with the ECC/Zcash Foundation on their roadmap.
The bounties are sent to an initial vote to gauge community interest based on @hanh’s work: Coin Voting / Shielded Airdrop / Proof of Balance.
Said committee (ZCG or whoever it is) promotes these bounties through their social accounts, and when they have garnered enough interested participants who have submitted proposals, they will be sent to a final community vote which will determine who receives the grant.
The grants are then unlocked (from the wallet) after an additional vote from the community that determines each milestone has been properly achieved.
ChatGPT version for @GGuy:
We should probably stick to tested business strategies for ZEC adoption. This entrenched theory that ZEC block rewards ought to be budgeted for use on extraneous projects doesn’t square up with reality anymore, now that Zcash has fallen out of the Top 200.
Being involved/ invested with Zcash in and of itself is a highly speculative sort of investment fund, results so far have been poor, despite the more than $100,000,000 spent on the project/ nearly a decade of engineering, marketing, lobbying, et al.
Why on Earth should this community be biting off even more that it can’t chew?
How about we keep our resources and energies focused on Zcash for the next 4 years?
That doesn’t seem like a controversial suggestion to me.
Lets give it a try this time, rather than just giving lip service to “All in On ZEC”
If Zcash were a project sitting firmly in the Top 20, if the development teams weren’t near financial distress, or if the network had reached 100k transactions/ millions of users per day on an average, I would feel differently.
100% @noamchom
We have yet to see the profits from ECC trading/speculative investment profits filter back into the Zcash ecosystem as well. ECC has the money to fund a speculative investment in Qedit (ZSAs, and stablecoins). Why fund thse things on competing blockchains rather than the Zcash blockchain? We need to be more focused on Zcash. Take the 10% and fund Qedit. 10% of the $20m trading gains just happens to fund Qedit’s new request. Lets do it now as a speculative investment in our own chain: Programmability, ZSAs, Stablecoins, Opt-In compliance—> Lets make Zcash look more like DeFi. Build bridges, not islands…
