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

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.

5 Likes