Community Sentiment Polling Results (NU4) and draft ZIP 1014

It is cumbersome. but how else do you hold the major grants slice accountable? If there is no cap for the ECC too, they now get free reign over the dev fund. This is not a level playing field for the companies that will be taking zcash to the future. They do not get the same benefit of no caps.

This seems disproportional in incentive alignment for the future of zcash against getting new players into the mix. like @mlphresearch, @mhluongo and other teams. which this process is trying to accomplish.

Is it worth losing the ECC? like @zooko has said, this will set a precedent for future projects and development funding. it is a lot more honest and sustainable than ICO’s - it is actually a pretty good model. I really can see this being the new mechanism for funding legit tech projects.

So should this be " og developers get the keys to the funding kingdom but new blood doesn’t?" (this is very uncharitable to the ECC and I am not saying that is what their position is, I am talking about the precedent.)

Setting history is kind of being overshadowed by losing the ECC. no one wants to lose the ECC and I feel that will be the biggest influence on the voting decision. it is real possibility that everything stalls if we get caps.

@joshs the ecc has talked about how you are working on developing stuff to help integrate new teams to the tech and space - realistically zcash and zec will be in bad shape if you don’t take the dev funding slice and this doesn’t happen. is it even feasible before nu4?

3 Likes

Thank you Josh, I think that coincides with how I stated how I originally felt that the accountability measures are better overall for the project and I want them but I also want the best development team but I can’t have both and it’s frustrating (please forgive any hysteria)

3 Likes

Hi Steve.

Yes, we are working on a number of community programs. You may have seen the genesis of a few of them. For tech specific communities, we are actively engaged and contribute in various communities focused on zero knowledge cryptography. I think this has gone a long way in the proliferation of current interest and research. More formally, we are working on a program but I’m not ready to share that information publicly. I’m hoping to get it announced in Q1 but it has a number of external dependencies that could push it to Q2. That program is independent from upcoming monthly developer calls.

I’m curious about this comment:

ECC would be capped on 4 years and a % of ZEC allocation, just not USD caps that would artificially constrain our work. This would also remove the USD-denominated cap for the Zcash Foundation and all grant recipients. Because it removes the cap for the grants pool, it actually invites more, instead of artificially restricting more participation by third parties! I think it’s the cleanest option for all parties, all parties are able to use the upside to benefit Zcash, and all parties would be accountable for their use of funds for the benefit of Zcash.

Thanks Steve - I appreciate your thinking and engagement.

4 Likes

Hi @Autotunafish. Per my note to @mistfpga above, I think that removing the cap does give you both and invites even better things for Zcash. The zip includes accountability requirements and if the community is unhappy with the work of any party, it has the power mandate change.

4 Likes

So… a question… if the poll comes back with ‘the cap stays’ & ECC declines thier slice, what next?

Somehow, I can imagine ECC continuing with funding via Major Grants, mainly as I can’t imagine ECC not working on Zcash… it’d be like Apple deciding not to make phones.

On a different note, remember back when the TM discussions got heated & out of hand? This is 1000 times better.

1 Like

Hi Josh,

I think I have. That is really good news.

From the discussions that have happened before, it was expressed by potential major grants recipients that the speculative nature of crypto pricing was something that held them back from being able to commit teams to the projects. The USD caps for the major grants process act as a buffer for this and as an accountability measure for the community. (admittedly it isn’t the best mechanism for accountability, but it is one.)

The buffer is if the price spikes, you still get to pay your team, and the excess goes into a buffer in case the price dips, this can then be called upon to pay the teams to keep doing the work. It doesn’t make sense to force new players to adopt “double risk” of the work not getting paid for even if it is completed.

This buffer also acts as an accountably measure. This isn’t needed as much for the ECC and I can see why the company isn’t thrilled by it. however major grants really need it.

But you cant cap one and not the other, imho.

2 Likes

Hi @dontbeevil. We try to be as transparent as possible and appropriate. Sometimes it’s best to wait to share because of people impacted, we need to better understand feasibility and implications, it can cause confusion and empower fudders if we don’t communicate well, etc.

2 Likes

Thanks Steve.

I can’t speak for them, but believe the third parties potentially interested in funding (ex. @adityapk00, @mhluongo, maybe others) have been in favor of removing the USD cap. As I understand it, it is a USD cap on the funding pool but not the recipient which would mean that the grants committee could only allocate funds up to the cap, which would unnecessarily cap third party participation. Tbh, I’m not entirely clear how this would actually work in practice - it seems complicated, risky and unnecessary.

8 Likes

Hi Josh,

No problem. Just trying to work out the implications. (are you or the ECC going to be in the call on Tuesday?)

Speaking from my own experience it is a very hard sell to get anyone involved in this project that isn’t already part of the opensource community. This was one of our/my problems with the grants process before. (I am referencing the zfnd grant process here, not the major grants. We wouldn’t be applying for one of those, but I don’t see why it wouldn’t be similar.)

