Joystream Stats fcbd88a006 merge archived helpdesk | 2 tahun lalu | |
---|---|---|
.. | ||
README.md | 2 tahun lalu |
When the Council
was first introduced, it was only able to vote on whether or not a runtime upgrade should be implemented. This very rarely occurred, making the Council a rather insignificant part of the platform.
As the Council
is intended to be the executive arm of the Joystream governance system, we have now developed a proposal system that allows users to control most of the day-to-day decision making on the platform.
The list below contains all the proposal types currently available.
Aka "Signal Proposal"
Although no action will happen if such a proposal is voted through, it provides a way for user to request changes, propose improvements, complain about something, and in general voice their opinion on a matter. This will open a discussion, and Council Member can signal their approval or rejection through a vote. This can be used to notify the platform developers about key feature missing, highlight a topic of controversy, etc.
Aka "Funding Request"
In general, this proposal will include an amount, and a beneficiary. This can be used to fund development, pay winners of competitions, make bonus payments for a role, or anything else that requires minting new tokens to a specific individual or group.
The Validators are rewarded for producing blocks, and will share the rewards that are minted each era (target 3600 blocks). This reward is calculated based on the total issuance, and the amount of tJOY staked by the pool of Validators relative to the total issuance. A higher number means smaller rewards for each individual Validator, but set to low and the network grinds to a halt.
As the Council will see a significantly increased workload, there may be a need to change some of the Election cycle parameters. This proposal allows the Council to vote on expanding the Council seats, increase or decrease the length of the Voting process, or the minimum stakes required to participate. If this proposal is voted through, a change of these parameters will not be activated until the next election cycle, to avoid the current Council making changes benefitting themselves.
As before, upgrading the runtime can be proposed by any member, and voted in by the Council. This is a critical proposal that, if a "bad" runtime is proposed and voted in, can kill the blockchain.
This proposal allows an opening for a Working Group Lead to be created. When editing the "Opening schema", you must ensure your changes still return a valid JSON schema. This determines what information is collected from candidates. Note that the reward specified is not binding, and is only determined when the Fill Working Group Leader Opening proposal is made (and approved).
This simply sets the opening for Working Group Lead to the "in review" status, meaning no further applications can be accepted. It is required to move on to the Fill Working Group Leader Opening
proposal.
If the Opening is in the "Review Stage", use this proposal to propose a specific Lead. The Council can now vote, and, if approved, this will be the new Lead.
Note that there can be multiple proposals of this type at the same time, so multiple candidates can be considered simultaneously. However, once one is approved, the others will fail.
This effectively acts as a budget for a Working Group; the Lead and Worker payments are taken from this mint. The Working Group Lead will be unable to spend more than the limit established by this proposal. This proposal also does not add tokens to any residual funds remaining in the mint, it sets the mint capacity to exactly what is entered in the proposal once it is approved.
To punish or warn the Lead of a Working Group for not performing their job correctly, they can be slashed partially or fully without firing them using this proposal type.
This proposal type allows decreasing the stake of a Working Group Lead.
This proposal allows for changing the reward for the Lead of a working group if it appears too little or too much. Note that only the amount can be changed, not the frequency.
If for whatever reason the Working Group Lead needs to be removed from their post (and potentially slashed), this is the proposal type which needs to be voted on.
This allows users to make a proposal to "fire" a Storage Provider that is not performing the role satisfactorily.
The Storage Provider will be paid by minting new tokens, effectively increasing the tJOY supply. The incentive will be to keep both the number of slots, and the size of the individual rewards, as low as possible while maintaining a sufficient service.
The Content Curator Lead is the first implementation of the concept of Group Leads on the platform. These will in general be responsible for hiring, firing, rewarding and training the group they are leading. They are hired by the council, and will be given a budget to perform their role satisfactorily, without inflating the supply more than necessary.
This means they have to answer to the users if they fail in their task. In this particular case, all members can propose to:
If the proposal is voted through, the change will occur immediately.
To avoid the Lead paying themselves too much, or frivolous spending in general, the Lead can only spend as much as the Mint Capacity. Effectively, a budget for their spending. Once the Mint runs out, recurring rewards for the Content Curators (including themselves) will be frozen.
If the Lead, or anyone else, wants to replenish or drain the existing Mint, a proposal can be made. If voted in, the new Capacity proposed will be set immediately.
A voter can choose between the following outcomes:
Approve
- approving the proposed actionReject
- reject the proposed actionSlash
- reject the proposed action, and slash the stake of the proposerAbstain
- abstain from votingBelow is a list of the states a proposal can be in, and what each of them means:
Active
- the proposal can be voted on, and no resolution has been madeGrace Period
- the proposal has been approved, and is awaiting executionExecuted
- the proposal was approved, and, after a potential Grace Period
, executed on chainExecution Failed
- the proposal was approved, and, after a potential Grace Period
, attempted to be executed on chain. For some reason, the execution failedRejected
- the proposal was rejected by the councilSlashed
- the proposal was rejected, and the stake of proposer was slashed by the councilExpired
- the council members did not reach consensus and the proposal expired without any action. This can be the result of insufficient voter turnout, or disagreement between the council membersThe parameters below are specific to each proposal type, and the values are chosen to balance the importance and risks associated with each of them.
approve
, relative to those that vote abstain
, reject
or slash
There are also some general parameters that apply equally to all proposals, such as fees, length of text allowed, the maximum number of proposals currently in the active
stage, etc.
Any member of the platform with a sufficient quantity of tokens to stake can create a proposal. If the proposal includes values that are within the allowable range, and there are fewer active
proposals than permitted, the proposal will proceed to the active
state where the council can vote on it.
Suppose there are currently 20 members of the council. A proposal to set max validator count is made, where the parameters below apply:
Proposal Parameters | Value |
---|---|
voting_period |
43,200 |
grace_period |
0 |
approval_quorum_percentage |
50% |
approval_threshold_percentage |
75% |
slashing_quorum_percentage |
60% |
slashing_threshold_percentage |
80% |
required_stake |
25,000 |
A member puts up the required stake of 25,000 tJOY, and the proposal goes the active
stage at block height 100,000.
The votes come in, until we have:
Approve
Reject
Slash
Abstain
At this point, the Approval Quorum
parameter is fulfilled (100%>75% approval), but there are still too few votes cast to fulfil the Approval Threshold
(at 30%<50%).
A few more votes are cast:
Approve
Reject
Slash
Abstain
At this point, neither the Approval Quorum
parameter (67%<75% approval), nor the Approval Threshold
(at 45%<50%), is fulfilled.
Another vote comes in:
Approve
Reject
Slash
Abstain
At this point, Approval Quorum
parameter (60%<75% approval) is not fulfilled, whereas the Approval Threshold
(50%), is now fulfilled.
A few more votes are cast:
Approve
Reject
Slash
Abstain
At this point, Approval Quorum
parameter (67%<75% approval) is not fulfilled, whereas the Approval Threshold
(50%), is now fulfilled.
A final vote for Approve
is cast, and the (unfinished sentence)