# \[ZIP 1002\] FINAL: ZIP Proposal - Genuine Protocol opt-in/out donation feature updated 02/sept **URL:** \ **Category:** protocol\ **Created:** [June 19, 2019, 11:59am UTC](https://forum.zcashcommunity.com/t/zip-1002-final-zip-proposal-genuine-protocol-opt-in-out-donation-feature-updated-02-sept/33846 "2019-06-19T11:59:49Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![mistfpga](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/mistfpga/32/17700_2.png) [@mistfpga](https://forum.zcashcommunity.com/u/mistfpga)\ **Post date:** [June 19, 2019, 5:16pm UTC](https://forum.zcashcommunity.com/t/zip-1002-final-zip-proposal-genuine-protocol-opt-in-out-donation-feature-updated-02-sept/33846/3 "2019-06-19T17:16:03Z")
> [@nathan-at-least](#): > > Hi, I don’t understand how this is different than voluntary donations as part of existing transactions. 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. > [@nathan-at-least](#): > > This is completely opt-in and works with the existing protocol. It already exists. No one seems to use it. - [Address: 15VZNqUazPKoK8rJMFb5XUzuB4o6Ww6xD3](https://www.blockchain.com/btc/address/15VZNqUazPKoK8rJMFb5XUzuB4o6Ww6xD3) Source - [https://www.zcashcommunity.com/donations/](https://www.zcashcommunity.com/donations/) 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 > [@The future of Zcash in the year 2020](https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/267): > > I understand the concern about complexity, but in our view this would preserve user choice and provide important signaling for the ECC, Zcash Foundation, and any other recipient of a future fund. Note that others associated with the Foundation may have more detailed or nuanced personal views (see @amiller’s comment above), but this was the consensus reached by the Zcash Foundation Board of Directors on how we’d approach the possibility of a new dev fund. 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. > [@The future of Zcash in the year 2020](https://forum.zcashcommunity.com/t/the-future-of-zcash-in-the-year-2020/32372/265): > > The only way any of the above could be implemented as an adjustment to the consensus rules[1], is for the consensus rules to specify that certain hard-coded addresses may optionally be present as outputs. But if it’s optional, then it’s basically useless as a consensus rule. Users and mining pools are already free to optionally add addresses as outputs to their transactions (a few wallets have done this in the past as “dev fees”, and IIRC some mining pools in the Grin network opt to donate a sm… 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. > [@nathan-at-least](#): > > 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? 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. > [@nathan-at-least](#): > > 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? 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. --- _[View the full topic](https://forum.zcashcommunity.com/t/zip-1002-final-zip-proposal-genuine-protocol-opt-in-out-donation-feature-updated-02-sept/33846)._