Democracy handles the administration of general stakeholder voting.
Proposal: A submission to the chain that represents an action that a proposer (either an account or an external origin) suggests that the system adopt.
Referendum: A proposal that is in the process of being voted on for either acceptance or rejection as a change to the system.
Enactment Period: The minimum period of locking and the period between a proposal being approved and enacted.
Lock Period: A period of time after proposal enactment that the tokens of winning voters will be locked.
Conviction: An indication of a voter’s strength of belief in their vote. An increase of one in conviction indicates that a token holder is willing to lock their tokens for twice as many lock periods after enactment.
Vote: A value that can either be in approval (“Aye”) or rejection (“Nay”) of a particular referendum.
Second: Signals agreement with a proposal, moves it higher on the proposal queue, and requires a matching deposit to the original.
The act of making a proposal is split from submitting the preimage for the proposal since the storage cost of submitting a large preimage could be pretty expensive. You can copy this preimage hash and save it for submitting the proposal without clicking Submit Preimage. Allowing for the preimage submission to come as a separate transaction means that another account could submit the preimage for you if you don't have the funds to do so. You can copy this preimage hash and save it for the next step.
However, at some point before the proposal passes you will need to submit the preimage, or else the proposal cannot be enacted.
- Making a proposal requires proposers to bond some tokens. The bonded tokens will only be released once the proposal is tabled (that is, brought to a vote); there is no way for the proposers to revoke their proposal and get the bond back before it has become a referendum.
- After being submitted, a proposal can be added to two different queues before it becomes a referendum:
- The proposal queue consists of all public proposals.
Max of public proposal= 100
- The external queue consists of Council-approved proposals.
Max of external proposal= 1. Note that the existing external proposal in the queue is overridden by the next external proposal.
- If someone else agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called seconding. By seconding a proposal, it can be moved up to a higher rank in the queue. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote); there is no way for the user to "revoke" their proposal and get the bond back before it has become a referendum. Since it is essentially impossible to predict definitely when a proposal may become a referendum (if ever), this means that any tokens bonded will be locked for an indeterminate amount of time.
- Note that no restrictions are made on the number of times a single account can second a proposal.
Any number of public proposals can exist simultaneously, but only one can make it to a public referendum during each voting period to avoid conflicts.
Every launch period (currently 7 days), the Democracy pallet launches a referendum from a top proposal that it takes from either the proposal queue or the external queue in turn. The "top" proposal is determined by the amount of stake bonded behind it, not number of the supporters. If the given queue whose turn it is to create a referendum that has no proposals (is empty), and proposals are waiting in the other queue, the top proposal in the other queue will be brought to a referendum every launch period.
Voting on proposal
Max votes per account= 100
Any token holder in the system can vote on referenda. The voting system uses time-lock voting by allowing the token holder to set their conviction behind a vote. The conviction will dictate the length of time the tokens will be locked, as well as the multiplier that scales the voting power. Token holders may lock up their tokens for a greater length of time to weigh their vote more strongly. By default, users who voted for a passed proposal must lock tokens up until the proposal’s enactment. This lock makes them stay in the network and endure the ramifications of their vote, while those on the losing side of the referendum are free to exit. While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account.
Votes are still "counted" at the same time (at the end of the voting period), no matter how long the tokens are locked.
Token holders are allowed to increase their voting power by declaring how long they are willing to lock up their tokens, hence, the number of votes for each token holder will be calculated by the following formula:
votes = tokens * conviction_multiplier
The conviction multiplier increases the vote multiplier by one every time the number of lock periods doubles.
The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 8 days. Only doublings are allowed. Token holders cannot lock for 24 periods and increase their conviction by 5,5.
John: Votes `Yes` for a 4-week lock period => Votes = 500 * 1 = 500
Users can remove their votes for referendums by calling extrinsic with function
democracy.removeVotein the following cases:
- The referendum has not finished.
- The referendum has finished and has not been put into the enactment queue.
- The referendum has finished, passed to the enactment queue and the voter's lock period is up.
After the lock expires, the user must explicitly call an unlock extrinsic to make their funds available again. Users need to submit the following extrinsic:
democracy.removeVote(index)using the account that they voted with. They submit the following extrinsic:
democracy.unlock(target), where the target is their account address.
- Voting period = 7 days
- At the end of the voting period, Glitch tallies the votes and calculates the result. The result of voting on a referendum is based on either
simple majority-carrieswhich 50%+1 of the votes decide the outcome or
adaptive quorum biased. The method of giving out the voting result is proposed below:
Type of proposal
How to create?
Submit proposal in Democracy
Positive Turnout Bias
Proposals with more than 50% support from the Council
Motion → democracy. External_propose
Positive Turnout Bias
Unanimous Council (Proposals with unanimous support from the Council)
Motion → democracy.External_propose_default
Negative Turnout Bias
Majority Council (Proposal with 80% support from the council)
Motion → democracy.External_propose_majority
Simple majority carries
If the proposal passes, then Glitch’s logic automatically schedules it for enactment, 8 days later to give time for external services to make any necessary adjustments and for those who oppose the decision to exit.
When putting the proposal into the enactment queue, the system checks the preimage hash:
- If the preimage hash hasn’t been submitted, the proposal will be removed from the enactment queue.
- When the preimage hash is decoded, the system finds it invalid (for example: insert a wrong hash that is not generated by the system) → The proposal will be rejected
- Preimage is valid. However, the system checks the following conditions to decide whether to execute the proposal or not:
- Origin: Check whether the function in the proposal is executed by Sudo.
- Parameters: Check whether the parameters are valid.
When a proposal is executed successfully, the storage fee of the preimage hash is unreserved and returned to the submitter of the preimage.
Adaptive quorum biasingmakes the threshold for passing or rejecting a referendum higher or lower depending on how the referendum was originally proposed. There are two types of adaptive quorum biasing:
- Positive turnout bias
It makes a referendum require a super-majority to pass which decreases as turnout increases. It means that as the referendum turnout increases, the threshold of aye votes required to pass it lowers.
- Negative turnout bias
It makes a referendum require a super-majority to reject which decreases as turnout increases. It means that as the referendum turnout increases, the threshold of aye votes required to reject it lowers
approve- the number of aye votes
against- the number of nay votes
turnout- the total number of voting tokens (does not include conviction)
electorate- the total number of GLCH tokens issued in the network. It is currently set to
- As turnout approaches 100%, all thresholds above converge to a simple majority-carries.
- Public proposal
- We only have 1, 500 GLCH tokens in total.
John: Votes `Yes` for a 4-week lock period => 500 * 1 = 500 Votes
Peter: Votes `Yes` for a 4-week lock period => 100 * 1 = 100 Votes
JJ: Votes `No` for a 16-week lock period => 150 * 3 = 450
Votes approve = 500 + 100= 600
against = 450
turnout = 500 + 100 +150= 750
electorate = 1500
- Applying the positive turnout bias formula for the public proposal, it is calculated as below:
Positive turnout biasrequires more
ayevotes to pass the referendum when turnout is low. Based on the above result, a super-majority to pass is lower( <16,432). Hence the referendum will be rejected.