Community Sentiment Polling Results (NU4) and draft ZIP 1014

[edited to add: in response to Community Sentiment Polling Results (NU4) and draft ZIP 1014]

(Hey, friends! Happy Martin Luther King, Jr. day. This is the day that Americans celebrate an American who practiced effective, non-violent, protest and organization. Coincidentally, I’ve been writing a post about permissionless petitioning, and today is the day I finished it and am ready to post it, so I added this note at the top before posting. :-))

I believe that permissionless, unstoppable Coin Holders Petitioning is strategically important for the long-term success of Zcash. I’m gonna briefly lay out my reasons here just so I have something I can link people to if they ask me why I encourage coin holders to do this.

First of all, there are reasons why people shouldn’t. I’m not going to go into all the details here because it would turn this comment into a book chapter. You can read this thread to find lots of discussion about the risks and negatives of Coin Holders Petitions. They are real—I’m not discounting them, but my arguments here are at a different level. I have four arguments. These are from the least important to the most important argument, so if you’re in a hurry skip to Point 4. :laughing:

  1. The risks and tradeoffs are not that bad. Everything in life is risky and comes with tradeoffs. There’s never gonna be a perfect anything, including there’s never gonna be a perfect on-chain voting mechanism. But, what we have in Zcash already works, and it is a beautiful thing. We used it last time around, and it was a success.

  2. The best way to learn and to improve something is to do it over and over. We could spend years debating the risks and designing improvements, but our “Perfectionism and Worry (PAW)” emotions will never be assuaged no matter how much we do that. We learn more in one month of trying something imperfect and risky than we would learn in years of debate and design. We’ve already learned a great deal from the first Coin Holders Petition. And you learn more from doing a thing twice in a row than from doing it once.

  3. It’s permissionless and unstoppable. Using the current Zcash blockchain, Coin Holders can voice their opinions, backed by their ZEC, in an anonymous and unspoofable way. We can’t silence them. We should pay attention to what they are saying.

  4. Coin Holders, large and small, are treasured parts of the Zcash community. They aren’t the be-all and end-all of the community, but neither is anyone else. They are dedicated, valued allies supporting our mission. They’re important for our future. It’s possible that some of them can’t or won’t participate in the other community sentiment gathering methods, such as the Community Governance Panel, for many reasons, perhaps because they didn’t sign up before the cutoff, or because doing so could compromise their privacy. We should encourage Coin Holders of all sizes to know that their voice matters.

Okay, those are my arguments. Reason number 4 is my overriding reason which I think it is an important long-term strategic advantage to Zcash for us to keep pushing it forward.

In a subsequent post I’m going to make a few simple, actionable recommendations.

[Edited to add: instructions for participating]


@zooko, this thread is already overloaded and overlong; can we please conduct the renewed discussion of coin-weighted voted in a separate thread (whether a new one, or continuing one of the dedicated existing ones)?

Also (and pertinently to this thread): we have a tight schedule. The Helios vote will close on Jan 27th 28th, and hopefully things will then move very quickly towards implementation. So a new coin-weighted signal, introduced this late in the game, will either have inadequate time to crystallize, communicate and execute (presumably it would require people to pull funds out of their cold wallets and suchlike), and/or it may delay the overall process.


In my previous comment I told you why I care so much about Coin-Holders Petition that I think we should keep pushing it forward despite the risks.

