recently we’ve noticed that our fee calculation related parameters on
Astar aren’t configured properly. Some things need to be changed and this will have an impact on all our users. Before we do any changes however, we will describe the problem(s) here and the proposed solution.
Shiden’s fee model is based on Polkadot’s tokenomics research (here). If you are looking for a more in-depth understanding of the fee model, then you are encouraged to read through that paper.
Shiden use basically the same underlying tehcnology, with
Shiden being more cutting edge than
Astar. However, they are configured directly. An easy to understand example is that on
Shiden, the unbonding period for dApps staking is 5 eras while for
Astar it is 10 eras.
At the genesis block,
Shiden had the initial total issuance of 70 million SDN. When
Astar was being launched, it was decided to increase
Astar’s total issuance by 100x, making it 7 billion ASTR. If you participated in crowdloan or lockdrop, you might remember this - your rewards were scaled up by a factor of 100x.
The 100x factor was also applied to
Astar’s inflation, making block reward (how much new ASTR is issued in each block) 100x higher when compared to
Shiden (this has recently been slightly adjusted but the difference in scale is still very close to 100x).
Unfortunately, this change wasn’t properly propagated to all aspects of the fee calculation.
The focus of this post will only be on rent fees though.
The rent fee is charged for certain calls which end up creating new database entries.
For example, let’s say you propose a new
multisig call. Some information has to be stored on-chain so that other signatories can check it (e.g. compare the call hash to the call you shared with them) and, if they want, to confirm it & execute it.
Once the call has been executed, it’s no longer important to keep this history in the database so it’s deleted (you can still access it via archive node by checking state at old blocks).
To prevent someone from creating tons of database entries and thus bloating the database, some storage rent fees need to be paid when an DB entry is created. This is called the rent fee. Once the storage has been cleaned up, the rent is returned back to the user (a bit different from how it works for renting places ).
E.g. if you initiate a
multisig call, X amount of
ASTR will be reserved. Once the call has been executed or canceled, the X amount is unreserved and returned to you.
There are two problems with
- The rent fee is way too low. If you execute the aforementioned
Polkadot, around 20 DOTs will be reserved. If you do the same call on
Shiden, only around 0.0000002 ASTR or SDN will be reserved.
- The rent fee is same on
Shiden, it doesn’t account for the 100x higher initial total supply and block reward.
The solution to the 1st problem is to introduce an improved formula for calculating rent fees.
astar_rent_fee = 100 ASTR * number_of_db_entries + 0.01 ASTR * number_of_bytes
shiden_rent_fee = 1 SDN * number_of_db_entries + 0.0001 SDN * number_of_bytes
With the previous example, storage rent for
multisig would now be around 100 ASTR or 1 SDN, make it more comparable to
Since creating a new asset on both
Astar is incredibly cheap, we will increase this to:
10 SDN on
1000 ASTR on
Please keep in mind this is also rent fee.
Most of the end user won’t feel this too much since they don’t use functionality like
multisig or creating new assets (this is done quite seldom).
Feel free to share your thoughts and opinions!