Can we not jump the gun here arbitrarily defining quotas for this? It really defeats the point of even implementing the voting system...
With some fixes to the multisig implementation, you have a clean masternode supported donations channel, this should be the avenue utilized for funding at the moment at masternode operator discretion. I wouldn't be opposed to a default "donation" imposed in the client either so long as the change was rolled out transparently.
This needs to be phased and not alienate anyone here. You guys have made a lot of off-the-cuff decisions and it's made adoption a whole lot rockier than it could be. We're over a year in at this point and need to settle out on protocol level changes... I'd propose something more in the way of the following:
1) Avoid making changes to the block templates, mining is still essential to this coins operation and breaking miner configurations or incentives should be avoided until a suitable alternative is provisioned for.
2) Create defined oversight and exhibit the system before channeling funding towards it. The voting mechanism should even be an integral part in making changes of this nature. No one 's expected rewards whether through mining or masternode operation should be arbitrarily changed, and there should be no expectation of constant funding to anyone involved on this project from the consumers.
3) Tune-up masternode multisig donations and create/update multisig addresses to provide for the claimed functionality:
a) Foundation should have an address anyone can contribute to. This is to facilitate the project, handling legal aspects, etc. This is to be a blanket account which would allow for discretionary spending or project allocation as necessary even on the same system indicated in OP.
b) Core Team should have an address anyone can contribute to for discretionary spending. Transparency of course expected, and likely require surpluses released back to foundation per charter.
c) Masternode network should ultimately be responsible for signing on the proposals without funds being arbitrarily distributed for future allocation. Here I propose some changes to the POSE system to allow for voting mechanisms to have expectations of actualization.
4) Alter the current POSE system to have more reaching potential. Currently it's just an isMisbehaving boolean with enough gray area to account for network anomalies. This could be rebuffed into something much grander, including a decentralized solution for the current roundrobin masternode payment modeling. Ultimately, for voting to be effective, we need a proof of trust model and this addresses both. Ideally, masternode network would also have the capability of generating multisig payments and established trust is needed to reasonably expect masternodes to sign in a timely manner enabling a truer form of network managed escrow. Expectation is this run on mainnet for some time after sufficient testnet time without influencing payouts before being enforced, with provisions to reset pose counters before enforcement would begin.
a) Create a secondary counter and define scope on POSE, defaulting to some value, say 2048 (arbitrary so as to be large enough to allow reduction and alternative use cases without a specification change in the future and happens to approximate current masternode count. For each block, masternodes perform their network checkout and behaving active nodes get this counter incremented while misbehaving nodes are given the 6-stage buffer zone before being penalized on their payout counter unless an action of malintent demands punishment. The masternode with the highest established pose score is the one to get paid (or random amongst top list to reduce targeted attacks) after declaring eligibility (see 'b'). Payout results in a reasonable decrementation in the counter, likely based on current masternode count with pose above default.
b) Instead of project funding allocation within block template, require a masternode to have locked a transaction for such purposes in InstantX style with extensions to length of lock per this use case. Here this becomes a secondary proof of service functionality and allows the masternode operator to directly select the project she intends to fund. This transaction must include the latest generated coinbase sent to the masternode if available. New masternodes or those who have spent latest payout would be allowed to generate this transaction from other coins supplied to the masternode operating address, effectively increasing masternode creation to 1001 coins in two separate transactions. Using alternative coins would come with an increased decrementation on payout as it reduces tracability. Upon validation of a project for funding, the network would expect payment from each pledger based on votes from their locked coinbases and approve such transactions only against the target address. If payment is not remitted by a pledger within a reasonable duration, masternode is penalized by not being permitted pose incrementation. This is now an escrow mode without requiring releasing funds to a
c) Masternode operators would be permitted an opt-out case in which these funds would be redistributed to masternode operators and miners by publishing coins to darksend with an increased fee schedule. This introduces a constant stream of virgin coins to darksend and the heightened fees on the masternode operator would increase block payouts. Forces masternode operators to support the network without demanding they pay for a project.
This is over-idealized in some regards and incredibly incomplete. Predominantly designed to seed conversation on alternatives with more fluidity and transparency while reducing alienation threat present in Evan's proposed fee schedule adjustment.