Here are three simple, actionable, observations:

  1. If you’re considering participating in a Coin Holders Petition, and you’re concerned about the risk of your coins being lost to accident or theft, then just use a fraction (like 1%) of your coins in your petition. That still shows that you exist and raises your voice while leaving the vast majority of your coins as safe as before. Of course, it also means your vote only weighs 1/100 as much as if you voted all your coins. Your call.

  2. If you’re worried about the risk of your privacy being compromised by participating in a Coin Holders petition, I would say this. At the risk of oversimplifying, it’s all about where you store your ZEC long-term. If you’re currently storing your ZEC in a t-address, and you use your ZEC, or part of it, in the petition, then on-chain data will allow blockchain-observers to link your vote to the t-address of your stash. And moving your ZEC through a z-address will not help. You have to store your ZEC in a z-address if you want on-chain privacy. But the good news is that if you’re currently storing your ZEC in a z-address, then you can participate in a coin-holders petition with basically no real loss of on-chain privacy. There are probably valid exceptions or arguments to that, but basically if you store your ZEC in your z-address, then it’s pretty damn private.

  3. See how I said “on-chain” whenever I said “privacy”, in Point 2, above? Point 2 is all about on-chain privacy, but that’s not the only kind of privacy that might matter to you. One particular off-chain data leakage that you should be aware of is the network layer. Even if you’re using z-addresses, someone who is watching the network layer will be able to see the IP address and the timing of when you make transactions. That means that even if you’re using z-addresses, they’ll probably be able to link your vote in the Coin Holders Petition with other transactions you make from the same IP address, including shielded and partially shielded transactions, even if they can’t learn anything about which z-addresses are involved in shielded or partially-shielded transactions. Whether this is a problem for you in practice really depends on your situation. Participating in the Coin Holders Petition probably doesn’t, for most people, make this problem substantially worse than it already is. If you’re a real privacy ninja, you could mitigate this risk by using Tor in a particular way.


  1. Only vote with as many of your coins as you’re willing to risk moving.

  2. If you store your coins long-term in a t-address, then blockchain observers may be able to link your vote with your long-term holdings and your other transactions. Blockchain-only observers won’t be able to do so if you store your coins in a z-address long-term. Moving your coins through a z-address does not change this. What changes this is whether you store your coins in a z-address.

  3. Think about the fact that a network observer can link your IP address with other transactions you make from the same IP address. The consequences of this are confusing to think about, but if you have concerns about your privacy even though you are using a z-address for long-term storage, then you need to think through this network-level privacy leakage.


I can move it to the original topic: Staked Poll on Zcash Dev Fund Debate


(With moderator hat.) A few comments on this topic are fine, IMHO; if it turns into an extended discussion then it should be moved.


Okay, head over to the Stake-Weighted Poll thread for instructions on how to petition using your coins.


The Zfnd blog post says close of polls is January 27, so I put Monday, January 27 in the instructions.

This is a valid concern. This is the sort of reason why I wrote why this is overwhelmingly important to me despite the drawbacks, so that you could know what my reason is (mainly just “Reason 4”), whether or not you agree with it.


Yes, we do. But critically the Foundation is not seeking unilateral power over Zcash. As I wrote in the conclusion to last year’s State of the Foundation:

Looking beyond the Foundation, I think it’s critical to reflect on where power — and expertise — sits in the Zcash ecosystem today. As I’ve said above, the central issue that faces our community today is centralization of power in the Company. But it’s a necessary centralization… for now. The Company employs many of the world’s top experts in zero-knowledge systems, and their contributions are critical to the development of the protocol.

If the Company were to disappear today, that would be a tragedy for the ecosystem. It would set us back by years if not decades. And that’s a fundamental problem for a protocol that’s meant to be robust as currency, that’s meant to protect privacy and adapt to the unforeseen privacy challenges of tomorrow. For the Foundation — and the ecosystem at large — it’s imperative that we encourage Company contributions to Zcash while paradoxically (and amicably) reducing their burden as stewards of the protocol.

Or as I wrote in June in Zcash Governance: A Step Toward Decentralization:

In my report on the Foundation’s 2018 progress and 2019 plans, I explained why and how the Zcash Foundation must counterbalance the Electric Coin Company’s power over the Zcash ecosystem. My concern is not that the Electric Coin Company does subvert Zcash to serve its own interests; my concern is that the ECC would be able to do so.

Unilateral power in either the ZF or the ECC would be a terrible outcome, and I for one think the project would suffer greatly if either group managed to exert undue influence on Zcash in the long term.

[takes Foundation hat off, puts personal Zcash community member hat on]

The ECC has made it clear that they would not accept funding if it included a cap. After a lot of thought and consideration, I’m personally voting against the cap because I very much want them to continue to be involved in this project.

Honestly though, this was a hard decision for me to make; it doesn’t change my opinion that the ECC’s official explanation leaves much to be desired. (the personal, unofficial ones on the other hand — that the ECC prefers having flexibility to spend more than the cap without having to go through a potentially onerous ZF, ECC, CAP process to up their limit — make much more sense to me)

When presented with a choice between Zcash with the ECC’s involvement with or without the ECC…well, I still think it would be a tragedy if the ECC walked away from the project, even if they do so for reasons that are still not rigorously explained officially.

[puts Foundation hat back on]

Regardless of my personal opinion, the Foundation will honor the results from our final Helios poll:


29 posts were merged into an existing topic: Staked Poll on Zcash Dev Fund Debate

Indeed, I was for capping the ECC and leaving the MG slice uncapped, and have since mostly come around to an uncapped ECC slice.

