Community Sentiment Polling Results (NU4) and draft ZIP 1014

Community Collaborations protocol
185

You can’t force a developer to become a coin holder like any other.

You can just give developers coins outright, in which case they’re free to just sell them right away (which investment theory say they rationally ought to, in order to diversify away from their employment-induced exposure to the cryptocurrencies market).

Or you can give them future rights to coins many months/years ahead, or time-locked equity in a coins fund, or some other mechanism you’d come up with. In which case they can’t sell their coins and thus are not in the same situation as other coin holders and are not perfectly aligned the way you phrase it.

Moreover, you’re completely ignoring the other incentives that ZEC coinholders have: the whilesblower, the dissident, the person of “wrong” religion or “wrong” sexual orientation, trying to protect their financial transactions — are they in it for the “upside” of long-term capital gain?

So you can discuss the virtues of this inevitable misalignment, but calling it simple and perfect is just not true.

In any case, so far you’ve said nothing about the amount of coins needed to “become part of the tribe”. It seems pretty arbitrary to decree that it must be a constant amount of coins per month, and that anything else is a horrible “artificially bind” that “chokes ECC”.

(Not to mention that even constant-coins-per-month is possible, with some planning and within some range of parameters, as @acityinohio pointed out above. I was wrong when I said earlier that it’s impossible.)

3 Likes
186

I don’t understand why it’s desirable for development funding to scale 1:1 with the price of ZEC.

1 Like
187

Under-rated comment!

An arbitrary spending limit is not accountability. The kind of accountability that you actually want from someone who works for you is what they do with the money, and most importantly what results they deliver.

In order to effect that kind of accountability, you need three things: 1. Visibility into what they are doing, 2. The ability to fire them if they fall to live up to your requirements, 3. To communicate to them in advance about what your expectations are.

Mario’s point here is golden and should be central to this discussion: the community has the power to fire the orgs that work for it (ECC, Zfnd, and any new additions that will hopefully come in due to this process).

This is a fundamental fact thanks to the fact that the community controls the consensus rules. Nothing we put into the NU4 ZIPs could change this.

P.S. Re-reading it, Mario’s point was actually more subtle than what I said — it’s the fact that the community can change allocations, and any other dev fund governance rules.

7 Likes
188

I have to say, I agree with @joshs here. It’s not clear to me at all, what problem the cap is solving.

Volatility reserves:
Let’s remember that both the ECC and ZF already have a large incentive to build up reserves to withstand volatility. History has shown us that ZEC price is very volatile, so it makes sense for everyone to build up volatility reserves. Adding additional encumbrances for something that is already incentive aligned seems like complexity we don’t need.

ZEC Price:
I don’t think it makes sense for us, as a community, to worry what will happen if Zcash is too successful/ ZEC price will appreciate too much. This is a problem we very much want to have.
If this comes to pass, we should let ECC / ZF / developers decide how they want to handle it - Whether it be build up ZEC reserves, build a USD volatility reserve or spend more on developers or marketing.

Accountability
We can already fire ECC / ZF / Developer if any of them gets captured / doesn’t deliver results via mechanisms that are well understood - Removing funding, hard forking, or simply exiting Zcash.

Complexity is the enemy of good incentive design. Adding a funding cap creates, in my opinion unnecessary complexity, solving problems that don’t exist.

We very much want the ECC / ZF / developers to be incentive aligned. A cap unnecessarily limits upside.

One last point:
It is very much true that the market for talent is very very competitive. I know of, first hand, people working on FB and Google Ads that are making > $1M a year. The reality is that this is the market we’re competing in.

Good software is hard - and we need to offer large upside to attract developers to Zcash in an incentive-aligned way.

5 Likes
189

It doesn’t have to scale 1:1. But I do think there should be some proportionality in order to create the positive feedback loop. I’ve said that I think some of ‘excess funds’ going into a strategic reserve would also be wise.

As @joshs said above the ECC is competing with other teams that are very very well financed.

4 Likes
190

Add a transparent mechanism for obtaining funds for ECC over 700 thousand per month with rising prices and all that is to be said here? The price will increase 10 times, it will be possible to get 10 times more, and how to do it will be something to think about. Surplus in zec is money for ECC in case of reluctance or inability to use it then to grant. It’s just that ECC wants distribution without conditions, put the percentage out of the block, then give it, and the fund wants to work as employees under the contract (ECC representatives themselves wanted this before, now realizing that the price will rise and they will receive less money, I also said that, they changed their minds - you just have to say directly)
Leave the restriction, but add the conditions for obtaining the balance in zec quarterly or semi-annually (budget savings). Either remove the restrictions altogether as the ECC wants, because it will have to be done anyway, otherwise they won’t work, there is no interim agreement, or whatever they want.

