AISLAND DECENTRALIZED BLOCKCHAIN
Staking
Aisland uses NPoS (Nominated Proof-of-Stake) as its consensus mechanism. The system encourages AISL token holders to participate as nominators.How does staking work?
In staking, you can be either a nominator or a validator.
As a nominator, you can nominate validator candidates that you trust to help you earn rewards in the chain's native token.
The earned rewards can be bonded (locked) immediately for staking on your account, which would effectively compound the rewards you receive over time.
You could also choose to have them deposited to your account or a different account as free (transferable) balance.
You can take a look at the nominator guide to understand your responsibilities as a nominator, and the validator docs to understand what you need to do as a validator.
Staking System Overview
Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of up to 16 candidates that it supports. In the next era, a certain number of validators having the most DOT backing get elected and become active. As a nominator, a minimum of 10 DOT is required to submit an intention to nominate. The nomination intents are placed in a semi-sorted list.
Once again, submitting a nomination intent does not guarantee staking rewards. The stake of the top 22,500 nominators is applied to the validators in the active set. To avail staking rewards, ensure that the number of tokens bonded is higher than the minimum active nomination. For more information, check the nominator guide.
Staking Rewards Distribution
To explain how rewards are paid to validators and nominators, we need to consider validator pools. A validator pool consists of the stake of an elected validator together with the nominators backing it.
If a nominator n with stake s backs several elected validators, say k, the NPoS election mechanism will split its stakes into pieces s_1, s_2, …, s_k, so that it backs validator i with stake s_i. In that case, nominator n will be rewarded essentially the same as if there were k nominators in different pools, each backing a single validator i with stake s_i.
For each validator pool, the blockchain keeps a list of nominators with the associated stakes.
The general rule for rewards across validator pools is that two validator pools get paid essentially the same amount of tokens for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards but this should average out over time.
Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid pro-rata (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. If a validator's commission is set to 100%, no tokens will be paid out to any nominations in the validator pool.
Rewards Mechanism
We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-token than pools with more stake.
We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators.
In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more).
We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount), which means that validator pools with more stake get slashed more ASL. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy.
The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more, or decreasing their fees to attract more nominators and increase their chances of being elected. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair).
Accounts
There are two different accounts for managing your funds: Stash and Controller.
- Stash: This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in governance proposals.
- Controller This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It sets preferences like payout account and commission. If you are a validator, it also sets your session keys. It only needs enough funds to pay transaction fees.
We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular.
Controller and Stash account keys can be either sr25519 or ed25519.
Validators and Nominators
Since validator slots are limited, most of those who wish to stake their AILS and contribute economic security to the network will be nominators.
Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA and validate the state transition.
Nominators, on the other hand, have far fewer responsibilities. Those include monitoring their validators' performance (uptime), keeping an eye on changing commission rates (a validator can change commission at any time), and general health monitoring of their and their validators' account. Thus, while not set-it-and-forget-it, a nominator's experience is relatively hands-off compared to a validators.
Slashing
Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked AISL.
Any slashed AISL will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process.
Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce their possible losses.
It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards.
As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected.
In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the Phragmén algorithm.
Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via Polkadot-JS Apps. The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period ( 7 days). After the grace period, the slashes are applied.
The following levels of offence are defined, however, these particular levels are not implemented or referred to in the code or in the system; they are meant as guidelines for different levels of severity for offences. To understand how slash amounts are calculated, see the equations in the section below.
- Level 1: isolated unresponsiveness, i.e. being offline for an entire epoch. Generally no slashing, only chilling.
- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills.
- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in GRANDPA protocol. Slashes a moderately small amount of the stake and chills.
- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills.
Claiming Rewards
You go to the Staking payouts page on Polkadot-JS, you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still have received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era.
If you wish to check if you received a payout, you will have to check via a block explorer.
Rewards Distribution Example
PER_ERA * BLOCK_TIME = **Reward Distribution Time**
3_600 * 6 seconds = 21_600 s = 6 hours
Validators can create a cut of the reward (a commission) that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the commission gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator.
For example, assume the block reward for a validator is 10 DOT. A validator may specify validator_commission = 50%, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator.
Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely unrelated account. By using the Extrinsics tab (Developer -> Extrinsics -> Staking -> Bond) you can also send rewards to "None", effectively burning them. It is also possible to top-up / withdraw some bonded DOT without having to un-stake all staked DOT.