dApp Staking v3 Technical Overview
Introduction
Astar and Shiden networks provide a unique way for developers to earn rewards by developing products that native token holders can decide to support.
The principle is simple - stakers lock their tokens to stake on a dApp, and if the dApp attracts enough support, it is rewarded in native currency, derived from the inflation. In turn stakers are rewarded for locking & staking their tokens.
The following chapters will provide an overview of the functionality and terminology with accompanying examples.
Functionality Overview
Eras
Eras are the basic time unit in dApp staking and their length is measured in the number of blocks.
Eras are not expected to last long, e.g. current production networks era length is roughly 1 day (7200 blocks). After an era ends, it's usually possible to claim rewards for it, if staker or dApp are eligible.
Periods
Periods are another time unit in dApp staking. They are expected to be more lengthy than eras. Each period is denoted by a number, e.g. 1, which increments each time a new period begins.
Each period consists of two subperiods:
Voting
Build&Earn
Period beginning is marked by the Voting
subperiod, after which follows the Build&Earn
subperiod.
Stakes are only valid throughout a period. When new period starts, all stakes are reset to zero. Protocol dynamic prevents inactive projects having high stakes due to inertia of stakers while at the same time allows more visibility for dApps joining the protocol and equal chance in attracting stakers' attention.
Even though stakes are reset, locks (or freezes) of tokens remain.
Voting Subperiod
When Voting
subperiod starts, all stakes are reset to zero.
Projects participating in dApp staking are expected to market themselves to (re)attract stakers.
Stakers must assess whether the project they want to stake on brings value to the ecosystem, and then vote
for it (or stake on it).
Casting a vote, or staking, during the Voting
subperiod makes the staker eligible for bonus rewards. so they are encouraged to participate during this time.
Voting
subperiod length is expressed in standard era lengths, even though the entire voting subperiod is treated as a single voting era.
E.g. if Voting
subperiod lasts for 5 eras, and each era lasts for 100 blocks, total length of the Voting
subperiod will be 500 blocks BUT it will consume only a single numeric era:
- Block 1, Era 1 starts, Period 1 starts,
Voting
subperiod starts - Block 501, Era 2 starts, Period 1 continues,
Build&Earn
subperiod starts
Neither stakers nor dApps earn rewards during the Voting
subperiod; rewards are only generated for eras in the Build&Earn
subperiod. However, as mentioned before, it’s crucial for dApps to use this time to market themselves and attract stakers, and for stakers to assess which projects they want to support.
It is important to award projects which the staker believes will bring value to the network and possibly themselves. Voting on a poor project means that poor performance is rewarded, damaging the network instead of improving it.
Build&Earn
Build&Earn
subperiod consists of one or more eras.
E.g. if Build&Earn
subperiod lasts for 10 eras, and each era lasts for 100 blocks, these 10 eras would consume 1000 blocks in total.
After each era ends, eligible stakers and dApps can claim the rewards they earned.
Rewards are only claimable for the finished eras. E.g. if the era 3 is ongoing, staker can claim rewards for era 2 if they were eligible.
Staker is only eligible for rewards if they have been staking for the entire era. E.g. if staker stakes in era 2, they are only eligible for rewards from era 3, which can be claimed from era 4 onwards.
Even though Build&Earn
comes after the Voting
, it is still possible to stake during this period, and stakers are encouraged to do so
since this will increase the staker rewards they earn.
The only exemption is the final era of the Build&Earn
subperiod - it's not possible to stake then since the stake would be invalid anyhow (stake is only valid from the next era which would be in the next period when all stakes are reset to zero).
To continue the previous example where era length is 100 blocks, let's assume that Build&Earn
subperiod lasts for 10 eras:
- Block 1, Era 1 starts, Period 1 starts,
Voting
subperiod starts - Block 501, Era 2 starts, Period 1 continues,
Build&Earn
subperiod starts - Block 601, Era 3 starts, Period 1 continues,
Build&Earn
subperiod continues - Block 701, Era 4 starts, Period 1 continues,
Build&Earn
subperiod continues - ...
- Block 1401, Era 11 starts, Period 1 continues,
Build&Earn
subperiod enters the final era - Block 1501, Era 12 starts, Period 2 starts,
Voting
subperiod starts - Block 2001, Era 13 starts, Period 2 continues,
Build&Earn
subperiod starts
dApps & Smart Contracts
Registration
Projects, or dApps, must be registered into protocol to participate. Only a privileged origin can perform dApp registration. At the moment of writing this, dApps & projects can request to be registered via Astar's forum.
Once the dApp has been registered, stakers can stake on it immediately, and it can earn rewards from the era in which it was registered.
There is a limit of how many smart contracts can be registered at once. Once the limit is reached, any additional attempt to register a new contract will fail. This puts an upper bound on how many contracts the protocol can support.
Reward Beneficiary & Ownership
After a dApp has been registered, it is possible to modify reward beneficiary or even the owner of the dApp. The owner can perform reward delegation and can further transfer ownership.
This is useful if dApp owners want to deposit rewards and/or transfer ownership to a DAO or a multisig account.
Unregistration
dApp can be removed from the protocol by unregistering it. This is an action that can only be done by a privileged origin. Unregistration can be the result of bad performance, reorganization or any other reason which governance decides it's viable.
After a dApp has been unregistered, it's no longer eligible to receive rewards. Past rewards also become unavailable, if they haven't been claimed already.
Stakers
Locking Tokens
In order for users to participate in dApp staking, the first step they need to take is lock (or freeze) some native currency. Reserved tokens cannot be locked, but tokens locked by another lock can be re-locked into dApp staking (double locked).
This is useful for vested tokens, which although cannot be transferred to another account, can still be used to participate in dApp staking.
Locked funds NEVER leave the staker's wallet - it's only not possible to use those funds for fee payment or for transfer.
In order to participate, user must have a MinimumLockedAmount
of native currency locked. This doesn't mean that they cannot lock less in a single call, but total locked amount must always be equal or greater than MinimumLockedAmount
.
E.g. if an account isn't participating in dApp staking and threshold is set to 10 ASTR, attempting to lock 9 ASTR will fail. However, if user already has 10 ASTR locked, they can safely lock an additional 1 ASTR, for **11 ASTR locked in total.
In case amount specified for locking is greater than what user has available, only what's available will be locked - it's not possible to lock more than what's available.
Once tokens have been locked, they can be used to stake immediately. Users should ensure to do so since locking doesn't bring any rewards, unless tokens are staked as well.
It's not possible to use the same account for dApp staking & as the collator candidate.
Unlocking Tokens
User can at any time decide to unlock their tokens. However, it's not possible to unlock tokens which are staked, so user has to unstake them first.
After unlock is successfully executed, the tokens aren't immediately unlocked, but instead must undergo the unlocking process. This process takes a predefined amount of blocks to finish. This is a well known & widely used mechanism to reduce selling pressure.
Once unlocking process has finished, user can claim their unlocked tokens into their free balance.
There is a limited number of unlocking chunks
a user can have at any point in time. If limit is reached, user must claim existing unlocked chunks, or wait for them to be unlocked before claiming them to free up space for new chunks. This mechanism exists simply to prevent users from creating unlimited amounts of chunks in storage.
In case unlocking some amount would take the user below the MinimumLockedAmount
, everything will be unlocked.
E.g. if minimum locked amount is set to 10 ASTR, user has 15 ASTR locked, and they decide tu unlock 6 ASTR, this would take them to 9 ASTR which is below threshold. As a result, all 15 ASTR will be unlocked.
In case users would like to re-lock the unlocking chunks back into the dApp staking protocol, they can easily do that, without having to wait for the unlocking process to finish.