|
2 | 2 | sidebar_position: 2 |
3 | 3 | --- |
4 | 4 |
|
5 | | -## Hybdrid Inflation model |
| 5 | +Astar has a soft-capped 'yearly' inflation and uncapped max supply. |
| 6 | +Inflation is distributed amongst actors in the network, in varying proportions. |
| 7 | +Actors include: |
| 8 | +* stakers |
| 9 | +* dApp owners |
| 10 | +* collators |
| 11 | +* treasury |
6 | 12 |
|
7 | | -The new inflation model will be preceded by an intermediate phase known as the hybrid inflation model. This transitional phase encompasses these modifications: |
8 | 13 |
|
9 | | -### Inflation Adjustment |
| 14 | +## Basic Time Units |
10 | 15 |
|
11 | | -Inflation rates have been lowered. The maximum token reward per block, reached based on the optimal staking rate or staking TVL (Total Value Locked), has been reduced from 253.08 to 231.20. Please note that this is temporary until the next phase of Tokenomics 2.0 coming with dApp Staking v3. |
| 16 | +### Cycles |
| 17 | +**Cycle** can be considered as a 'year' in the Astar Network. |
| 18 | +When a new cycle starts, new inflation configuration is calculated according to the total issuance at that point in time. |
| 19 | +E.g. if 'yearly' inflation is set to be 7%, and total issuance is 1,000,000 ASTR, then the soft-capped max inflation for that |
| 20 | +cycle will be 70,000 ASTR. |
12 | 21 |
|
13 | | -### Treasury rewards |
| 22 | +Cycle length is configurable, but in practice it will resemble a 'year' off-chain. |
14 | 23 |
|
15 | | -The dynamic treasury allocation has been removed in favor of a fixed annual inflation rate of 5%. Which correspond to a reward of 11.06 ASTR per block. |
| 24 | + $inflation\_soft\_cap = inflation\_rate * total\_issuance$ |
16 | 25 |
|
17 | | -### Collators rewards |
| 26 | +### Periods |
18 | 27 |
|
19 | | -Collators will now receive a steady 3.2% of the annual inflation which correspond to a reward of 7.07 ASTR per block. Although this represents a reduction from the previous model, the upcoming alignment of EVM fees and Substrate native fees is expected to increase overall fee earnings for collators. |
| 28 | +Each **cycle** consists of one or more **periods**. |
| 29 | +**Periods** are a core time unit in the dApp Staking protocol. Each period consists of a `Voting` and `Build&Earn` subperiods. |
20 | 30 |
|
21 | | -### Stakers & dApp Rewards |
| 31 | +During the `Voting` subperiod, neither stakers nor dApp owners can earn any rewards, only _collators_ and _treasury_ continue earning. |
| 32 | +During the the `Build&Earn` subperiod, stakers earn staking rewards per **era** and have the opportunity to earn bonus reward at the end of a period. |
| 33 | +dApp owners also earn rewards, based on how well their dApp is performing in dApp staking, at the end of each **era**. |
22 | 34 |
|
23 | | -The rewards for dApp staking, both for users and dApps, will remain unchanged in absolute terms. No immediate modifications will be implemented in this area. Future updates, including the introduction of dApp staking v3, will occur in the third phase of Tokenomics 2.0. |
| 35 | +### Eras |
24 | 36 |
|
25 | | -We use the blockReward distribution to ensure those three requirements (and calculate them from the reward per block): |
| 37 | +Each **period** is divided up into multiple **eras**. |
| 38 | +**Era** is the core time unit in dApp staking, and its length is measured in the number of blocks. |
26 | 39 |
|
27 | | -| | Percentage | Reward ASTR | |
28 | | -|------------------|------------|-------------| |
29 | | -| Block reward | 100% | 231.20 | |
30 | | -| Treasury | 4.78% | 11.06 | |
31 | | -| Collators | 3.06% | 7.07 | |
32 | | -| dApp reward | 17.27% | 39.93 | |
33 | | -| Base Staker | 23.04% | 53.27 | |
34 | | -| Ajustable Staker | 51.84% | 119.85 | |
| 40 | +`BuildAndEarn` subperiod consists of one or more _standard_ **eras**. Each era has a fixed length. |
| 41 | +`Voting` subperiod always consists of exactly **one era** and this _voting_ era is unique as its length (in blocks) can be longer than a _standard_ era length (but always a multiple of _standard_ era length). |
| 42 | + |
| 43 | +### Example |
| 44 | + |
| 45 | +* Block is produced every 12 seconds |
| 46 | +* **Era length** is 7200 blocks which equals 24 hours (1 day) (This is _standard_ era length) |
| 47 | +* `Voting` subperiod length is 10 eras (This is the single _voting_ era which lasts 10 x 7700 blocks) |
| 48 | +* `Build&Earn` subperiod length is 81 eras |
| 49 | +* Cycle length is **4 periods** |
| 50 | + |
| 51 | +With such configuration, we'd end up with a cycle lasting 364 days (roughly a year), and each period taking around 3 months to complete. |
| 52 | + |
| 53 | +## Recalculation |
| 54 | + |
| 55 | +When a new cycle begins, soft-inflation cap is recalculated, and according to the calculated value, rewards for all network actors are adjusted. |
| 56 | + |
| 57 | +The reason why it's a _soft-cap_, instead of a _hard-cap_ is how staker & dApp rewards are distributed. |
| 58 | +Rewards are only minted when they are claimed, and it is possible that at the time of reward recalculation, some rewards remain unclaimed. |
| 59 | +As a result, theoretically, it's possible for the cycle inflation to exceed the _soft-cap_ even though in practice it will be highly unlikely |
| 60 | +due to _lazy minting_ & _fee burn_ mechanisms. |
| 61 | + |
| 62 | +## Inflation Distribution |
| 63 | + |
| 64 | +Based on the calculated _soft-cap_, rewards for all network participants are adjusted. |
| 65 | + |
| 66 | +### Collators |
| 67 | + |
| 68 | +_Collators_ get a fixed amount of the cycle's _soft-capped_ inflation. |
| 69 | +This amount is equally divided by the number of blocks in the cycle. |
| 70 | + |
| 71 | +$collator\_reward\_per\_block = \frac{total\_collator\_cycle\_reward}{blocks\_per\_cycle}$ |
| 72 | + |
| 73 | +### Treasury |
| 74 | + |
| 75 | +Similar to the _collators_, treasury gets a fixed amount of the cycle's _soft-capped_ inflation |
| 76 | +distributed in equal amounts throughout all the blocks in the cycle. |
| 77 | + |
| 78 | +$treasury\_reward\_per\_block = \frac{total\_treasury\_cycle\_reward}{blocks\_per\_cycle}$ |
| 79 | + |
| 80 | +### dApps |
| 81 | + |
| 82 | +dApp reward are _assigned_ at the end of each era during `Build&Earn` subperiod. |
| 83 | +This means that the total cycle's dApp reward amount has to be equally divided by the total number of `Build&Earn` eras in a cycle. |
| 84 | + |
| 85 | +$dapp\_reward\_pool\_per\_era = \frac{total\_dapp\_cycle\_reward}{periods\_per\_cycle * eras\_per\_build\_and\_earn}$ |
| 86 | + |
| 87 | +The dApp staking protocol will calculate how much each staked dApp should get. |
| 88 | + |
| 89 | +### Stakers |
| 90 | + |
| 91 | +There are two components to the staker rewards - regular _staking_ rewards & the _bonus_ reward for loyal stakers. |
| 92 | + |
| 93 | +#### Regular Staker Rewards |
| 94 | + |
| 95 | +Regular staker rewards are awarded for staking native currency, **ASTR**, on a dApp. |
| 96 | +These rewards have two components - the _base_ reward and the _adjustable_ reward. |
| 97 | + |
| 98 | +Base reward is the amount assigned to the reward pool at the end of each era regardless of how much has been staked in total. |
| 99 | + |
| 100 | +$base\_staker\_reward\_pool\_per\_era = \frac{total\_base\_staker\_cycle\_reward}{number\_of\_cycles * eras\_per\_build\_and\_earn}$ |
| 101 | + |
| 102 | +The adjustable part is the dynamic part, and depends on the _total value staked_ and the _target stake value_. |
| 103 | +This amount linearly increases as the _total value staked_ increases, and then saturates once the amount is reached or exceeded. |
| 104 | +With this component, _staker rewards_ are not a _zero-sum game_. |
| 105 | + |
| 106 | +$max_\_adjustable\_staker\_reward\_pool\_per\_era = \frac{total\_adjustable\_staker\_cycle\_reward}{number\_of\_cycles * eras\_per\_build\_and\_earn}$ |
| 107 | + |
| 108 | +The adjustable part of the reward is calculated once an era ends, using the _total value staked_ at that point in time. |
| 109 | + |
| 110 | +$adjustable\_factor = min(1, \frac{total\_value\_staked\_percent}{ideal\_staking\_percent})$ |
| 111 | + |
| 112 | +Using the _adjustable\_factor_, adjustable portion of the staker reward is: |
| 113 | + |
| 114 | +$adjustable\_staker\_reward\_pool = max_\_adjustable\_staker\_reward\_pool\_per\_era * adjustable\_factor$ |
| 115 | + |
| 116 | +When the _adjustable factor_ is less than **1**, it means the remainder is never minted, reducing the overall inflation. |
| 117 | + |
| 118 | +With the above formulas, we can finally express how much staker _Alice_ earns in era **n**: |
| 119 | + |
| 120 | +$staker\_reward\_per\_era_{Alice} = \frac{staked\_value_{Alice,n}}{total\_staked\_value_n} * (base\_staker\_reward\_pool\_per\_era_n + adjustable\_staker\_reward\_pool_n)$ |
| 121 | + |
| 122 | +#### Bonus Rewards |
| 123 | + |
| 124 | +In case a staker stakes during the `Voting` subperiod, and doesn't reduce their stake during the `Build&Earn` subperiod below what |
| 125 | +was staked at the end of the `Voting` subperiod, it will make them eligible for the bonus reward. |
| 126 | + |
| 127 | +Bonus reward pool is assigned per period, and can be expressed as: |
| 128 | + |
| 129 | +$bonus\_reward\_pool\_per\_period = \frac{total\_bonus\_cycle\_reward}{periods\_per\_cycle}$ |
| 130 | + |
| 131 | +The bonus reward for a staker _Alice_ can then be expressed as: |
| 132 | + |
| 133 | +$bonus\_staker\_reward_{Alice} = \frac{voting\_subperiod\_staked\_value_{Alice}}{total\_voting\_subperiod\_staked\_value} * (bonus\_reward\_pool\_per\_period)$ |
| 134 | + |
| 135 | +## Lazy Minting |
| 136 | + |
| 137 | +Both _staker_ and _dApp_ rewards are minted in a lazy fashion - when they are needed. Only collator & treasury rewards are minted per block. |
| 138 | + |
| 139 | +With the _adjustable staker reward_ and the dApp staking tier system, the inflation in practice will be much lower than the calculated _soft-cap_. |
| 140 | +Maximum adjustable award amounts is possible only if the ideal staking rate is reached or exceeded. |
| 141 | +For the dApp rewards, it's unlikely that all of the tiers will be filled with dApps - it might be that the tier capacity is larger than the demand, |
| 142 | +or that simply some dApps don't attract enough support to enter a tier. These rewards will never be even minted thus lowering the effective inflation rate. |
| 143 | + |
| 144 | +Rewards don't persist forever, and must be claimed before they _expire_. |
| 145 | +Although this is expected to be very lenient, it's still possible to happen. |
| 146 | + |
| 147 | +None of the aforementioned mechanism are _burn_ mechanisms, instead they just delay the _minting_ operation until it's needed. |
| 148 | +The major burn mechanism is part of the fee system, where a significant portion of fees get burned. |
| 149 | +Only due to this, it's practically impossible for the _soft-capped max inflation_ to be reached when considering rewards assigned & issued during |
| 150 | +a single cycle. |
| 151 | + |
| 152 | +## Parameters |
| 153 | + |
| 154 | +| | Shibuya | |
| 155 | +|--------------------------|---------------| |
| 156 | +| Periods Per Cycle | 2 | |
| 157 | +| Eras Per Voting Subperiod| 8 | |
| 158 | +| Eras Per Build&Earn Subperiod | 20 | |
| 159 | +| Blocks Per Era | 1800 (~6 hours) | |
| 160 | +| Cycle Inflation Rate | 1% | |
| 161 | +| Treasury Part | 5% | |
| 162 | +| Collators Part | 3% | |
| 163 | +| dApps Part | 20% | |
| 164 | +| Base Staker Part | 25% | |
| 165 | +| Adjustable Staker Part | 35% | |
| 166 | +| Bonus Part | 12% | |
| 167 | +| Ideal Staking Rate | 20% | |
0 commit comments