ECC endorsements & its ZIP withdrawn

Summary

ECC is endorsing the Lockbox for Decentralized Grants Allocation submitted by @skyl and Hybrid Deferred Dev Fund ZIP submitted by @aquietinvestor. We have a couple of concerns detailed in the Background section below.

Both represent the spirit of what we have seen in the polling completed by the community, embrace the spirit of decentralization, and represent the change we need.

Despite support from the community, I am withdrawing my ZIP proposal to extend the development fund by one year with a mandate to work toward a non-direct model. These other proposals are stronger and, we believe, more accurately reflect the community’s will.

We will not endorse any new model that provides direct funding to any organization other than to support ecosystem grants.

It’s time for Zcash to move away from its legacy funding model and into a bold new era!

Background

Now is the time to set Zcash free. And to be free, Zcash must be loosed from the shackles of guaranteed funding streams. We have a challenging task ahead of us. The old model is not yielding the results we need. Now is the time for a meaningful positive change that drives our momentum forward, not backward. We need greater decentralization and accountability for those, like us at ECC, who receive funding from Zcashers. If we do that, we’ll be better positioned to rocket around the sun.

After reviewing the community’s survey results and consulting with various community members, ECC team members, our regulatory legal team, and the Bootstrap board of directors, I no longer believe that it is in Zcash’s best interest to extend the development fund through a direct funding model, even if for a time.

The Lockbox and Hybrid Deferred Development Fund proposals both provide positive and meaningful change, and the community desires to see change by moving to a non-direct model, as evidenced by community polling. The Zcash Foundation chose not to provide this as an option in any of their ZCAP polls, so we cannot be sure of the ZF ZCAP preference, but all the other polled communities supported it.

While we support these proposals, we have a couple of considerations for the authors to consider.

The Lockbox ZIP specifies a 50% dev fund allocation. We have not seen any survey results that support this high allocation. Reducing it to 20% would be more in line with sentiment and a 50% allocation may create security risks if it doesn’t adequately fund miners.

Hybrid Deferred Development Fund ZIP specifies that ECC and ZF are ineligible for grants. As neither would receive direct funding, we aren’t sure why this restriction would be in place. A grant option could be useful if ECC or ZF has an unanticipated need or opportunity the community wishes to fund. We also advocate for a one-year model with the possibility of an extension, if necessary, rather than a guaranteed funding period of two years.

Thoughts on Other Proposed ZIPs

With the exception of the Zcash Foundation’s ZIP, all the other proposals have recognized the community’s sentiment. However, a few challenges with the other proposals give us pause, which we’ll list here. Of course, others may disagree, and everyone should vote for what they think best; this merely reflects ECC concerns.

Manufacturing Consent, proposed by @noamchom, includes a four-year direct funding mechanism and the introduction of Qedit as a new direct grantee.

Zcash Grants Fund - ZCG & Zechub and Zcash Grants Fund - ZCG proposed by @GGuy are in the spirit of the two we endorse. The only major difference is that they direct most or all of the funding to ZCG. This puts 19-20% of all block rewards in the hands of a five-person committee, affording that committee significant governance and financial control.

We cannot endorse the Dev Fund for ECC, ZF and Zcash Community Grants proposed by @Dodger of the Zcash Foundation for the following reasons:

  1. The Zcash Foundation did not consider the community’s preference for exploring a non-direct option in its polling or ZIP.
  2. Dodger stated that the foundation would be unbiased and simply reflect community sentiment and asked for feedback on its ZCAP member surveys. The community’s feedback on its polling was largely disregarded, causing significant confusion and frustration across the community, resulting in the community conducting its own polling.
  3. The ZIP mandates direct funding organizations despite all other polls showing that only a minority of the community supports renewing the direct funding model.
  4. The Zcash Foundation board of directors released a statement acknowledging strong community support for a non-direct model, but saying, “We recommend against adopting a ZIP that mandates a non-direct funding model at this time.” We submitted a response to the board but have not heard back. Other Zcash community members have since submitted proposals also including the mandate to explore a non-direct funding model.
  5. The ZIP author has included ECC as a recipient, even though we have repeatedly stated that we would not accept direct funding without a mandate.
  6. ECC is not eligible for grants in this proposal.
  7. The ZIP concentrates too much power with the Zcash Foundation and its affiliate, the FPF, as 100% of funding streams would go to their wallets.