I am pretty sure that it is designed so that mg recipients cant burn all the funds in times of price spikes. It just looks strange now because we are at a low zec price.

If Company A prices and does their work and gets zec for six months over a price rise period they will do very well. Company B however who was awarded the MG and starts work 6 months after Company A will lose out. (this happens if the price doesn’t keep increasing) Not only on getting fair compensation for their work but also on all the ramp up time to get going on the needed project that has now been canned.

This only happens without caps. This is a non trival risk to most companies. (not the ECC tho, but that goes without saying, but the MG process is not primarily about the ECC.)

Maybe I have it wrong. Whilst it is a cap on the amount you (the ECC) can make of the appreciation of the value of zec it completely eliminates the risk for MG recipients in favour of fiat denominated stability.

It does cap the allocation pool for anyone period but for the sake of long term stability. - isn’t this essentially what the zfnd grants process now is, but on a bigger scale. @tromer am I being thick? I don’t think mine and Josh’s interpretations are mutually exclusive but now im starting to doubt myself.

What’s with company C and D during phases of success and high zec price? They won’t be there - because they were killed by the cap. Now you can start to rethink your cap and maybe rise it a bit such that there is space for company C and D. But what’s with company E and F during phases of success? They won’t be there and can’t contribute because of the cap. Now what’s with company A that was doing a great job - it wont able to enlarge it’s engagement because of the cap. Now what’s with a motivated company G that’s exploring opportunities in the blockchain space - will the cap attract company G? Now what’s with an serious investor who is comparing Zcash’s capped investment into it’s future with the competition - will the capped investement into the future attract him more?

We should really try as good as we can to achieve accountability - however an USD based cap is the wrong instrument for this, moreover it’s absolutely devastating for the future of Zcash.

4 Likes

Perhaps Major Grants needs to be split, half with a cap/reserve for fiat based funding, the remainder in ZEC for the devout. Applicant decides.

If we were to run A/B experiment on having a USD cap and none, experiment arm with no cap will see more developer activity resulting in increase in Zcash adoption. Imagine if you are trying to start new ride hailing company like Uber, how would you attract drivers? without enough drivers, you won’t be able to serve your users (if you have!) better (that’s the problem Lyft is facing right now). You would give a chunk of your company’s equity to drivers as a reward for the risk they are taking on your company, suddenly you see a growth in drivers joining, resulting in more users. Then every new driver that joins your company will get less equity relatively but it will be growing. You can always get rid of that driver if you want!

You can easily see same analogy here. USD cap demotivates or creates minimal incentive to contribute to Zcash.

Cryptocurrency works because there is a financial incentive for miners to mine user transactions, not because of other reasons (now imagine a USD cap - forget about implementation details, just imagine!). Replace “miners” with developers and “mine” with development of cryptocurrency

1 Like

Hmm…maybe…I see what you’re getting at and agree with some of it, but would say ‘it depends on the developer’.

Some are firmly rooted in the fiat world for projects and freaked out by ZEC volatility, there were comments on that from a ZF Grant applicant. Others want ZEC.

Think ECC is a special case, certainly ‘devout’ as everything they do is in ZEC. Thats fine, and pretty much explains why a fiat cap wont work for them - but wouldnt work for all.

My 2 zats, having ECC is far better than a fiat funding cap.

5 Likes

(Speaking for myself, not for ECC or as ZIP editor.)

I will concentrate on reasons that haven’t already been stated in ECC’s blog post or expanded on in @zooko and @joshs’ previous comments on this thread.

The funding cap is attempting to “solve” a problem that does not in my opinion exist. The ECC and ZF each have the option to voluntarily impose a similar discipline on spending as that imposed by the cap. The only plausible motivation for a mandatory cap is if the community does not trust ECC and/or ZF to have the financial discipline needed to manage price volatility.

However, ECC and ZF have both been successfully managing price volatility of ZEC for as long as they have existed. In particular, the staff of ECC are highly incentivised to make sure that funds are not mismanaged. We have the information needed to do so: in addition to the quarterly public transparency reports, there are internal “all-hands” meetings every two weeks in which the current ZEC and fiat positions and the estimated runway are communicated.

For policy reasons ECC staff do not normally talk about the ZEC/fiat price, however, I do need to talk about that a little to make my position clear. If the ECC slice is 35% (of 20% of issuance), then between the first and second halvings that corresponds to 7560 ZEC per 30-day month. So a 700,000 USD/month cap would come into effect when the ZEC price exceeds USD 92.59. That’s not a particularly high price, historically speaking; the all-time high (ignoring the initial few days of price discovery after launch) was around USD 750 at the start of 2018, and the price was over USD 160 for roughly 14 months between ~May 2017 and ~August 2018. Without attempting to make any price prediction, I think it’s easy to see that, if it were to turn out that ZEC had been substantially undervalued relative to its price over the next 4-5 years, then a fixed USD funding cap could start to look like a serious mistake. (Of course, price history is not a guide to future price, and nothing in this comment should be construed as financial or investment advice.)

