Let the discussion begin
Thanks for raising the glove on this @cryptochef
"This is such a massive ideology, and currently I am very uncertain on how this development will unfold.
Many ideas are discussed as to how the funds taken from the blocks could be used. One idea is a vote that would award the address with the most votes the entire pool. Also been refered to as a whale pool. This idea would create in a very short period a dictatorship, in my opinion.
We have also discussed ideas such as burning tokens or storing and holding.
The main issue currently i see in zen is the current value. So this should be the first order of business. To create value and to use the CGP in whatever method to increase our MC."
My toughts are that we will go through a learning proccess as best practices are developed of how funds are distributed in a legitimate manner.
Just to clarify, the proposal allows is a recurring vote (every 10,000 blocks) on:
- what % of coins from the block rewards go to miners, and what % of coins go to the CGP.
- Distributing the a fixed amount of accumulated funds in the CGP to an address.
To expand on the above:
The current proposal puts a cap of 50% on how much the allocation to the CGP can change in each interval. At most 99% of the block reward can be allocated to the CGP.
Each vote on who should be awarded funds from the CGP says two things: who the winner is, and what the allocation should be. The “winning proposal” comprises both of these two things. In other words, if there are 1000 votes for John to get 10,000 ZP, 1000 votes for John to get 5,000 ZP, and 1001 votes for Mary to get 30,000 ZP, then Mary will win.
A “winner” can be either a normal “public key” address, or a contract.
If the winning proposal doesn’t allocate all the funds in the CGP, then the remaining funds stay there.
There is always a winning proposal. It is not possible to vote for anyone to get 0 ZP. So at least some of the CGP is always awarded.
It is not possible to burn funds from the CGP directly. However, it is easy to do so indirectly, either using a contract or using a “fake”/“eater” address that can’t possible match a real private key which someone knows.
It’s possible to implement a different voting scheme using a contract. Any suggestions?
True, it will be a learning process and we can all improve it as we go.
With the current ‘winner takes all’ model I suspect that it won’t do justice to it’s name ‘Common Goods Pool’. Let’s be realistic, given a choice of own good and ecosystem good, people will choose the first option, pool of people can collude together and vote to win and allocate themselves dividends.
Not sure if anyone heard of https://proposals.decred.org/
I understand that this is somewhat centralised, but some brilliant minds here in zp can come up with a decentralised version of this modal maybe!!
At the end of the day, if we naming it CGP then we as a community must ensure that the funds are used for common good.
I am biased because of my contract work with the RadicalxChange Foundation as the Director of Finance, but I vote for a Liberal Radicalism style CGP funds allocation.
The mechanisms of funds allocation is described in this paper here (ignore the authors – just focus on the content):
Welcome @AdamPerlow to our forum
Good to be hear Crypto Chef
A thought that has been suggested is to create a white paper in regards to the CGP development.
So the new point change cap will be 15% and not 50%.
So basically 15-30-45-60-75-90-99 max and so on or vice a versa.
These are all great ideas Sun.
Also note, there will be no single person deciding this. We as a community must get behind and vote for any such proposals when they are put through voting.
Yes, everything suggested must be voted on.
What is Zen Protocols procedure to submit suggestions for the CGP? Is this described on the website, or in any releases? If you have access to this information it would be beneficial if it was made readily available.
I am not exactly sure how these proposals will be managed, but I imagine that we will probably use Gitlab/Github in order to manage these proposals and “Accepted Proposals” will be merged into the main Codebase… clearly not all of these proposals will be code changes but text documents laying out the proposals will suffice for tracking purposes.
I would ask @AdamPerlow to comment here on his thoughts on how this management of proposals will work from a procedural standpoint.