Emergency extention to a select part to NU4 inclusions RE dev fund


@moderators, @zooko, @nathan-at-least

Please may we have an extension on what gets included into NU4 regarding the development fund.

It is clear that across the community there is broad consensus that zcash will need continual funding. How and where this funding comes from and where it goes to is still a talking point.

When Shawn first raised this thread (about 7 months ago) Zooko stated that he felt it a conflict of interest for the ECC to get involved with the discussion of continual funding. I a fair and balanced sentiment.

Looking back over the thread though it seems it end up with the community discussing it themselves for several months - with the foundation making a clear stance and suggesting ideas. But ultimately the thread was about principles and high level ideas.

I believe that due to the good intention of zooko (and for the safety from legal ramifications), it made the ECC representatives reticent to get involved with the topic at all except to dispel misinformation. Which exacerbated the above issue.

We have seen considerable uptake in community engagement over the past week on this topic in no small part to Nathan coming forward and really getting involved with helping the community try to organise themselves in a manner the ECC can do something with. This was an amazing step forward in finding a solution to this problem.

We will hear from zooko very soon, and I feel the community has solidified their opinions and basic ideas enough that Zooko cannot be seen to have a conflict of interest anymore, nor more importantly legal liability. (I am not a lawyer though). The community has also worked out how to get information from the development team that enables them to get their voice heard without compromising the integrity of the position of the ECC.

We (the community) are at a stage where we can put /something/ forward, however I think an extra 4 - 6 weeks maximum extension would really help us understand the ramifications of what we are suggesting.

All of the feedback I have got so far has made me think of new issues with my ideas, helped me solidify my ideas, allow me to accept new ideas and new routes. This all takes time to sink in.

This has happened in every thread in the proposals section.

I understand what we are talking about is non trivial and will require non trivial work to implement - but now there is community engagement and it is very productive engagement at that. (I was completely wrong on what I thought would happen - due to me misinterpreting Shawn and the very strong clear response from the moderation team plus the very helpful engagement of the development team)

I don’t think anyone is at fault in this issue and had we had discussions like this back in Jan/Feb/March this would all be solidified by now. (but I can see how it would be a very fine line for a ECC employee to get involved at that time)

I know you have development cycles you follow, I know you do agile, so this will be a pain for you. I think the benefit to the zcash ecosystem as a whole would outweigh those issues. I do not have the full information on this though.

To be clear I am not saying do not announce/lock anything on the 31st, just make a special case in this one instance. We are after all trying to make a special case for funding. A lot of the people posting here and have proposals also have full time jobs. The forum is just a very small subset of the zcash community so I feel that it is out duty to make sure we get these fuding propsals right.

Sorry for the wall of text. Please add your thoughts. Is this a possibiity?

I would see the timeline something like this -

  • Rough Drafts by the 31st (not a hard deadline though, but it might not get accepted after)
  • Two weeks for the company to review them and put a basic timeline and implementation impact (cant remember the exact bit it is called in the ZIP but its the technical bit we cant do) And assess overall impact of compatibility between ZIPS
  • Feedback to the community who have two weeks to consider and consolidated their ZIP’s based off ECC technical feedback aspects
  • Possible second round of vetting and checking of last minute ZIPs or Final drafts to be submitted.

4 - 6 week extension.


Nathan, the CTO of Electric Coin Company, has set the timing for the NU schedule so any changes would be up to him.

This is exactly why I started the other thread back in January, to try and get these kinds of conversations going. It’s unfortunate that many have only recently seen the big deal that this really is and began to think about it.

Don’t expect much feedback before next week or so from ECC or the Foundation. Zcon1 starts tomorrow and many are in planes or just arriving in Croatia.


It is, but that is where we are now.

I wouldn’t mind clarification on, and is part of the reason I am asking for more time - We could end up with 50 very similar yet slightly different zips. Is this the right way ? what do you think about it? I guess more is better, but then that leads to needing more time.

I don’t really want to start @ a load more people so I hope they read this thread. I am just about to update the OP with a suggested timeline.


Hi mistfpga, thanks for the thoughtful post! Like Shawn says, Nathan is responsible for the ECC Network Upgrade Pipeline. Here’s the current version of it:

The next deadline is Draft ZIPs Due at the end of August and then Feature Selection (choosing ZIPs) at the end of October.

As far as I currently understand, the current options for the Zcash community are:

  1. “Standard ZIP Process” — specify candidate decisions before the end of August, make a collective decision before the end of October, and then ask ECC to implement that in NU4.

  2. “Compressed ZIP Process” — start later but finish at the same time, meaning we have less time for some of the steps.

  3. “Delayed NU4” — start later and use the normal length of time, meaning that NU4 activates later.

  4. “Temp Funding” — implement a ZIP in NU4 which has some effect but only for six months (until NU5 kicks in). That ZIP could be no-Dev-Fund ZIP like Dev Fund Proposal: No dev dund, let FR expire, market decides - #2 by nathan-at-least, in which this would be a six-month gap in funding, or it could be a Dev-Fund ZIP like [ZIP 1003] Dev Fund Proposal: 20% split between the ECC and the Foundation but limited to six months, in which case this would be a six-month temporary funding measure.

  5. “Switchable” — implement a ZIP in NU4 that has some parameters you can plug into it—like amount of funding and duration and recipients—and then delay plugging in those parameters until later in the process.

