ZIP Proposal - A genuine opt-in protocol level, development donation option


Advocate: @mistfpga zcash forums

I am in the process of updating this zip to be in a better format. and to incorporate the comments below. and from other forum members that I solicited via PM. thankyou for your input.

I intend to have this ready asap.

different rules for likes in this section - click to expand.

In my humble opinion liking this post, or any proposal post, is no indication of your support for or against this proposal. It is to encourage the poster to keep working on it, and to show that you have read it and are engaged in that topic at least on a thought level.

This is how I will be using and interpreting likes on a post. (this is not begging for likes, im just saying likes have a different meaning than the standard “I agree”)

@nathan-at-least @Shawn @str4d @acityinohio @sonya @paige @amiller - sorry for @ so many of you, I would like a much feedback on this as possible. You have all been involved in this particular discussion, do you feel this zip meets the standards of a zip (if not what do I need to do to improve) and does it accurately convey the thoughts and objections raised by yourselves.

Thank you for your help and feedback so far.

I hope this is better. Please see this posts edit history for previous versions.

I have tried to address the points raised without quoting the questions, this is for brevity. This zip is a collaborative effort and not just the work of myself. Thank you for all that have helped so far.

If this template is any good please feel free to use it yourself. If the people who will be judging this zip like this format I will be happy to write up example questions that you can ask yourself, so you can fill out the template.

I have probably missed some things, so I will reread over the posts and keep making updates. Please keep adding comments, criticisms and ideas to this thread. All is welcome. All is very appreciated.

If some stuff is out of scope and it should be in scope, ask the question and I will add the answer the OP.

ZIP NaN - A genuine opt-in protocol level development donation option.

Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.

To help ensure ZEC can keep up with these changes, now and in 50 or 500 years time, there needs to be a continual funding for research into new technology.

The only source of indefinite wealth transfer is transaction fees or donations. This zip is specifically about voluntary donations.

The baked opt-in idea is because it incentivises people to donate, because if they stop so will development.

Clarification of 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).
  • Opt-in v opt-out - Opting out is a purely selfish act in the context of this ZIP (there is nothing wrong with being selfish, even though the word has negative connotations). They do not burn the coins therefore giving everyone value. They keep them.

Rational behind proposal:

  • To help continual funding of the Foundation, via an additional opt-in mechanism, baked into the protocol.
  • To give an alterative to redistribution of either, the current, block distribution structure or transaction fee structure.
  • The foundation will use this funding to fund zec development for the lifetime of the ZEC Coin.
  • To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations.

Rational for baking addresses into the coinbase:

  • Baking the addresses into the codebase you do not need the wallet software or pool software to keep track of donation addresses.
  • It prevents wallets sending to old addresses.
  • Should the addresses change, their is no need for wallet maintainer to reissue their software build.
  • It makes it easier for pools to add support and prove that they are actually donating the % they say they are.

Motivation for proposal:

  • To ensure that there is continual and indefinite funding of the Foundation.
  • To give users an opt-in choice via software or service provider.
  • To bake the reward structure into the protocol
  • Longevity of zcash infrastructure and protocol

Out of Scope:

  • Block distribution is not directly covered by this zip. This is because there will be a time when all blocks are distributed, but technology will still advance.
  • Technical adjustments needed to make this happen. I cannot assess this.
  • What the Foundation does with this money.
  • Voting or what political conditions need to be satisfied to implement this zip.


  • Use ability is not impacted
  • security is not lessened
  • this must not contradict the main use cases for zcash.
  • this feature must be opt-in via a user set flag

Further discussion is needed on:

  • Block sizes, this may impact the motivation to increase block sizes should that need arise.
  • Details of technical adjustment.
  • Cost to implement
  • Manhours needed to implement and test
  • Is this a trivial adjustment or not


  • What happens if the Foundation closes down, will the donations:
    • go to into the mining fee
    • get burnt
    • get sent as change to the original sender
  • What if the mining software signals donation/no donation but the pool software is set to the opposite?


  • This adds complexity to the protocol
  • This does not add anything that cannot already be done under the current protocol.

Supporting evidence

  • Other coins have added a similar mechanism and some mining pools do support this feature. (GRIN?)
  • Wallet creators already have a feature similar to this in their software, but at the software level.

Hi, I don’t understand how this is different than voluntary donations as part of existing transactions.