1 Like
191

We seem to be speaking past each other on several points.

No, I don’t want to disconnect developer incentives and user incentives. If we’re still talking about offering upside to ECC employees then I’m all for that, and suggested a solution that allows the ECC to do so even with the presence of a funding cap that had widespread community support.

Yes I am personally indifferent to it, but I understand the rationale behind it. I’m advocating for a funding cap under the belief that it was widely supported by the community given the support behind ZIP 1012, which is why the Foundation only lightly modified it as a proposed ZIP.

Agreed! The community coalesced on a proposal that funds the ECC but has entirely reasonable accountability requirements.

Does this mean you have objections to the cap that are unrelated to employee compensation? Because if so I really feel like you and the ECC should have explicitly said so much earlier in this discussion because it changes the nature of everything being discussed here.

The current cap wouldn’t even start affecting the ECC until ZEC is 3x its current price, which doesn’t strike me as something that’s binding. And it can always be raised by the ECC, ZF, and community approval according to ZIP 1012.

I strongly disagree with this approach. We’ve already spent months debating proposals and ideas, months collecting them and converging on approaches, and ZIP 1012 has broad community support already. Deciding to press pause/reset could cost us months more and for questionable results. Don’t let perfect be the enemy of the good, particularly when I think there’s broad alignment on a proposal with minor tweaks that can be measured with another (final) community poll.

8 Likes
192

The “keep it simple” proposal also had significant support, and it didn’t have a USD funding cap. If a majority of the community thought the cap was so critical, why did a proposal without a cap receive such strong support?

Its seems that the proposal as whole received the strong support, and we can conclude that the cap itself was not considered a critical element by the community.

2 Likes
193

That’s too strong a conclusion too! But the fact that the polling wasn’t by line item is true. I don’t think it should be, but we should be careful to avoid assuming community intent beyond the data.

5 Likes
195

Again I disagree, as the original Foundation modification to ZIP 1012 removed the cap and we received push back from @azrael @tromer and others (which resulted in lighter modifications to ZIP 1012).

But all this discussion points to adding a question that asks whether the cap should be present and if so at what level in our final Foundation poll. I agree with @mhluongo that it shouldn’t be done by line item but at least this question is clearly something worth measuring.

2 Likes
196

Josh already answered this question when you asked it before: Community Sentiment Polling Results (NU4) and draft ZIP 1014 - #36 by acityinohio

We used approval voting. Remember that when it comes to approvals, we are likely seeing all of these scenarios, and we don’t know the distribution:

  • poll respondent approved both A and B
  • poll respondent approved A and abstained from B
  • poll respondent abstained from A and approved B
  • poll respondent approved A and disapproved B
  • poll respondent disapproved A and approved B

That makes interpretation somewhat fuzzy. Maybe someone with more of a math brain than me can figure out constraints on distribution from the results? Idk if that would be worth it.

I like Josh’s suggestion to make it an explicit question for polling:

3 Likes
197

I don’t see the “Keep it simple” proposal as a strong community backed one with just 54% on the Panel.

We can see it reverse as well, that proposal 12 got exactly the majority of votes from the community due this restriction.

I think everything further should be build only on proposal 12 as it simply got the most support. Any changes to proposal 12 should be as close as possible to the initial version.

It doesn’t make sense that the community vote for proposal 12 gets modified more than slightly or it wouldn’t be anymore the proposal 12 the community voted for, i just see it as simple as that.

1 Like
198

It was the second most popular proposal in the forum vote. We can see mathematically that some people supported both proposals, and at least those people must not have viewed the usd cap as critical, at least not so critical that it would prevent them from supporting a proposal without a usd cap.

2 Likes
199

I’am not sure if proposal 10 didn’t get more votes than proposal 13 all together. Doesn’t matter too much either.

There is a winner, it’s proposal 12 and if you remove an essential part of the winners proposal it isn’t just the same proposal, i even don’t understand that there is any place to argue about.

IF the the no cap aspect was that important for the community any proposal without cap should have won, but it didn’t win but just 2nd or 3rd which is (and shouldn’t!) be enough to modify the winning proposal so it fits whomever that isn’t satisfied with the community vote outcome.
IF the cap would be removed than i personally would argue that we did not have any need of voting for proposals after they are later put together to fit one or another entity’s or person’s view.

The community voted for proposal 12, even the (not very good) try to count abstains as supporters for other proposals doesn’t change this fact.

