This section documents various proposed governance improvements for Polkadot, Kusama, and network-alikes.

## Council Keep-Alive

 This section describes a specification, with identifier 60-CKA. (Discuss)

Historically, many councils in Polkadot-alike networks suffer from inactivity issues. The councils are also suffering some additional problems.

• A motion can span across multiple council terms. In this case, when council memberships change, old votes become invalid. Council can also be with seats empty, and this can cause a council motion to become totally invalid due to required approval count when a new council term begins.

• The difference between no-vote and abstain is blur. In the past, some council members have indicated that they do not have strong preferences over some council motions, or they need more time to think about it. Currently, it is hard to differentiate that from simple inactivity.

• The current council design does not promote thoughtful council discussions. Rather, it simply encourages people to either immediately vote or to remain in abstained status.

### Council period and term

Define council period as $$P$$. A council term is $$2P$$ and council elections happen every council term. A council term begins with a $$P$$-length proposing period, and ends with a $$P$$-length voting period.

### Proposing period

During the proposing period, all council members can propose council motions (for as many as they want). The motions are recorded on-chain, but unvoted. It is expected that council members use this period to thoroughly discuss motions, before reaching any conclusions.

Council motion semantics remain unchanged. It will still require at least threshold votes (as defined in the motion) to pass.

### Voting period

Once the proposing period ends, all proposals during that period enters voting status in the voting period. No new motions can be proposed during this period.

Instead of voting on individual motions, council members submit a full council report via a new extrinsic council.submitReport. The report is a list of tuple of (motion_id, pref) where pref can be Aye, Nay or Abstain.

A council report cannot miss any votes. Missing-votes council reports are invalid, and council.submitReport will reject any such extrinsics. The goal here is to make sure all motions under the current voting period are considered.

### Motion approval

At the end of the voting period, motions enter one of the following status.

• Approved if more than or equal to threshold council members voted Aye. The motion passes and gets executed.

• Rejected if more than (total - threshold) council members voted Nay. The motion is rejected.

• Delayed if none of the above happens. Indicate that council members haven’t made up their minds. If not enough people voted Aye and not enough people voted Nay, then the council motion will be delayed, and voted again in the next council term’s voting period (by entering the next proposing period).

### Aliveness check

By the end of the voting period, if a council member fails to submit a council report, then it is removed from the next election’s candidacy list. This simply gives other runners-up a chance to join and does not imply any ill-will. Candidate votes are kept, and the previous council member can later submit candidacy again to become active.

With aliveness check and an explict abstain vote option, we can expect council members to be more active, and as a result, the notion of "prime member" does not hold any special rights any more.

### Emergency motion

In some occasions, emergency motions have to be proposed. For them, we design a special motion category. Emergency motions are voted as soon as it is tabled. Emergency motion only lasts time $$E$$ (recommended to be only several hours) and there is only one voting choice — Second. If more than threshold council members seconded an emergency motion, then it passes and gets executed. If less than threshold council members seconded an emergency motion, then it is rejected.

 This section describes a specification, with identifier 58-BVOTE. (Discuss)

Currently, voting results of a democracy referendum are published in real time. If a user holds an opposite opinion of what the current "majority" thinks, one may be hesistant to express oneself. If a large group of users do this, we may lead to a situation of a "silent majority". This system also gives some unfair advantages for those who vote very first (because they can influence the initial sentiment of the public), or those who vote very last (because they will have a good idea how much they should use to vote and lock in order to sway the voting results around).

This proposal changes the voting rule so that we divide the voting period into two phrases. In the first phrase, everyone votes blindly, by publishing a pre-image hash onto the blockchain, and then in the second phrase, the pre-image is revealed.

### Specification

Divide the voting period into two phrases, blind voting phrase and revealing phrase.

Change democracy.vote. It still takes vote value and conviction in cleartext. However, the voting choice "Aye" or "Nay" is changed as follows:

• In blind voting phrase, every voter generates a 32-byte secret, and compute the hash of SCALE encoding (secret, AYE) if one wants to vote Aye, or (secret, Nay) if one wants to vote Nay.

• The voter then publishes the hash to the blockchain. As the vote value and conviction at this stage is cleartext, the coin is then locked for the specified enactment.

• In revealing phrase, every voter reveals the preimage. The 32-byte secret is then discarded, and the voting choice Aye or Nay is recorded.

• Once the releaving phrase is finished, the referendum is accepted or rejected based on the current voting rules.

## Allow explicit abstain in adaptive quorum biasing

 This section describes a specification, with identifier 59-ABVOTE. (Discuss)

Allow explict abstain votes, for voters who really don’t have an opinion on a referendum, but still wants to participate in governance. In case of adaptive quorum biasing, abstain votes are counted in the total turnout.

### Specification

Add a third type of choice for voting — abstain.

In case of adaptive quorum biasing, the voting result is calculated as follows, where $$T$$ is the total issuance, $$Aye$$, $$Nay$$ and $$Abs$$ are the total number of coins voted Aye, Nay and Abstain respectively.

• For a super-majority approve referendum, we calculate if $$\frac{Nay}{Aye + Nay + Abs} < \frac{Aye}{T}$$

• For a super-majority against referendum, we calculate if $$\frac{Nay}{T} < \frac{Aye}{Aye + Nay + Abs}$$