Updated 1/aug/19: ZIP proposal Keep the block distribution as initaly defined. 90% to miners

01/Aug/19 Total rework of format and ZIP to incorporate feedback.

New feedback required please.
@nathan-at-least - this is my proposal I would like your comments on.

ZIP proposal Keep the block distribution as initaly defined. 90% to miners

czip v zip click to expand

This is a community ZIP (CZIP) and not a ZIP ZIP. hopefully I can make this into a ZIP from feedback. Please reread this proposal and make any suggestions below. I am open to changing quite a lot of it and welcome discussion on any part or aspect of it.

I may have made mistakes in typing this up, so all comments are welcome.

If this proves useful I will publish my guide on how to write and fill out these sections. Also I can do a lot of the heavy lifting in terms of formatting, etc. I do need some basic information from you though.

If this current proposal is okay and signed off by the foundation/ecc as a decent example. I will pass my guidelines for how to fill all this stuff out (80% of it can be done by someone else, you just need to engage in questions) I dont want to publish guidelines for them to be wrong and people to have to redo work.

I have created a pull request for the foundation to include the guidelines (as requested by @sonya). the request can be found here

The formal ZIP process parts are taken from this guide by the ECC

1 - Header

ZIP: unassigned.
Title: ZIP proposal Keep the block distribution as initaly defined. 90% to miners
Adviocte: mistfpga (zcash forums)
ZIP Status: Draft
Community Status: Request for comments @ Updated 1/aug/19: ZIP proposal Keep the block distribution as initaly defined. 90% to miners
Category: Process
Created: 2019-08-01
License: CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0) [1]

Additional Community Status header information - click to expand
  • Community Status, what part of the process is this zip at.

    • Request for comments (from anyone)
    • Request for proposal (formal request to help make into a proposal)
    • Request for technical review (requesting technical feedback from the ECC)
    • Final (this zip is finished and ready for submission)
  • It should contain the URL of where the discussion is taking place. forum/github

Note: at any point in this process, even if it is labelled final people can still comment. If the status is Request for comments, the ECC can still give technical feedback.

Should these additions get accepted I will add a guide on how to use them.

2 - Terminology

To understand this ZIP it is critical that people understand the right terminology so their requirements can be quickly checked.


Have special meaning and people should familiarise themselves with it. - https://tools.ietf.org/html/rfc2119

For clarity in this zip I define these terms:

  • Mining software in the context of this zip refers to pool software, local mining software, or staking software.
  • Mining is defined as the action of processing transactions, so this include proof of stake, if zcash would switch to that.
  • Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).
  • T1 fee is the standard transaction fee that a sender puts on a transaction to get it included into a block and processed.
  • Block distribution is defined as the block reward - mining fees [T1 fees].
  • Spirit is defined as what is the intended outcome of the zip.[2]

3 - Out of Scope for this proposal:

  • Governance on how decisions are made, this ZIP is not meant to be used as a form of governance.
  • Future funding
  • It does not cover other donations or revenue streams but it does cover how the current FR funds should be used at a very top level.

4 - Abstract/Spirit

The main spirit is not to stop potential future funding, it is to ensure that the FR ends.

It is a simplistic short zip to honour the inital contract of 90% of block distribution by giving miners 100% of block distribution goes to miners after the first halving.
The mining community has already raised enough funds for the ECC to work until NU5, they should be spent on zcash.

Hopefully it will be compatible with a number of other zips and can be worked into them.

5 - Motivation and Rationale

  • To ensure the initial contract is honoured.
  • To build trust within the long term holders and non active participants that the rules that they initially agreed to will be honoured.
  • Breaking this trust and enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the FR
  • The ECC should use the funding as they have stated they would in the initial contract.
  • The community has managed to raise an extra years worth of development funds via the FR, this should be used for development of the zcash protocol for as long as those funds last.
  • The ECC’s sole source of income is the FR[3]
  • The ECC has enough funding until NU5[4]

6 - Requirements

  • The ECC MUST use the FR funding to fund zcash development and adoption until it runs out.
  • This zip SHOULD NOT preclude the ECC from sourcing funding elsewhere, or from donations.

7 - Specification

  • The existing Founders’ Reward consensus rules [6],[7] MUST be preserved.
    Specifically, FoundersReward(height) MUST equal 0 if Halving(height) >= 1
    (For clarity once the halving happens the FR stops. as per the rules outlined in [6],[7])

Issues & Further Discussion

This section contains a variety of information, questions and concerns. There is no real structure to answering or questioning this section.

Raised objections and issues so far:

  • Nathan and Zooko said at Zcon1 that ECC had roughly 24 months of runway, and that if it went below 12 months, ECC would have to reconsider its All-In-On-ZEC strategy.[5]

Implications to other users.

  • Will FR addresses will need to be removed from the codebase.
  • Pools and other software may need to make adjustments for this.