The Foundation could publish a donation address, and then when users create transactions, they can spend some of their funds for their main destination, some for the transaction fee, and some as a donation to the Foundation. This is completely opt-in and works with the existing protocol.

So how is this proposal different?

It makes more sense if the mechanism affects block rewards (i.e. newly issued ZEC coins) rather than only transaction fees. Is that the intent of this proposal?

Here’s a more specific proposal with concrete numbers and details just for clarification (I am not literally proposing this). Let me know if this fits your intent or not with this proposal:

  • Starting with NU4 activation (the block immediately after the Founders’ Reward ends):
  • Each block rewards 5 ZEC to miners and between 0 - 1.25 ZEC to a Dev Fund.
  • At each halving interval thereafter, both the miner reward and the max Dev Fund reward are reduced by half, indefinitely.
  • Users have some way to vote with their ZEC how much to fund the Dev Fund on some periodic basis. Let’s say these votes happen monthly. Some examples:
    • If all ZEC votes to support the Dev Fund, the full 1.25 ZEC per block is issued to the Dev Fund for the following month.
    • If only 40% of existing ZEC supports the Dev Fund, then only 0.5 ZEC per block are issued to the Dev Fund for the following month.
    • If 0 ZEC supports the Dev Fund, 0 ZEC per block are issued to the Dev Fund for the following month.

Some implications of this design:

  • The total issuance matches the current Zcash issuance schedule, so same number of ZEC are produced over time tapering off at 21M ZEC.
  • If the Dev Fund issued in any month is less than the maximum, then fewer total ZEC are issued. This means there would be a smaller supply of ZEC so all ZEC holders would benefit in proportion to the ZEC they hold.

Some open questions:

  • How would the voting be implemented technically and securely?
  • Would the voting be private so that no one can tell how anyone else voted? (Seems ideal, but potentially difficult.)
  • What about people who don’t vote?
    • This is actually more specific about ZEC which doesn’t vote. This is probably an extremely important decision, because much ZEC will be in cold storage, on exchanges, etc… From what I’ve noticed of “on-chain governance” examples, like Aragon, Tezos, Cosmos, etc… I think typical turn out for votes is often in the 2-5% range, or maybe 10% in extreme cases. So the main question would be if non-votes support or reject the Dev Funding.
  • What about custodial systems? If a user owns ZEC in a deposit on an exchange, what if the exchange (who controls the private key) votes with those funds? What if the exchange doesn’t vote, but the user wants to vote? What about cold storage? etc…

Let me know if this example proposal matches the intent of the original proposal, or if not, how not.

Edit: Added examples about non-votes being very important. Added open question about custodial services and voting.


The crux, is this zip is going for longevity.

  • Mining fees are what will keep the system running.

  • By baking the addresses into the codebase you do not need the wallet software or pool software to show an address. This limits 3rd party developers redirecting these funds for themselves - in the same way as the FR

  • The addresses might need updating from time to time. This prevents wallets sending to old addresses and meant wallet maintainer do not need to keep remaking their software.

  • It makes it easier for pools to add support and prove that they are actually donating the % they say they are. So by mining software I am including pool software.

It already exists. No one seems to use it.

The opt-in I agree with, however for longevity it would be advisable to bake it into the protocol. That way when I get my usb drive out in 20 years it will automatically donate (if set) to the foundation.

I would like to put in a quote from a different thread about this exact issue from @acityinohio

That is the last post in a very small bit of the 2020 thread. please read this from @str4d and the following two posts. That quote is from the third.

It is a much easier sell to a pool and wallet developer to include it, than it is for someone to actively think, I need to donate, how do I do that, etc.

Not really no. I will put forward some proposals I don’t agree with because we are running out of time and no one else seems to be doing it. - but not today.

Block distribution has to remain the same. The spirit of this zip is to eliminate the need for voting, whilst enabling features in the previous zip.

The problem with voting is getting a quorum, for the very reasons you outlined. It is a store of value (like bitcoin) not an asset of transference of value (like monero) - But this is only because of where we are at in the development cycle. Until zec can be a monero replacement, which it will be, these will be tough times. I posted to you in another thread regarding this, and if this is done by the end of the FR then it has been a success.

  • non votes are always for not changing. its unfortunate but I don’t think voting and crypto go together.
  • What if people vote to depreciate z transactions?
  • If amount of coins increases your voting power then whales and mining pools will always vote that the users pay.

