This guide will focus exclusively on the Web3 Foundation canary network, Kusama. While there are numerous similarities to the Polkadot network, several key factors in terms of metrics are different. For those interested in Polkadot staking details please refer back to our Help Center at a later date once the Polkadot network mainnet is launched.
In this guide we will standardize some of the language across Kusama's protocol and relate it to our app’s specific staking language.
Also, from here on out:
Nominators = Token Holders
Nominating = Staking
Kusama is a NPoS (Nominated Proof-of-Stake) canary network blockchain developed by the Web3 Foundation, with a native token called KSM. A KSM holder is able to receive rewards in KSM over time through staking. To encourage KSM stakers to diversify who they delegate to, they can pick up to 16 different validators to distribute their stake to.
As with most other POS blockchain networks, validators assume the role of producing new blocks and guaranteeing finality, so understanding a bit about how this works will be helpful to any user looking to participate in staking on the Kusama network.
Creating and Importing Accounts
Users who create their Kusama addresses using the Lunie app suite will be given a 24 word seed phrase which is unique to Lunie and will restore the account from any Lunie app.
Depending on where you have your KSM’s stored, whether from the token sale or bought from an exchange, you will be able to import existing Kusama accounts into Lunie via several import options. For simplicity-sake, Lunie gives users the ability to import their Kusama accounts in a few different ways.
- 24 word seed phrase
- 12 word seed phrase
- A raw private seed (only the schnorrkel type exported from Polkadot.js)
Within the Kusama protocol, there are more advanced options to manage staking with one’s keys, however Lunie has abstracted away some of this complexity in the first integration. This allows users to stake and participate in governance only from their single Kusama address, rather than having separate addresses for various purposes like having one for voting and one for staking.
Specifically regarding account types, there are two different accounts from a protocol level for managing funds in Kusama:
Stash accounts hold funds bonded for staking, but delegate some functionality to a Controller account. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time.
Controller accounts are able to act on behalf of the Stash account, signalling decisions about nominating and validating.
When using Lunie-originated Kusama account, both the stash and controller account will be the same.
To learn more about how Lunie recommends users think about and manage their keys, please read our keys management guide on it in our knowledge base.
Lunie offers an easy to browse list of Kusama validators with high level information about their past performance in the network as well as estimated rewards.
Rewards are recorded per session, or every four hours on Kusama. Payments are made per day, or every 4 eras, minus commissions charged by validators. Commissions are set at their own discretion and publicly advertised on the Lunie platform for token holders to evaluate.
Lock-Up Periods, Selecting Validators and Staking KSM
KSM staked to validators are “locked” and cannot be used for other purposes. You can receive new KSMs in your account but you cannot transfer KSM away from your account. If you wish to un-stake or “un-lock” KSM from a validator, they will continue to be unavailable for use for about 7 days, or 28 eras. In Kusama, each era is about 6 hours and there are approximately 4 eras per day.
When picking validators for consideration, a token holder only chooses which ones he wants to stake with, but not the specific amounts of KSMs allocated to each validator. This is chosen by the Kusama network phragmen algorithm. When tokens are locked up with a specific set of validators chosen, the set of validators will remain the same as long as those funds are locked up. The only way to alter the validator set is to unlock the staked funds entirely, wait the full un-locking period and then re-stake with an updated validator set.
While funds cannot be withdrawn from locked up KSM without going through the unlocking period, funds can be added to the locked balance and staked to validators.
For example: if token holders stake 10 KSM to 2 validators (A and B), a fraction of the 10 KSM will be staked in validator A and the rest in validator B.
As with other networks such as Cosmos, the Kusama blockchain uses slashing as a penalty against validators who are not available 24/7 or who behave badly through malicious behavior on the network. If a validator is slashed, the stake of KSM that are staked to them will also be slashed in proportion.
On Kusama slashes are percentage-based, which means that validators who have more stake delegated to them will lose more. For example, if a validator has 100,000 KSM delegated to them and they get slashed 5%, they have just lost 5,000 KSM. If a validator has 1,000 KSM and gets slashed 5% for the same offense, they lost 50 KSM. Token holders are affected the same way in regards to the locked-up KSM they have staked to a validator.
Validator responsiveness is punished if multiple validators (>= 10% of the active set) are offline at the same time.
Double-signing is always punished.
The higher the percentage of validators caught engaging in the same behavior behavior, the higher the likelihood of an attack on the network, and therefore the higher the percentage of slashing.
For example, for non-responsiveness, slashing can range from 0% ( < 10% offline) up to 7%. It climbs to ~ 43% offline (e.g., if 15% validators are offline, they will be slashed ~ 1%, if 20% are offline, then they are slashed ~ 2%, etc.)
Please note that Lunie is not a validator on Kusama or any other Proof of Stake blockchain - therefor we have no objective benefit to recommend one validator service over another - we simply offer the clearest indicators possible of what a validator’s performance and current status is and the rest of the judgement will fall on the user. As always, we are happy to field any questions you might have about this process and are open to feedback.