@acityinohio has implied that it would be straightforward to raise the cap. But ECC cannot rely on that, and it would not be able to do any long-term financial planning under the assumption that the cap will be raised. The need to go back to the Community Panel and ZF to argue for a funding cap increase would itself cause substantial market uncertainty (as this dev fund process has done, unavoidably).

ECC management’s position has been clearly stated in their blog post:

The proposal from the Zcash Foundation includes a US dollar-denominated cap on funds that would be available to the Electric Coin Company. We are grateful for the Zcash community’s desire to continue to fund our work. However, the Electric Coin Company currently does not see a path to succeed at recruiting and retaining a world-class team, and aligning them around the Zcash mission long-term, if we are constrained by a fiat-denominated funding cap. Unless the Electric Coin Company could find a solution to that issue, we would not accept the funds.

I have every reason to believe this is a firm and considered position that ECC management will stick to. Therefore, a vote for a funding cap is essentially a vote for ECC not to continue developing Zcash. Personally I think that would be a tragedy; I don’t believe there is any viable replacement for ECC in the Zcash ecosystem. This is because there’s a highly nonlinear relation between the number of people working together in structured teams, and the amount of development that is achievable.

You cannot just do the things more slowly with fewer people. In my opinion ECC currently doesn’t have enough engineers, but in any case, to make a success of cryptocurrency development, engineers are not enough. You need, for example, people dedicated to improving continuous integration. You need people handling infrastructure failures and attacks. You need researchers. You need people working on encouraging favourable regulation, and mitigating or attempting to reverse regulatory setbacks. This all costs money; a lot of money.

If we are spread too thinly, the things that we don’t have enough people for will get dropped. And if Zcash is to become successful, that can’t be allowed to happen. Yes the development of Zcash needs to become more decentralized, but it is very difficult to imagine the necessary critical mass of talent being assembled without ECC.

15 Likes

Thanks Daira!!

Agreed.

3 Likes

How does the ZFND assess the consequences for the whole Zcash project in the case if the ECC stops developing Zcash?

Why is there no variation in the ZF slide?
Why did the ZFND exclude this possibility from the poll?
Why is this particular point not under debate?

1 Like

ECC has clearly stated that they will decline and not accept funding IF the community decides there should be a cap. You can re-read it somewhere even in this topics.

1.) Because the ZF has allready the smallest slice
2.) Because nobody asked in the discussion for a change of the ZF slice.

This might be true as you may have all the information, but the community has not. As an example, for me personally it’s still a miracle how the community is giving funding to the ECC without even knowing who the shareholders and owners of that for-profit company are. But that’s just me of course.

Did the ECC company make profit in the past years? Paid out dividends/bonuses/whatever to the owners/shareholders? You may know these details but we, the community, do not.

The voting results do not inform us why the community endorsed a cap although I doubt it was voted for solely due to price volatility. I can only speculate but I believe it is more focused on encouraging accountability and sustainability. I am certain that the CFO of the ECC is doing their best to manage currency risk as it arises.

In regards to handling volatility, fair point.

Indeed. A similar argument can be made in the opposite direction if I fully supported the cap. Several metrics indicate Zcash is fully valued without considering future inflation, market reflexivity, broader marketing, or any marked increase in adoption. This is speculation however so feel free to disregard it.

It is disappointing to see that the ECC is absolutely unable to operate under a different regime for any period of time. Frankly though, how do you quantify market uncertainty? Volatility, price decreases relative to the broader market, or some other metric?


I assume that the ZF would fill the gap that the ECC leaves behind if it came to that. The current employees seem to enjoy working on Zcash so the best course of action for the community and these individuals would be to transition them over. The structure of how the work gets accomplished would definitely change but I don’t see how this would irreparably harm all parties (excluding specific owners of the ECC).

Edit: Apologies for being so terse in my initial response @daira. I appreciate your comments very much.

3 Likes

As far as I can see we have have currently no evidence for ZFND’s efficiency to carry out the tasks entrusted to it. However there is some evidence for it’s inefficiency.

One of ZFND’s first larger technical projects is Zebra, an important project for many reasons - however it’s a relatively simple task in comparison to the tasks that the ECC is carrying out today.

The following question was posted by rex4539 after the ZFND presented its Engineering Roadmap for 2020 and remained unanswered.

Perhaps I’m alone here but I have to admit that I was kind of disappointed after reading it.

Parity-Zcash client is already syncing the Zcash blockchain and while I do hear the reason to (kind of) start from scratch, I can’t help to think that the Parity client was built for (sort of) nothing. All these months of development and money spent to finally decide it’s not good enough because it carries the Bitcoin baggage?

Based on the fact that the ZFND is aiming to play a major role in future Zcash development and by applying Josh Cincinnati’s personal standards:

I’m asking the ZFND to comment on this.

1 Like