This is an important moment for Zcash! If we cannot get clear community consensus on a ZIP, the development fund will end in November. While many in the community have signaled that they would like to see the development fund expire, a majority have expressed that they would prefer it continue.

I applaud all the ZIP proposers for stepping forward with their ideas, listening to the community, and working in the best interest of Zcash, freedom, and our collective future. Also, thank you to all the poll creators and voters. We are the die-hards, the change-makers, and the chain-breakers. We will have differences but will accomplish great things together, hand-in-hand. What an amazing community!

21 Likes

I believe that this is intended to inhibit ECC and ZF being ineligible for grants from ZCG. This seems to me like a reasonable way of aligning the interests of ECC and ZF around developing a distribution mechanism for the locked funds.

6 Likes

Excellent and clearly explained!

In Venezuela we have a saying when we want to talk about the possibility of flexibilization and change, we say: “That is not written in stone”.

ZIPs can be edited, polls can be adjusted, “rigid” positions can be softened, as long as there is real intention to change.

Let’s hope your call is heard, @joshs

3 Likes

hey @skyl where did u come up with 50%?

seems rather too high. otherwise i like the idea.

1 Like

In the interest of ensuring that a 20% deferral option is available to voters, I have opened Lockbox for Decentralized Grants Allocation (20% Option) by nuttycom · Pull Request #866 · zcash/zips · GitHub as well.

6 Likes

Agreed. On a scale of 0-5, I would rate @skyl’s proposal a “5” but only if the dev fund was kept at 20%. The 50% makes it a “1” for me.

4 Likes

Could you explain this a little more? What is the “20% deferral option,” and “available to voters” how?

1 Like

This PR simply changes the 50% parameter in @skyl’s ZIP to 20% and is otherwise identical (modulo that I changed the owners because I did not consult with him or with @aquietinvestor on whether they wanted to be listed as owners of the modified version; if they’re interested in being owners of this modified version I will re-add them to the owners list.)

6 Likes

To make the math readable, Jason’s Hybrid ZIP is allocating 12% into the “Lockbox” and 8% to the ZCG. As a supporter of ZCG, I’d like to see their organization funded for the years ahead, but I think the 12/8 split could potentially be less than ideal.

I like the idea of a larger lockbox allocation and an equal or smaller ZCG allocation. 18/7 would result in a 25% block subsidy/ issued reserve.

It seems like another round of polling could be helpful.

1 Like

Things I agree with:

  • Stopping the Dev Fund until community reaches consensus on proper funding system
  • No individual/org should have an address coded into the Zcash blockchain
  • Funding should go into a “Lockbox”, where funds can accumulate for future funding distribution
  • ZCG should not hold the sole power on how funds are delegated from Lockbox; community can choose to allocate funds from Lockbox to ZCG.(ZCG is not the community, they are part of it)
  • Keep it at 20%
  • Ok with ZF, ECC, QEDIT receiving funds from Lockbox if community finds value
9 Likes

In principle I am not against increasing the dev tax to accelerate development, but it’s hard for me to support it before I know exactly how the new system will work. There should also be some consideration of how this would affect miners and the security of the network. I support the 20% lockbox.

1 Like

We need all ZIP’s that will “officially” be voted on in an easy to read document, accessible to everyone.

Excited to vote for the future, but lets get organized.

:hearts: :zebra:

3 Likes

I might add that other grant funding programs like FundX of Cardano ended up in unfair competition between independent contributors and big founding organizations (or derivatives from them).
I’ve talked with people in other blockchain communities that saw this happen and it’s something we should be aware of.

For example, let’s use a grant like the one @emersonian is carrying out
Note: I’m using ECC as hypothetical grant applicant, not implying that ECC would actually do this. On the contrary, I’m pretty sure it’s something they won’t do

ECC has much more resources, background and knowledge to actually win this one grant over. Also, they might already have infrastructure paid in bulk that would be a cheaper price quote than the one an independent contributor could get from cloud providers.

Objectively, by price and efficiency of resources the Committe should grant ECC instead of the independent contributor because its a best deal for the buck, but mid-term centralization grows because a potential new actors are disuaded from applying to grants because they can’t compete with “Big Orgs”.