This is exactly the issue. We are making decisions with other peoples money that they have in a safety deposit box and probably don’t follow the forums, or crypto in general. This is why it is so important that the initial rules are stuck to, and backward compatibility is maintained.

This is why we cannot have voting.

Am I still doing this right? Thanks again for the quick response.


It should be noted that that was a donation page I set up before I started working for the Zcash Foundation. It was not for Zcash protocol Development, but to help pay for monthly server costs since I used to run the chat and main website out of my own pocket, but now I work as a contractor with the Foundation and have taken links to that page down from the main site. I will also take down that page too.

Edit, it’s removed.


My apologies for the mistake.

You kinda undermined my argument a bit here tho, lol. That is some nice donation money for keeping things up and running. Im sure it didn’t cover everything but you did really well.

Thank you for doing what you did. I never really realised how much you had given to the community before.


BTC price wasn’t as high back then, so it wasn’t enough to cover everything but it was enough to keep my wife from yelling at me when I paid the bill for it each month :joy:

But to your point, as I and Radix42 can attest to, just having a donation page up is almost never enough to support full time work on a project unless the developer is willing to donate thier time for free and have donations cover the hard costs.


Just a quick question.

I was going to @ a few ppl but I thought Id ask you quickly first:

Do you think it would help to consolidate the OP with my responses to Nathan and possible objections/issues and stuff that is not covered by it?

Entirely up to you, think if you were visiting this thread for the first time, what information would be best to present in the first post to help you convey your idea?

1 Like

I think for threads like this where a proposal idea is being crystallized into a ZIP draft, it makes sense to use the OP for tracking this progress. That could include continually-updated “Motivation” and “Rationale” sections (that would become part of the ZIP), which would probably be the most useful sections for a newcomer to read in order to catch up with the current state. Maybe also include the full proto-draft itself depending on its length (or a link to wherever the thread participants are drafting the text).


That’s mostly very true.
However, it could be at least be part of several independet funding sources which together could add up in covering developement or given tasks that must/should be funded.

1 Like

Thank you. Could you point me towards a couple of well written zips so I know what sort of format to copy, and what sort of wording to use.

I complete agree with the sentiment that hopefully the OP can just be cut n pasted into a zip.


1 Like

ZIP 210 is probably the simplest ZIP that was written after ZIP 0 was finished. It has all the sections that you’ll see defined in the ZIP Format and Structure section of ZIP 0, for what is conceptually a simple proposal.

Other ZIPs that affect coinbase, and may be useful for you to examine:

You can ignore reference implementations etc. for now.

Having seen your current OP summary, I’m now also thinking that it may be useful to have “Drawbacks” and “Alternatives” sections in some ZIPs to complement the “Rationale” section, similar to in Rust RFCs (here’s a short example). It may be useful as a summary of the community discussions that led to the ZIP. We can figure that out as we go.


Thank you for hand holding me thorough this - I saw the templates but didn’t really get it until the examples you gave. Personally I like bullet points, but I will do both and see which works better.

I think have everything I need now. I will have problems with the specification part. I will fill in what I can.

I agree on the Rust style, that is what I am a lot more familiar with.

And for reference implementation, I probably will not be able to provide that.

Thanks again.


My main concern with this proposal and any other fully opt-in funding mechanism at this stage of development is that it creates a lot of uncertainty and potentially instability. With proper governance and accountability, I think a lot more can be achieved through a guaranteed funding pool. I admit that this comes with its own set of problems and challenges, so it all boils down to strategic trade-offs and timing. I’m not against opt-in, I’m just worried whether it will create more problems than it solves given where Zcash is and what needs to happen for it to be successful.


Thank you - I appreciate you taking the time to give me feedback

For me that is really valuable and useful feedback. I will try to incorporate it in. It does also help my greed v burn suggestion. the greed option was my compromise I was going to put in to make my proposal more inline with anthers (I think amiller’s, not 100% sure - the idea seemed to get a lot of community support, wanted a greed option added.)

I will think about this and the best way to address it in this zip, once I have done that I will post some updates to the OP and maybe a few more questions in this thread.

It is a concern that does need to be highlighted in the proposal somewhere, if I find a mechanism or idea to solve it - it will probably be needed to be solved or at least properly against other zips (I can do that)