As a potential MG recipient who will ultimately be making a bet on the future of the coin, it better aligns interests and gives me a chance for asymmetric upside. I need that to choose something like Zcash dev as an MG recipient over other ecosystem opportunities.

I mean I’m really interested now! I think making any sort of coin vote mech recognized by the ZF for sentiment collection this time around would be dangerous (for the above reasons)… that said, the last petition not “appearing to matter” is why I didn’t take the time to vote myself.

Anyway, weighing in further in the other thread to not pollute this one too much.


This is the proposal I believe would be most beneficial to the longevity of the project.

ECC 50 /SR 25 /ZF 25 MG would fall under SR.

There are community members who are for the cap. Knowing that funds are being allocated specifically for long term development/adoption etc would help change minds to favor uncapped proposals.The community having a fund slice under their control (at a min 3/4 majority control via voting) would all so help with external optics as this would decentralize control of the project while preparing for the day when(if) ecc/zfd decide to part ways. ECC and ZFD would continue their work so long as the community sees fit. MG slice would fall under Strategic Reserve and should be majority controlled by the community (not any other party ecc or zfd) for the specific purpose of community approved Projects/Major Grants/external marketing etc. No burns coin burn.

Wording plays an important role in external optics. Major Grant in my view should be changed to Strategic Reserve (Major Grants would then fall under SR) and majority control should be the community and custody (only) by the zfd until a better method comes to light. These funds to remain locked and shall only move with community approval.

Clearly i do not have all the answer however these ideas i believe have merit and should be strongly consider by the community. Always open to ideas.

Keep up the good work Daira.

1 Like

At first look a cap seems a responsible thing to have, but it causes other problems. Voted against it.


Excellent choice, how are things shaping up so far. Where is the majority sentiment at this point?

This cant be true.

Given these facts:

Your statement:

Actual Spend vs Budget
 	    Budgeted	    Actual
Total	$2.4mm	        $935k
Zcon0	$357k	        $363k
Grants	$250k	        $139k
Wages	$873k	        $312k
Other	$920k	        $121k

Wages: We really wanted to expand headcount, but hiring in the cryptocurrency industry is hard (particularly for a nonprofit that can’t offer early equity)…

ECC’s official explanation:

The company would not be able to use rights to future monthly Zcash coins as part of a package to attract and retain top talent.

Ironically, the sentence starts with “Honestly”

1 Like

I voted for a hardcap. I would have voted for no cap if the ECC in time would have agreed to fully convert to a non profit organisation.

Main reasons why i voted for a hardcap:

  • ECC’s accountability and transparency so far is no way satisfying and far from detailed.
  • ECC’s owners and shareholders are unknown, i do not want that any money flow is used other than for direct development.
  • I’am a believer that budget restrictions will lead to better and more focused work with limited funds than with unlimited funds as things have to be planned much better and more efficient.
  • ECC did not provide any detailed information/plans for what exactly excessive funds would be used.

As pointed out by @zooko, it is legally impossible for ECC to commit to becoming a non-profit unless and until all the owners approve it:


I’am aware of zooko’s statement, but it’s my reasoning for voting for a cap, even more the community does NOT know who the owners are.
IF the ECC really wanted to go this path there was more than enough time to elaborate this path and communicate with the owners meanwhile in the last months.

I have said and written it many months ago that the best move by the ECC would have been to transform somehow in time to a non profit. I’am still pretty sure that this would have made the community more generous towards the ECC. The ECC might of course still get what they want, but not that easyly and not with such high community support.

However, i just described/argumented why i personally voted for a cap.


I don’t think a cap is a good idea. To put it bluntly, if you want to get very good people to work long term on your project in a start up environment, you need to give them the possibility of very high pay off in the scenario the project does very well. (Sidenote: you could perhaps cap the company’s monthly budget in USD, while allowing employess to get FR-style predefined bonuses/dividends in ZEC, but that might be even more complicated to implement than just a cap).
Ironically, if you cap in USD and don’t allow for the possibility of large pay off in case of success, you might end up needing to pay much more to retain good people.


According to the proposal, the company still has the ability to get 100% of all the coins allocated for them, it’s just not done by default, but by additional request. Therefore, do not confuse the restriction with the limit.
In addition, why are you sure that ECC owners will support the project endlessly, they can also benefit and harm success, just like being 100% for the project. This limitation promotes transparency by default, because transparency reports are made by the company itself, and no one else can verify this (errors and secret games are possible anywhere)

So, forgive me for not knowing the details, but in this proposition, where does the ZEC initially go, and who do you make the request to?