Overview of Kusama Network
What is Kusama ?
Kusama is Polkadot’s canary Network. The name canary comes from the idea of canaries that were used in coal mines to give warning to miners by detecting carbon monoxide and other toxic gases that could hurt them. Similarly, Kusama acts as a canary by warning and helping detect any kind of vulnerabilities or weaknesses in the polkadot code base.
Kusama is based on the same code as polkadot, however it’s a very early unaudited release. Kusama is more than just a testnet because it’s intended to be a test bed for new features as more of them get implemented in polkadot through first landing on Kusama. Once people have gotten a chance to experiment with those new features in Kusama, and everything looks fine, they will eventually move over to polkadot.
If you’re familiar with the litecoin bitcoin dynamic where litecoin is kind of a lower value and kind of intended to be a more experimental network than Bitcoin which moves a lot slower you can think of Kusama being as litecoin and Polkadot as Bitcoin.
Kusama is not a Testnet. It is more than a testnet as testnets are usually only playgrounds where tokens have no value. Being a canary network focused on research and development and a testbed to polkadot, KSMs are certainly of lower value, but still have some.
Kusama Timeline
In July 2019, DOT indicator token holders were able to claim their KSM by making an ethereum transaction that allowed them to be in Kusama’s genesis block. You can follow this guide if you have not claimed your KSM yet.
A month and a half later, Kusama launched with proof of authority, as the only validators which were allowed to generate blocks were those run by parity and the web 3 foundation, and the only functionality that was available at that time was to allow potential validators to signal their intention to validate.
After a couple months of chaos as it was expected, Kusama finally transitioned to POS. There are currently 130 validators on Kusama. Governance is; as the time of writing, on the hand of the KSM holders. Sudo which was a kind of central Super user that was holding the final say for any kind of governance decision on Kusama have relinquished its power and governance have fully transitioned to the KSM holders. As an example of this governance, there was a referenda which was being voted by KSM holders on increasing the number of validator to 150. After some time left for voting KSM holders decided to vote against the referenda.
Kusama future
In Kusama there is no Kill switch meaning that there is no central authority that can stop it. The only way the network could come to an end is through governance, if KSM holders decide to end the network, which is very unlikely to happen.In the future, Kusama could potentially connect to polkadot via a bridge or as hierarchical sub relay chain.
How to get KSM
There are several ways to get KSMs:
- DOT indicator token holder: Kusama is willing to be aligned with the existing DOT holders and community. For this reason anyone who has participated in the DOT sale and has received DOT indicator token is entitled to an equivalent amount of KSM on the Kusama network. You can follow this guide in order to claim your KSM.
- Faucet: Anyone can also get KSM through a frictional proof of work faucet. There are however some requirements that should be fulfilled in order to use it. One of them is to own a GitHub account that was created before 21 June 2019. If this is your case you should then get a KSM address that contains the string “ksma”. There are two ways for generating the address and its whether via Subkey or PolkadotJS Dashboard. Note that this address can only be used once to claim KSM and each Github account can only use the faucet once each 24hours. More information can be found here.
- Grants from web3 foundation: There are some other ways to obtain larger KSM than through the faucet and this is for Builders or governance participants who can apply for a grant from web 3 foundation.
- Bug bounty program: if someone is able to discover an unknown vulnerability in Kusama he will then get rewarded for it with KSMs thanks to the Bug bounty program.
Roles on Kusama
There are several ways to participate on Kusama network by either being a builder, maintainer or an end user.
Builders
The first role we are going to talk about concerns developers and development teams. Their role would be to build parachains, parathreads, bridges or block explorers. There are some reasons why developers and development team should consider building on kusama. As we already mentioned kusama has the same code base as Polkadot, so if they build their applications on Kusama, they would have nearly the same experience when they will build it in polkadot. Also, deploying a parachain in Kusama would be way cheaper than in polkadot, as acquiring parachain slots will probably be a lot cheaper in kusama than in Polkadot. So for new parachains ;that are still in an early phase, and need to be deployed to polkadot , it would make sense for teams and developers to first deploy them in Kusama before Polkadot.
Network Maintainers
Be it Kusama or Polkadot networks, a set of actors are helping to maintain them. Those are validators, nominators, collators, and governance actors.
Nominators’ role is to choose good and reputable validators and stake KSM. You can refer to our guide on how to nominate in Kusama for a step by step walkthrough the process.
Collators’ role is to maintain parachains by collecting parachain transactions from users and producing state transition proofs for validators.
Validators are also maintaining the network and are responsible to add new blocks, and to participate in consensus with other validators. They are staking tokens at the risk of being slashed but they also earn rewards for performing their validation duties.
Governance actors: this role implies participating on how kusama evolves, what direction it will take, and what it will turn into. Improvements and changes to Kusama code base can be introduced through proposals that can be submitted by anyone as long as a minimum amount of KSM is deposited for that purpose. Three main branches take part on this governance process:
- Referendum chamber: Its represents all KSM holders. KSM holders can propose public referendum, prioritize a public referendum, vote on an active referendum, vote for council members or apply to become a council member.
- Council: There are actually 13 members/accounts elected through approval voting in the council, and they represent the passive members of Kusama. Every two weeks there is a vote on council. The role of the council consists of electing technical committee members, Vetoing a referendum, proposing a referendum in 1 out of 2 launch periods, fast tracking a referendum along with technical committee when a critical one needs to be passed quickly.
- Technical committee: elected by the council. Includes dev teams that have successfully implemented or specified either Polkadot/Kusama runtime or the runtime environment. The role of the technical committee is to evaluate whether a proposal is urgent or not and then decide to fast track it along with the council. That way critical upgrades gets implemented first.
Overview of Kusama Governance
The starting point of the governance process can be a public proposal, a council proposal, or an emergency proposal submitted by the technical committee (has to be approved by the council) in order to make a change to the protocol.
The main aspect of kusama governance is the referendum, which allows KSM holders to vote on changing the chain. Any referendum holds a proposal that is designed to propose a concrete change to the chain. Example of proposals can include; among others, changing blockchain parameters (e.g slashing penalties), registering/deregistering a parachain, changing runtime code, canceling a referenda, or funding a project from treasury.
Once a proposal is made it has to become a referendum. Every launch period which is equivalent to 28 days, the proposal backed with most stake becomes a referendum. This is alternatively done among public and council proposals. In other words, each launch period will be specific to either select the most backed public or council proposal to become a referendum.
Once it becomes a referendum anyone with a stake (KSM holders) can vote (stake-weighted vote) for or against it. Once a referendum is passed, it will enact 30 days later.
When a public referendum is issued the vote has a positive turnout bias which means that it is biased towards not passing. On the other hand, when a council referendum is issued and when the vote on the proposal was unanimous the referendum will have a negative turnout bias meaning that it will be biased to pass. This is where the true power of the council resides. In case of a majority vote of the council for a proposal the final vote will have a majority carries. If a council proposal does not attain the majority among councillors, then it will never become a referendum.
For further explanation you can refer to Adaptive Quorum Biasing.
Treasury
The treasury hold funds that come from slashing, inefficiencies from staking system, lost deposits and transaction fees. To make a spending proposal any KSM holder should bond 5% of the spend (amount of KSM he wants to get from the treasury). In order to go through, a spending proposal needs to get 60% approval from the council. In that case the funds will be sent to the beneficiary address. If the spending proposal gets less than 50 % approval from the council, the reserved funds would be slashed. This process is done for each spending period which is 6 days.
Parachains
Parachain — parallelizable chain — is a simpler form of blockchain, which attaches to the security provided by the “relay chain” rather than providing its own. It is validatable by the validators of the relay chain. Parachain will require a parachain slot which will be acquirable by auctions. It is maintained by collators whose role is to maintain a full-node of the parachain, retain all its necessary information, and produce new blocks to pass to the relay chain validators for verification and inclusion in the shared state of Kusama.
Parathreads
Parachain and parathreads are very similar from a technological point of view. A parachain can become at some point a parathread and vice versa. The difference between them is rather economic. A parachain will need to acquire a slot through auction while parathreads have a fixed fee to pay for registration which would be much lower than the cost of acquiring a parachain slot. However, this fee will only guarantee the registration of the parathread code. As parathreads progress and produce new blocks, they will be a fee associated to include newly generated blocks in the relay chain, which will take the form of a block auction; competing with other registered parathreads.
You can support us by voting on InchainWorks on Kusama network. Our address is : DbAdiLJQDFzLyaLsoFCzrpBLuaBXXqQKdpewUSxqiWJadmp
You can also follow our step by step guide to nominate on Kusama network
