What's new

Treasury Donation Address

Eric_Stanek

Active Pivian
Governance Proposal:
Treasury Donation Address

PLEASE NOTE:

This is a Protocol Proposal and not the typical Treasury Proposal.


BACKGROUND:

Given this is the FIRST Protocol Proposal, it is probably best that I include a reference to what that exactly is.

In 2017, the "CDG: Multiple Governance Categories" proposal passed by a landslide.

From that proposal;


Protocol Governance:

These proposals are zero cost and are to make decisions to change the code base (the protocol) of, or the priorities of changes to, the PIVX system. If such a decision requires funding, then that funding portion would be a separate Treasury Governance proposal submitted after the Protocol Governance proposal has been accepted. What is unique about Protocol Governance is that the Core Developers can veto such proposals if they are technically impossible, or logistics dictate an order of implementation different that that voted on in the proposal.



This means that if this proposal passes, asking that the requested functionality change to the code base be implemented, the PIVX Core Developers can then veto and reject the request if it is technically not possible. For example, if it is a request that sounds easy - but would break privacy and violate the PIVX Manifesto - it would be considered infeasible.



THIS PROPOSAL:

COST:

This proposal only asks for 10 PIV, which is the minimum amount possible. This is the best that can be done to follow a 'zero cost' proposal as the above description states. However, I believe that intent allowed for requesting the reimbursement of proposal fees. This proposal does not ask for fees to be reimbursed. The ‘zero cost’ in my mind, was simply to communicate a Protocol Proposal asks for a decision and not project funding. That funding would be via a separate conventional ‘Treasury Proposal’.


CODE FUNCTIONALITY CHANGE REQUEST:

This proposal asks for a simple Yes or No vote, to determine if the DAO requests a 'Donation Address’ be added to the PIVX Treasury System. Anyone donating to that address, is increasing the budget above the 43,200 PIV available each cycle.

For clarity, we will refer to the current PIVX Treasury amount of 43,200 per superblock as the PIVX Network Treasury, and the amount in the ‘Donation Address’ as the PIVX Donation Treasury.

Proposals would be submitted and voted on by the Masternode Owners (and eventually the Stakers) as they already are.

Proposals that are passing, would be paid out by the PIVX Network Treasury first as they already are.

Remaining passing proposals that were not funded, because the regular 43,200 PIV allocated by the PIVX Network Treasury was reached, are then paid out from the PIVX Donation Treasury, until it runs out.

As we know, the regular 43,200 PIV from the PIVX Network Treasury is not carried forward if not used. Those unallocated coins are not burned - they are not even created in the first place.

The PIVX Donation Treasury coins are different. They exist and are not burned. If unspent, they are carried forward to the following budget cycle.



VOTING DETAILS:


We needs some discussion on this before we can incorporate Community feedback and turn this into a proper proposal and submit it with voting details.

Please add your comments!
 
Last edited:
I like this.

Would it be a good idea to create an issue for this and all future protocol proposals in the PIVX github?

And then when/if this passes it can be picked up easiers by the devs as a project/feature.

This will make a huge difference to the funding of PIVX by allowing funding not linked to the price of piv.
 
Awesome! Could a % be set aside for a special charity - or we have a list of 20 and we rotate donations to them? One criterion would be they must accept PIVX in general and abide by a set of core values we all decide on as a DAO
 
If people want to donate to a Charity, they are free to do so. But setting some aside would complicate things dramatically. It has been discussed before with the current treasury. The same arguments apply here. It would need a 2nd voting system to maintain the list of charities. The goal with this idea is simply to supplement the Treasury for the Governance System. So, if someone were to submit a proposal for a specific charity, then it could be paid that way. If people don't feel that is the right place for a charity - then placing it ahead of the vote into a 2nd voting system isn't either.

Likely a much better option is those people donate to one or all of the charities that will be listed in the PIVXgives.org site being developed.
 
Going to jump in here and clarify that the budget/proposal system currently in place holds absolutely zero weight over protocol/network level changes, no matter how honorable such changes may be or what was stated in the past. I wasn't quite involved when the proposal you reference was submitted and voted on, and a proposal like this (if it gets submitted to the network, and passed) cannot dictate what the dev team should or should not focus on in any way.

All that said, proposal addresses ARE currently public knowledge at the time of proposal submission. It would not be a stretch to ask proposal creators themselves (rather than the network/protocol) to account for any user deposits to the proposal payout address. This is something that the dev team will be incorporating ourselves in our next proposal (currently slated to be submitted for the Aug-Oct cycles), wherein we will be providing explicit details as to where and/or how non-budget generated deposits to the proposal's payout address will be treated.

Considering the fact that proposal creators would be required to detail a plan for external donations regardless of how they receive them, it is much simpler of a solution to just require any proposal creator to detail/account for a situation where they receive funds to their proposal address from outside the current automatic budget payout system, and forego a convoluted secondary "donation address" scheme on the network/protocol level.
 
Not sure I follow everything. But, it was expected that it would be significant work and may take some time to reach the top of the priority list, especially given the current roadmap. No worries there.

What will happen for at least the next 2 superblocks, is that the process in this pre-proposal will be followed manually, perhaps paying out to a completely separate receive address for the proposal creators if that makes more sense. I assume that once we've done this a couple of times, some of the 'logistics' will become more clear.

When the PIVX Foundation pays individual proposals, they are basically 'hiring' a contractor. That creates paperwork (invoices etc.) and also could create scenarios where the proposal is not really 'proper' for the PIVX Foundation to be involved in. (I really need to stretch my imagination to think of such scenarios - but it could happen.) The thought is that if the donation is simply made directly to the Treasury and paid out thru the protocol as normal Treasury funds are, then the paperwork goes away, proposal creator privacy is maintained, and any proposals that might not be 'proper' for the PIVX foundation to pay out become moot - because they could not possibly have known what proposals would have been submitted, let alone passed, when the donation was made.

Remember - even if this proposal passes, since it would be a Protocol Proposal, the developers have a right to veto it, with an explanation. For example, it might be impossible (either logically or because it breaks privacy), or can't be implemented until something else is completed first, or there simply are no developer/funding resources available to do it. (The resource issue is likely applicable here - because I know we inherited the Governance code from Dash and it is complex - with AFAIK only Mrs X being familiar with it.) Even in those cases, the vote is still valuable, because it communicates the desire/intent of the PIVX Community. That can then be noted for future consideration.

There will be 21,600 PIV donated at each of the next 2 superblocks. This obviously is a 50% budget increase. So, these are good problems to have!
 
Top