Draft ZIP: Defer Lockbox Distribution and Extend the Current Dev Fund

This ZIP is a perfect example of why coinholder voting is absolutely necessary and must be included in the decision-making process.

It doesn’t even matter who is in the right here. The point is that every stakeholder should have the right to an opinion and be able to express it.

If ZIP reviewers have so much power that they can label a ZIP they do not like as “not legitimate” mainly because of some semantics, how can you say that Zcash and its governance is decentralized? It did not even come to a vote, the ZIP was taken out before that by the power of a very small group. Although these are very knowledgeable and experienced people whose opinions I value a lot, this is not right. IMO this ZIP is legitimate to be voted on.

So far, I find these debates extremely healthy for our decision-making. Sure, there are people here who defend their financial income (rightly so, because they have already done a lot for Zcash and want to continue to build). And there are people with a big stack of ZEC and financial risk who want to have more influence in the decision making (rightly so, because they have hardly had any influence so far).

Obviously, Zcash participants with different views clash here. The emotions and discussions show that the topic is important to all of us and everyone wants the best possible outcome. That’s a good thing, onwards! Please do not censor, as long as it stays respectful without ad hominem attacks.

2 Likes

I hope that voting can increase the miners’ fee income. Miners already have no income.

That’s not correct.

The intended effect is to decrease the likelihood of further delays by preventing disbursement from the lockbox until ZSAs are active on Mainnet.

This is something I could have pointed out had I been invited to the meeting at which my own ZIP was being discussed. :roll_eyes:

3 Likes

I will point out that the ZIP Editors do not have a governance role, and are not responsible to make any sort of decision as to whether or not a given proposal is included in the polling; that is up to the entities responsible for constructing the poll. If polling found sufficient support for the rejected ZIP, then that could be sufficient cause to reopen the ZIP (though with my ZIP Editor hat on, it would still require modifications.)

The fundamental problem with this ZIP is that it is not actionable. It essentially says “the community must reject any network upgrade that did not conform to this particular prioritization in its development.” However, the individuals that choose to run Zcash network nodes, and in particular miners, are not governed by the ZIP process - they choose what software they want to run.

This ZIP, as currently written, is attempting therefore to direct the action of independent actors in the Zcash ecosystem (1) in a way that contravenes ZIP 1014, specifically this:

This slice will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

The ZIP Editor meetings are open, and participation in the #zips channel of the R&D Discord is encouraged for those who wish to attend.

1 Like

And yet, you’ve assumed one by attempting to reject a ZIP that you don’t like.

Incorrect. It says that the community chooses to keep the Lockbox funds locked up until ZSAs are activated on Mainnet.

That is not correct.

If the community chooses to keep the Lockbox funds locked up until ZSAs are activated on Mainnet, “independent actors” may still do whatever they want.

If those “independent actors” decide that they are going to boycott or refuse to assist with the deprecation of zcashd, and the deployment of ZSAs in protest at the community’s decision, the community can react accordingly (e.g. by deciding to issue grants to other parties who can move those efforts forward).

ZIP 1014 applies to the funds that were distributed under the first Dev Fund. It has no relevance here.

1 Like

No. We rejected this zip for exactly the reasons we stated. If you are interested in correcting the errors in your ZIP, you’re welcome to do so.

Since Zcash is not centralized, any entity can implement a change to the consensus protocol that creates a lockbox distribution mechanism at any point. Miners can then choose to activate that hard fork. This isn’t something that’s subject to governance, except insofar as ZF is technically capable of exercising the Zcash trademark to ensure that such a fork is not allowed to use the mark (which they have pledged not to do.)

I don’t know where you got the impression that anyone was planning to do this. The ECC and ZF teams, along with the ZingoLabs folks, are actively working on both ZSA activation and zcashd deprecation. Maybe you should learn to code and help out?

This governance by programmers has got to stop. Unbearable.

I agree; after the experience here I think that the ZIP process is basically unsuitable for governance decisions. It was always an awkward fit. ZIPs should be strictly for specification of protocol and wallet-relevant features; a governance decision or process might need ZIPs in order to be implemented at the protocol or wallet level, but the social contracts themselves should be outside the scope of what’s considered suitable for a ZIP. I think that the “community” (whatever that means) needs a different mechanism for formalizing and recording its decisions.

2 Likes