These are all the options I can think of. I don’t want to put forward my own opinions too much about which of these options to choose, but I’ll just point out that the impact on the core devs (at Electric Coin Co and Zcash Foundation) is only one of the impacts. The timing and contents of this decision also impacts third party devs (e.g. the Trezor devs, exchange devs, wallet devs, etc. etc.) as well as miners and coin-holders.


Thank you for this well thought out reply.

the roadmap is really helpful

After your talk at zcon1 I read your posts differently. I have been thinking about this in the back of my mind. The down stream stuff is potentially so non trivial I am not sure the best way to proceed. I will keep thinking about this though.

financial tangent - zooko plz read

Could you have the thickness of the coloured lines represent the rough % of technical resources allocated to that task? this would be high level enough for me to try to help minimise disruption and try to find more time.

From a finance point of view could you get that roadmap to indicate % of financial resources that go into each stage (again via thickness)

This info would be ideal for me, and would significantly add to transparency. when combine with the transparency report. I could add this to that thread. I guess I should. but I am leaving it here anyway.

What I am going to do to try to help a bit is get my ZIP’s in for July 31st so hopefully the ECC and foundation can set aside some time to discuss them and their potential impact with other ZIP’s before August 31st.

Hopefully having my ZIP’s posted early they will serve as a good template to enable other people to submit theirs sooner than august 31st and the teams will have a good idea of what the implications are when new zips arrive.

This is the best I can suggest at the moment.

I really think though there does need to be a second round of community feedback once all the zips are in.

Hey zooko,

Sorry to bump this thread, but is this being talked about internally? Can we please get a brief response from @nathan-at-least It feels like this is getting ignored.

I understand if the answer is “no, we cant do It” or if it is “Maybe, we are still assessing the downstream impact”

It would just help me prioritise my work. I really do want to try help on this, but I am giving quite a bit more of my free time to this than I originally anticipated - so I would like to try to get the work I get paid to do done also.

Sorry for being a pest. I will drop this subject now, probably wont post in this thread again unless specifically asked a question.

I will just try and get it done as best I can.

1 Like

This sounds like the best approach - it separates the recipients (could be nobody) & amounts (could be zero) from the delivery mechanism (edit: which needs to be defined)


I apologize for not seeing this thread earlier!

Let me see if I can clarify the normal timeline and requirements for ZIPs in NU4, then let me describe how Dev Fund proposals are different.

First the table of dates on this page might be easier to follow than the infographic for the timeline: zips.z.cash. The first two deadlines there are:

Deliverable Date
ZIP draft submission deadline Aug 31, 2019
Feature selection done October 31, 2019

What’s probably less clear is what is expected for the August 31st deadline, versus what happens by October 31. For “typical” ZIPs (not Dev Fund stuff), the August deliverable is a ZIP draft. A draft is an unfinished version that has enough information for the zcashd and zebra developers to have a fairly clear picture of what’s involved.

In order for “Feature Selection” to accept a ZIP by the October 31st deadline, a “typical” technical ZIP needs to be well specified enough that engineers, security auditors, product development people, etc… has a clear and specific understanding of what’s involved.

So for a typical technical ZIP, September and the beginning of October are intended to give the developers, the ZIP editors, and the ZIP authors time to refine, clarify, and improve proposals.

Now let’s talk about what this might look like for Dev Fund ZIPs: I expect some amount of refinement of a proposal between the ZIP Draft deadline and the “final proposal” for NU4. Probably during September we’ll need several iterations where proposals are refined or tweaked, then community members discuss the changes as well as ECC and Zfnd.

Later in this phase in October, it would be ideal in my opinion for all substantial changes to be complete because we need time for various kinds of community sentiment to be gathered.

Please also see the Foundation’s plans in the “How the Foundation will select a particular proposal” section of the “Zcash Foundation Guidance on Dev Fund Proposals” post.

Now in addition to that process, ECC separately will publish assessments on proposals before the draft deadline. See my post here about that.

Does this clarification help you understand the timeline and the fact that there is some time built-in for assessments, discussion, and refinement?



Thank you. It very much does. I really appreciate the detailed response, and the ECC being proactive and flexible. - I would have been a little calmer if you had seen this sooner :slight_smile: - The lack of clarity on this was what a lot of my “we only have 2 weeks, etc” and other complaints were about. I didn’t realise you missed the thread.

So the 31st is flexible for funding a bit like I outlined, but try to get as much nailed down asap in case it needs non trivial code changes (unlikely given the current proposals) and don’t panic.

Thanks again.


I am ruefully realizing that I was definitely not clear enough about this.

1 Like