Further discussion needed on:

  • How to make this zip more compatible with other zips. I don’t want the ECC to go out of business I just want the initial promise kept to.
  • Please consider what I can change about this or what you want to change about it and add it to your czip.
  • If a governance mechanism is decided for and implemented in NU5 the effect for the ECC should be relatively seamless.
  • This gives almost 2 years to think about and switch to a new governance system, using already credited funding.
  • Is there enough information for governance people and other prospers to work this into their proposals?

Technical implementation.

Associated zips

zips that interact with this zip should be listed here if possible


[1] - https://creativecommons.org/licenses/by-sa/4.0/ <-I like this one best, dont know which the ECC prefers.
[2] - If there is contradiction between Spirit and any other part of the proposal that needs to be addressed. in the even it is not addressed Spirit is assumed to overrule all.
[3] - Need to find the quote from zooko.
[4] - Need to find the quote from nathan.
[5] - Need to all link to stream timecode.
[6] Section 7.7: Calculation of Block Subsidy and Founders Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]
[7] Section 7.8: Payment of Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]

Thats it. It will still need updating but hopefully this helps.

Should I now @ a bunch of people asking for their specific input on particular parts?



Thanks for starting this proposal here!

Yeah, the whole community can help flesh it out. The goal, IMO, is to make each proposal as clear and specific as possible so that the community can be clear about which decision they’re making.

This sounds more like a “community resolution” rather than a protocol change. Resolutions are definitely improvements for Zcash even though they aren’t literal changes to the protocol, because they help everyone know what the community intends for the future of Zcash.

I would argue that the ZIP process already has a space for resolutions like this, but if it doesn’t, I advocate extending the ZIP process to include them.

No need to apologize! This is exactly the kind of contribution I was requesting in my Dev fund proposals & sentiments post.

I have some clarifying questions:

  • Would this preclude any introduction of proof-of-stake, including hybrid PoW-PoS?

    Those kinds of changes alter block rewards such that some go to stakers instead of miners, and I’ve seen different people interpreting that differently.

  • Does this include transaction fees?

    Would this resolution prohibit introducing consensus rules that redirect some or all of transaction fees to anyone other than miners?

    Example rule: half of transaction fees go to the block miner and half go to a development fund.

  • What does “explicit user consent” mean?

    Does that mean users can introduce a rule to redistribute mining rewards or fees, as long as they consent? Maybe an example of how “consent” is measured is stake-based voting, where if 60% of all ZEC votes for a change to a mining reward redistribution, then that’s acceptable.

    Or does it mean that rules that let users redirect funds “dynamically” are acceptable? For example: users can vote either for or against allocating issued tokens to a dev organization in each block?

  • Does the “current status quo” of block rewards include only the amounts of block rewards, or does it also include transaction details such as the ability to use t-addresses? For example, would the resolution prohibit disabling t-addresses for mining rewards in the future?


Cool. Thank you for the speedy response, there is little time. I will try to champion some other zips too. Can I please use RFC language? I think it will be easier most people are familiar with those.

No, mining is the processing of transactions. Stakers are miners too. They should get block distribution if PoS comes in.

This I don’t know. I cannot find any stance from the ECC in the early docs that state what happens to the transaction fees, only block rewards. I would really appreciate it if you can point me to any more info on this.

but in principle no, it doesn’t. (until I find information to the contrary)

Not in principle. but it is kinda an assumption that they will go there. - but I see this as the potential funding source.

This means that like the current FR rewards are baked into the coinbase, so would the addresses for donations for the foundation.
A user would signal by enabling a switch on their mining software or transaction client that would let them give an additional percentage of either the transaction or block distribution e.g.

  • I sent you 1 zec.
  • I pay 0.001 zec in mining fees that at in this zip go to the miner
  • I opt to pay 0.001zec on top as a donation. (by ticking a box in the software)

In this case the sender sends 1.002 zec. 0.001 goes to the foundation.
The miner if the pool or software he is using donates a percentage of his fee’s say 10% the miner donates 10% of the blocks total fees. I am leaving out block distribution because that will run out. I am open to the idea of putting it into the zip though.

This is unacceptable in this zip under any circumstance except emergency security issues. The block distribution is not up for change from the miners(transaction processors) in this zip. The intent of this zip is to honour the 90% block distribution as set out when we all opted in to zec. No voting. This zip is to stop that exact above scenario.

You could add these opt-in’s to the block distribution but that stops one day. Fees are forever, I am trying to think 60 years time when most of us will be long gone. There will be massive advances in tech over that time which this will have to keep up with.

  • The spirit of the zip is also longevity.
  • Not at all the intent of the zip is to preserve the 90% block distribution. to the miners (transaction processors) not to disrupt the usecases for zcash, especially its most important ones.

