Kusama Rollout and Governance
Kusama is Polkadot’s canary network. It is an early, unaudited, and wholly experimental network, designed to help understand how the various cutting-edge technologies introduced in areas including governance, staking and sharding work under real economic conditions
By Gavin Wood•August 23, 2019
Kusama is Polkadot’s experimental “canary” network. It is an early, unaudited and wholly experimental pre-production trial network, designed to help understand how the various cutting edge technologies introduced in areas including governance, staking and sharding work under “real” economic conditions. To find out more about Kusama, visit https://kusama.network/.
This morning at around 9:30 am Swiss time, we kicked off a block chain that was soon to become “Kusama Chain Candidate 1” and with it, the first deployment “in the wild” of a protocol that was originally conceived around three years ago and under active development for almost two years. Combining bleeding-edge innovations in governance, consensus and scalability, you’re about to get a taste of the blockchain world to come. In short, Polkadot v0.5.0 is out and you can sync to the provisional Kusama network now.
In order to get off the ground with a soft launch, Kusama has begun as a PoA (proof-of-authority) network with validator nodes run exclusively by Web3 Foundation (without compensation, of course!). During this period, much functionality of the network is disabled. In particular, balance transfers are not possible and governance is limited to the “Sudo” module for which the Web3 Foundation holds the single key. Functionality enabled is limited to usage of the Staking, Sessions and Claims modules; specifically, bonding, nominating and issuing an intention to become a validator, setting up one’s session keys and claiming KSMs will be supported.
This period will last sufficiently long to allow at least 50 and ideally 100 well-backed validators to be bonded and ready. We expect it be between one and four weeks. One or more additional runtime upgrades will happen during this time to merge in additional features to the chain. This is in part to allow a further testing and development of logic and partly to test the runtime upgrade logic itself.
Following this period, the Web3 Foundation will issue a final centralised runtime upgrade. This will remove the Sudo module and with it the Web3 Foundation’s authority over the chain. It will introduce Kusama’s Genesis governance apparatus and enable the NPoS staking system, effectively transforming Kusama from a centralised PoA network to a decentralised PoS network. At this point, governance and balance transfers will become active and Kusama will be functionally live.
Genesis Governance
Kusama’s initial governance system, known as “Genesis Governance”, is a tricameral model. The Referendum chamber (which can be roughly considered the “legislative” chamber) has the broadest membership of all three and is by far the most powerful. All legislation (i.e. changes to the Kusama’s logic) must gain the approval of this chamber, which happens as an assembly of all stakeholders (i.e. KSM token holders) weighted according to both the amount of KSM held and the amount of time they are willing to continue to hodl those tokens.
The other two chambers are the Council (which has some similarities to an executive body) and the Technical Committee. The membership of the Council is a proportionally representative approval vote by token holders, weighted only be the number of tokens controlled. It will begin with seven seats, but with the assumption that they should be expanded as community interest in governance grows.
The Technical Committee is composed according to a single vote for all teams that have successfully and independently implemented or formally specified one of the two halves of the Polkadot/Kusama protocol (i.e. either the Polkadot Runtime Environment or the current Kusama Runtime). Teams that implement both are thus awarded two votes. Teams may be added or removed by a simple majority of the Council voting so.
Voting on proposals in the Referendum chamber lasts 28 days and, if approved, then a further 30 days are waited before the change comes into force. This allows time for those bonded into the NPoS consensus system (“stakers”) to exit the network in the case that they believe the legislation is catastrophic.
All voters are required to hold for the 30 day period up until the enactment date in the case that “their side wins” (if not then they are otherwise free to sell and leave the network). Those willing to hold for twice as long gain an additional vote. This is the case for up to five additional votes (i.e. those willing to hold for approximately two and a half years gain six votes). Those unwilling to hold at all may still vote but with a 90% reduction in power compared to those who hold for the four week minimum.
At 100% turnout (i.e. with all tokens attached to a vote, regardless of its lock period), no legislation may be passed without at least 50% of the first chamber’s total votes in approval. As the turnout lowers, the mechanics for approval differ depending on how the legislation was brought forward. In general, a technique known as Positive Turnout Bias (or simply super-majority carries) is applied, whereby as the number of distinct voters increases, the amount of a majority that is needed to pass the legislation reduces from 100% to 50%. Put another way, at anything less than a full turnout, a super-majority is needed to approve. The size of the super-majority that is required shrinks (and thus the chance of the motion passing grows) as the turnout increases.
There exist two special cases; one where a simple majority is needed, regardless of turnout. This counting method is usually referred to as majority-carries. The other, whose proper name is Negative Turnout Bias, but which is often known as simply default-carries, is where a super-majority of dissenters is needed to prevent the legislation from succeeding, though this again reduces to a simple majority as the turnout increases to 100%.
Proposing Legislation in Kusama
Kusama’s legislative agenda is split into monthly-proposals for the first chamber to vote on. Proposals are made by either the Council or the public (which are placed into the Public Queue). Every month, a proposal is brought to vote coming from one of them, prioritising the one that did not get a go the previous instance. Essentially, they take it in turns. It is thus the Council’s prerogative to control 50% of the legislative agenda, and the public’s for the other 50%.
The Public Queue is the broader means of allowing legislation to happen. Any user of Kusama may place a proposal in this queue by depositing a minimum amount of KSM behind it, or “seconding” an existing proposal and adding to this deposit. When it is turn for a new proposal from this Public Queue, the proposal with the most tokens deposited behind it comes to vote.
As mentioned, the mechanics for vote-counting in the Referendum chamber are generally super-majority-carries. There is an exception: When greater than three-quarters of the Council vote in favour of a proposal, the vote becomes a simple majority-carries with no reference to turnout. Furthermore, if and only if the council is unanimous in its approval, then default-carry is used as the vote-counting method.
Fast-tracking
Kusama includes logic to allow its governance system to handle unexpected conditions where legislative changes need to be made quickly. This kind of legislative “short-circuiting” allows a proposal to be brought to referendum immediately and in parallel to the normal monthly proposals.
In the case of approval by a super-majority (more than three-quarters) of the Council and a two-thirds approval of the Technical Committee, then a piece of legislation may be fast-tracked. Here, it is put to vote in the Referendum chamber immediately, with a far shorter voting period to normal (3 days) and a near zero enactment period. The approval mechanics in this case are unchanged from what they would be otherwise (either a simple majority or, in the case of a unanimous council, then a default-carry). This mechanism is expected to suffice for non-contentious bug-fixes and technical upgrades, but given the requirement of the Technical Committee’s approval, may not be effective in the case of emergencies that have a tinge of political sensitivity or strategic importance to them.
Treasury
In addition to legislation, Kusama’s governance apparatus includes the Treasury. The treasury is a pot of KSMs filled through transaction fees, slashing, inefficiencies in Kusama’s staking set (i.e. anything left over from the 10% inflation that is not rewarded) and lost deposits. The purpose of these funds, broadly, is for the benefit of the Kusama network.
Precisely how they should be deployed is something for the community to decide and make its expectations known. These expectations may be enforced through the selection of council members by KSM holders. Spending suggestions may be presented by anyone, with a 5% non-returnable deposit on the amount to be spent. These are then approved or rejected by the council. Those that are approved move into a queue and every 24 days (the budget period), as many spending proposals are drained from the queue as the treasury can afford to fund. If there are insufficient approved spending proposals to spend the treasury funds, then a small portion of the remaining treasury funds is burned, creating a slight deflationary pressure.
The sorts of things we can imagine spending proposals covering include:
- infrastructure deployment and continued operation;
- network security operations (monitoring services, continuous auditing, …);
- ecosystem provisions (collaborations with friendly chains, …);
- marketing activities (advertising, paid features, collaborations);
- community events and outreach (meetups, Kusama pizza-parties, hack-spaces);
- software development (wallets and wallet integration, clients and client upgrades, …);
However, this is ultimately controlled by the Kusama stakeholders and it will be that group and their collective imagination and judgement which really determines the course of the treasury.
Post-Genesis Governance
Two additional governance mechanisms are planned to be added to Kusama after launch (and to Polkadot’s main-net at Genesis, if the trials go well). One is the Oracle Committee, the other is Spontaneous Subject Committees.
Oracle Committee
The Oracle Committee is a group, not unlike the Technical Committee, whose membership is controlled by the members themselves according to a set of natural-language rules a bit like a constitution. Unlike the Technical Committee, the members of the Oracle Committee are asked, and paid, to vote explicitly. They are expected to evaluate statements designed to be objectively true or false and provide an according answer. As a principle, they are never expected to use judgement or opinion of any sort.
Their membership is dictated through objective criteria broadly designed to maximise their chances of voting honestly and identities remain secret until the individuals leave the committee.
Spontaneous Subject Committees
Spontaneous subject committees are designed to be a more agile way of capturing stakeholder sentiment that can be used in tandem with the existing tricameral structure in order to optimise the legislative flow. Essentially, it uses progressively increasing, statistically significant random sampling of the stake-weighted voting population in order to determine the chance of either a rejection or a landslide referendum approval. The randomly sampled voters are compensated for their votes, and turnout is taken into account. If rejection or approval is determined with sufficient confidence, then the proposal may be dropped or fast-tracked freeing up the pipeline for other, more contentious legislation.
Learn more
To learn more about Kusama, head to the Kusama network website for further information and links