200

I have to agree here, we have spent months considering the proposals and working through community sentiment. Some debates have been put to rest (and should stay there). But we have made progress.

The whole point of this was to set a precedent for long-term decentralized governance, not to fund ECC.

For me, it’s always been about the following:

  1. Make sure ECC has stable funding so that they can continue doing excellent work
  2. Make it easier for new entrants to work on Zcash and gradually fund them more according to success metrics and deliverables
  3. Implement a blended financial system to generate more capital through an investment-type vehicle

I think this proposal captures a lot of that.

I’d like to fund ECC and keep them around, but, I’d also like to see Zcash take a leadership position on governance. Everyone talks the talk about governance, but zebras walk the walk. Cheesy, I know :wink:

Nothing in this precludes ECC from sourcing funding from external sources. (@tromer please correct me if I’m wrong). And ideally, ECC can fund itself solely through the Dev Funding, however, that’s never been a guarantee, nor the sole purpose of this proposal process.

7 Likes
201

I think that would pertain more to the MGR committee / no committee topic (which is just on the backburner I guess for the moment), @mlphresearch how should we properly infer the scenario concerning said committee? Perhaps some sort of hybrid? (Zip already specifies the term length as a year and subject to the same restrictions and requirements of the board members on the zcash foundation so it certainly isn’t guaranteed)
Furthermore I think that also raises the voter accountability discussion from a few weeks back which (besides my Twilight Zone forsaken stakin idea) was basically it this or that way doesn’t work and heres why so what accountability requirements would be imposed?

202

I’d like to say something on my personal role here. People have been writing to me privately, about why don’t I offer ECC this, or how dare I offer ZF that, and suchlike. Sorry, wrong address.

I’m mediating, not negotiating. I’ve been listening to what everyone here has to say, and trying to distill that to a consensus. So I synthesized the ZIP that I thought can garner the most support, and am now trying to figure out what would satisfy newly-raised considerations with minimum disruption.

It’s not up to me to make offers or changes. To the extent that I had to nail down parameters and mechanisms to make my ZIP concrete, they reflected my best read of the community, with a dose of logic and engineering. Now that the framework is out there, it’s up to the community to re-negotiate and solidify these parameters as needed, aided by ZF’s ballot.

When I argue with people in the current discussion, it’s not to promote a position. It’s because I think they’re saying something incorrect that derails the consensus-seeking. I particularly pay attention if people say that “x must be done”, where their rationale is faulty and x contradicts others’ opinions, so this risks a deadlock. But it doesn’t mean that I personally object to x, or could relent and grant x.

So just this once, let me deviate and state my personal opinion: I think we’re in a region of design-space where all the remaining variants on the table are acceptable to me. Yes, I think ECC can survive and thrive with a $700k/month Funding Target for its slice (and more from Major Grants if it wins them), given the simple mechanism for increasing the Funding Target when needed. But I also think it’s OK to increase the Funding Target significantly, because I do trust ECC and ZF to use their potential riches prudently, in the same spirit of the Volatility Reserve, even without a mandate. I’m also fine with exempting some (or all!) coins from the Funding Target, in favor of an immediate uncapped “upside”. And I don’t really care whether the Major Grants committee is independent and binding by mandate, given that ZF does that anyway.

I personally consider all of these variants acceptable and would vote “approve” on any of them. My overriding concern is to achieve community decision rapidly, establish clear legitimacy, know that the future of financial privacy is funded, and get back to BUIDL.

Thanks for your attention. We may now resume our regularly-scheduled arguments.

22 Likes
203

Not to derail the discussion, those employees must senior staff engineers or directors :slight_smile: source: levels.fyi

204

Hey folks, per the Foundation’s earlier plan for this process (Supporting a Path for NU4 - zcash foundation), ECC and Zfnd are going to meet tomorrow to talk about next steps. I’m going to take a break from posting to this thread for now.

9 Likes
205

Going by my proposed alternative to funding caps, perhaps include the following choice:

A. $700k monthly caps as described in the proposal.

B. No monthly caps but allocations and dev fund governance rules can be changed every 12 months based on a community sentiment poll (i.e. same process as now).

C. Neither, but all other accountability requirements of the proposal remain.

On a separate note, @acityinohio, the ZF statement says: “The Community Advisory Panel will continue to be administered by the Zcash Foundation, with an eye toward broadening its reach and enhancing its voting/selection mechanisms.”

Does “broadening its reach” mean increasing the number of its members (based on some reasonable criteria that would open the door to more/new community members)?

2 Likes