This zip kinda needs z only mining addressing to work properly, there might be too many correlation attacks from fees otherwise.

Now on to your next post.


Speaking as a ZIP Editor, @mistfpga’s proposal is entirely in scope for a potential ZIP, under the current process. ZIPs do not have to describe protocol changes (especially in a case like this where they are acting as an alternative to one or more other proposed ZIPs).

Such a ZIP would of course have a very simple Specification section; the meat would be in the Rationale.


Thank you so much for this, it has really helped how I think about this and how I will write it up.

Glad to see you back on the forums.


Hi, thanks for making the effort to follow my requests in Proposal authors, please read: Help making ZIPs . I’ll check back to you in the next week or so to help you with any formatting or editorial needs.


Bump because this is a total rework

  • Simplified to make intent more obvious
  • Removed a lot of stuff in the hope of making it more compatible with other zips.
  • Would really like feedback from the community on this.

@daira do you feel I have met the Rationale requirements, or maybe more correctly are they useful? I have tried to use concise statements to make machine translation easier, and also hopefully easier for non native English speakers to read.

@sonya can you please note in the high signal/low noise thread that my proposals are ready in their draft format for the community to reassess. especially this one. I have tried to make it as compatible with other zips/czips as possible.

This current one - ZIP proposal Keep the block distribution as initaly defined. 90% to miners

And this one. - ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 28/July

1 Like

Together with this proposal, we can consider an additional progressive scale of allocations for the unit.
1 month -1%
2 month -2%
6 month -20%
That is, half the year will have to spend reserves of the past period.

1 Like

Nathan and Zooko said at Zcon1 that ECC had roughly 24 months of runway, and that if it went below 12 months, ECC would have to reconsider its All-In-On-ZEC strategy. Therefore, ECC has enough funding to continue its Zcash operations as-usual until mid-way between NU3 and NU4, as (barring any large price movements) that would be roughly where the 12-month remaining total runway is reached.

This specification as-written modifies the existing FR, which contradicts the proposal’s title and rationale. I think the point of confusion is that NU4 activation is not the same thing as the first block halving. They may end up being at different heights (i.e. NU4 might activate before or after the halving; we won’t know when until mid-next year).

I suggest something along these lines:

The existing Founders’ Reward consensus rules [1, 2] MUST be preserved. Specifically, FoundersReward(height) MUST equal 0 if Halving(height) >= 1.

[1] Section 7.7: Calculation of Block Subsidy and Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]
[2] Section 7.8: Payment of Founders’ Reward. Zcash Protocol Specification, Version 2019.0.0 [Overwinter+Sapling]

This part of the specification is unclear, and possibly redundant:

  • The existing hard-coded FR addresses cannot be removed from the protocol as a whole, because they are part of the historic chain.
  • If you mean “not be part of the consensus rules from NU4 activation”, then this is covered entirely by the first part of the specification.
  • The addresses can eventually be removed from implementations (once there is sufficient distance from the NU that rollbacks can be discounted / prevented with checkpoints, and earlier blocks can be assumed valid), but that is an implementation-specific issue, and not relevant to consensus.
1 Like

Thank you for your feedback, I have directly incorporated it. It makes more sense the way you wrote it.

This point though is one of contention so I raised it as an objection.

There was no mention of a 12 month runway in the initial contract. So does the ECC have the power to change that at will? We certainly don’t have a mechanism for the community to decide, well not by the 31st anyway.

I understand that people need to live, be secure, know they have job safety, etc. However they also need to honour their promises. Had their been mention of this 12 month runway 3 years ago, there probably wouldn’t been a need for this zip.

It is a contentious point and one I am trying to talk about from a non emotional point of view. I understand if this black/white rule idea is offensive to some. There was no room for negotiation when some people decided that taking away the FR was a good idea (last year sometime) I strongly disagreed with that, because it was not upholding the contract. I am coming at this from the same position with this zip.

I really value your input. Thank you.

It feels strange and a bit creepy to me to be talking about what should happen with other peoples money. I don’t really like having these conversations and am continually learning from them. It is not my intent to upset anyone.

That is a really interesting idea. I will think about it and the implications. thanks! :slight_smile:

I think updating in this thread is fine since that bumps and people can click through. I’ll add GitHub links when pull requests are opened in ZIP repo.

1 Like

Watched the live stream.

This is not going to go anywhere. Should I retract it? I don’t want to have to waste my time championing something that is not relevant.

1 Like

Thank you for you comment,

You made me realise something important.

I am representing not just my voice with this zip, but others too.

I will continue to champion it. So even if I am wasting my time I am still doing the right thing for other people.

Thank you again.


I wouldn’t abandon the default setting.

Its what will happen if things remain as they are, that makes it an important baseline which should be explored and considered.


Keep the block distribution as inital defined, that is 90% to minner is not bad. I maybe vote for it.

1 Like