Democracy

Overview

Democracy handles the administration of general stakeholder voting.

Definition:

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.

Diagram

Description

Submit preimage

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.

Submit proposal

• 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.

Seconding 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.

Launching referendum

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.

Conviction calculation

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.

Lock period	Vote multiplier
0	0.1
1	1
2	2
4	3
8	4
16	5
32	6

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.

For example

John: Votes `Yes` for a 4-week lock period => Votes = 500 * 1 = 500

Remove vote

Users can remove their votes for referendums by calling extrinsic with function democracy.removeVote in 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.

Unlock tokens

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 result

• 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-carries which 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?	Applied method
Public proposal	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

Enactment queue

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 biasing

Adaptive quorum biasing makes 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

Note:

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 186665764*10^18

• As turnout approaches 100%, all thresholds above converge to a simple majority-carries.

For example

• Public proposal

• We only have 1, 500 GLCH tokens in total.

Member	Voting token
John	500 GLCH
Peter	100 GLCH
Lilly	150 GLCH
JJ	150 GLCH
Ken	600 GLCH

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

Summary

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 bias requires more aye votes 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.