[With my personal hat on, not my ZF board member hat]

I think that might be the crux of the disagreement here.

Just as a thought experiment, let’s think of “the community” as a single entity Mr. Community who has hired contractors to build a house. The contractors have been doing a really great job building this house on a solid foundation, making sure it surpasses code requirements, going above and beyond to get the house done better than expected. But Mr. Community really, really needs a shed to be built in his back yard to store his motorbike, because if that’s not built soon his motorbike is going to get damaged by the next hail storm. It’s so important to him that he says: I’m going to withhold payments to all the contractors until my shed gets built (even to the electrician who has nothing to do with his shed). Mr. Community has paid for all the work done so far, and the contractors tell him it’s a bad idea to do what he’s doing because building the house’s roof to protect it from the hail is more important, but Mr. Community thinks he needs to do this because, to him, it’s more important that his shed gets built so he can protect his motorbike than it is that the roof gets put on his house. It’s also the case that by doing this, it won’t get Mr. Community’s shed built any faster, because he’s just making electricians and plumbers sit on the sidelines while everyone waits for the shed-builders to get their work done.

Should Mr. Community be prevented from being able to make that decision? In my opinion, each contractor has the right to respond however they wish to the notice that funds are being withheld, they aren’t being forcibly controlled (but their time is being wasted, and they may exit), but Mr. Community should not be denied the right to take that action, as long as he has paid everything he currently owes to the contractors and has satisfied all of his contractual obligations.

But one other potential crux of this issue is that in the above thought experiment, I’m equating “ZIP being rejected” with Mr. Community not being able to take that option, which I think is how a lot of people have interpreted the ZIP being rejected. However, @nuttycom wrote the following, which suggests the opposite:

If polling found sufficient support for the rejected ZIP, then that could be sufficient cause to reopen the ZIP (though with my ZIP Editor hat on, it would still require modifications.)

So there are two cruxes as far as I can see (and please feel free to disagree, especially by pointing out ways my thought experiment doesn’t map on to this discussion!), which are (a) ZIP editors erroneously think that the proposal is unduly affecting the behavior of independent people within the Zcash community (rather than creating an incentive structure by withholding funding until a goal is met, even though that might be a bad incentive), and (b) others are erroneously thinking that the ZIP editors’ decision to reject the ZIP means that the community cannot elect to have the will conveyed by the ZIP (that it cannot be included in polling, etc.).

The best solution, in my opinion, is that even though it doesn’t meet the requirements to be accepted as a ZIP—and I defer to the ZIP editors’ interpretation of what that means—it can still be included as an option in community polling and coinholder voting (along with any necessary modifications to ZIP 0 or other ZIPs that would make it eligible for being a valid ZIP).

1 Like

I think the poll that will go out strikes a balance. There will be two questions.

Q1: Which of the following funding proposals do you support? You can select more than one proposal.

  • Community and Coinholder Funding Model (C&C)
  • Community-Governed Funding Model
  • Pure Coinholder Funding Model
  • Pure ZCAP Funding Model
  • Zcash Governance Bloc (zBloc)
  • The Dev Fund should end and 100% of the block reward should go to miners.

Q2: Do you support prioritizing the extension of the Dev Fund and the implementation of a new funding model, even if it requires postponing NU7?

  • Yes
  • No
  • Abstain

The second question provides the community the ability to signal its desire for or against what I believe was the intention behind the ZIP in question, and since asked independently, gives it more weight than it would have received as one of a number of options, while providing more clarity.

3 Likes

Let me get this straight we spent the better part of 2024 voting to get rid of the dev fund all together as it no longer served the purpose of the project.

A few months pass and we are saying oops we didnt plan right and have no funding so lets go back to the thing we all hated and voted against just a few months ago.

Genius. Just Genius.

2 Likes

@commonsense: if that’s your belief, make sure to vote against the dev fund as well please.

The result of the previous voting wasn’t to “get rid of the dev fund” but to create the lockbox and basically postpone the decision on how to handle it. Which is what is happening now.

1 Like

Correct. Quoting from ZIP 1015:

For these reasons, the Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development funds.

It’s fine to be opposed to the existence of the dev fund, and to have voted against it in the past. But ZIP 1015 was explicitly voted for, both by the community in Helios polls and by the vast majority of coins exercised in the corresponding coinholder vote.

1 Like