Conclusion:
Mixing community grants with big orgs is putting fish and sharks in the same pool. Big “OG” orgs shall not be forbidded to obtain funding, but this should be handled with care so we foster a diverse ecosystem with actors of all sizes

2 Likes

Instead of changing the proven system (20%), I’d like to see the focus be on creating funding streams for the “Lockbox” (via donations, custody of different assets, txn fees)

  • The previous Dev Fund was seen by many as a “public good” and it rightfully benefited the entire crypto ecosystem. What’s missing is a system that allows outside parties to contribution back to a Zcash Fund
  • Projects like Namada benefited from Zcash development and are rewarding the community with an airdrop(ty btw), but what’s to stop them from wanting to contribute to the sustainability of Zcash development as a whole?
5 Likes

The ZIP Editors are currently working on clarifying the important details all of the submitted ZIP proposals. Once those clarifications are done, it will be possible to create a document from the abstracts of the various proposals.

4 Likes

In your example, that would be one of the reasons to consider giving this particular project to ECC. Projects need to be cost-effective. That’s one of the defining factors of efficiency.

Based on what you’ve seen, does an organization focused on smaller grants, like ZCG, solve this problem?

I think we’ve overpaid miners to this point. 50% is easy to calculate and reason about. I think we want that much for engineering and other core needs. The idea of the lockbox though is that it will be much harder to access. Right now 12% goes directly to corporations where the executives can basically do whatever they feel like. 8% goes to the ZCG committee of 5 who I think have been a little bit too generous historically. The idea of the lockbox is that we really set aside a substantial portion for the future and that it will be much harder to get at the funds. The implementation of the disbursement mechanism is TBD but I would argue that there should be limits built in. Some ideas off the top of my head:

  • no more than 5000 ZEC per request
  • funds must sit for N blocks before they can be disbursed (eg 1 year)

This way the funds, even though they are there, wont be accessed and liquidated at such a rate as we have seen. With 50% issued indefinitely, I would like to see the balance accumulate over time for the first years and not be disbursed and liquidated easily.

I can do the napkin calculation later, but even at 50% of the remaining block reward, I think the total amount would still be dwarfed by the Founder’s Reward?

1 Like

I’m okay with changing the variable but I think folks should really think about what we want to see in the future and not be anchored to the inertia of the past.

1 Like

Decentralization, cost-effectiveness or “efficiency” not necessarily go together. There are cases where they are antonyms. Strictly speaking in terms of resource consumption, sometimes centralization is more efficient than decentralization.

For example, let’s say that 100% Internet uptime is important to me. So instead of having one ISP I decide to have three. That is not cost-effective nor efficient, but it has other benefits that I rationalize as a net positive over the cost overhead. Then economy starts not being good and the ISP bill starts to have a huge weight on my household. It happens that one of the ISPs launches a “Premium QoS” service that in theory would let me cancel one of the ISPs and reduce my Internet bill a 25% by cancelling one of the providers.

Shall I cancel it?

Well the answer is, as always, it depends.

In line with what I’ve written in response to the other quote above, I wouldn’t put things in terms of “solutions” because we are talking about potential risks.

Risk are “odds” and can’t be “solved”, they can be mitigated (lower their chance of ocurrence) .

That being said, I think that the spirit of all of this is mitigating the risk of centralization, because on a decentralized system is not a positive value.

What we want to avoid is the risk of centralization.

So when resources are scarse, resource efficiency can become a deciding factor, and it’s not illogical that it rationally outweighs others. We are all human.

Defining structures that protect the core values of our project is in fact a good thing to do to mitigate risks we don’t want to happen. Although, there’s no silver bullet. Tiered grant committee is on available tool.

1 Like

Of all the organizations that receive the mining award, miners are the only ones who do their job as advertised.

The hash rate is in decline. At a 50% mining reward, I am sure we will see a further significant drop in hash rate, network security, and, finally, coin price.

In any case, I don’t see the urge to carve a large portion of the mining reward when there is no concrete plan to use it.

You want to take 50% and put it in a box for the future.

I can’t imagine how you would explain this to a potential investor.

What is the sales pitch?

14 Likes