Revising rent fee on Astar & Shiden

Economics
1

Hello everyone,

recently we’ve noticed that our fee calculation related parameters on Shiden & 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.

Overview

Astar & 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.

Both Astar & 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.

Rent Fee

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 :slightly_smiling_face:).

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.

Problem

There are two problems with Astar and Shiden:

  1. The rent fee is way too low. If you execute the aforementioned multisig call on Polkadot, around 20 DOTs will be reserved. If you do the same call on Astar or Shiden, only around 0.0000002 ASTR or SDN will be reserved.
  2. The rent fee is same on Astar and Shiden, it doesn’t account for the 100x higher initial total supply and block reward.

The Solution

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 Polkadot.

Additional Change

Since creating a new asset on both Shiden and Astar is incredibly cheap, we will increase this to:

  • 10 SDN on Shiden
  • 1000 ASTR on Astar

Please keep in mind this is also rent fee.

Summary

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!

7 Likes
2

I agree! This is helpful to avoid spam on the chain and save some memory on nodes storage for useless data.

3

This just makes sense to do it. Let’s make it happen.

1 Like
4

This hasn’t been merged yet since we were waiting for some other changes to be included in the code first (the PR is here for those who are interested).

But I’d like to bring something new to the discussion which I became aware of just recently.

The pallet-contracts module, which provides our runtimes with the capability to run WASM smart contracts, heavily relies on the rent fee. For each database entry a user creates, rent fee is charged. Once that DB entry is removed, the rent fee is returned.

So let’s consider a PSP22 smart contract (similar to Ethereum’s ERC20).
When Alice submits a transaction which results in a call to a PSP22 style smart contract, and a new database entry is created (e.g. how much Alice has of this PSP22 asset), some rent fee is charged from her.

I believe that the price of 100 ASTR would be too much for such operation. Psychologically, it’s a large amount to pay and it might discourage regular users from using WASM.

That being said, I’d like to modify my initial proposal to the following:

astar_rent_fee = 10 ASTR * number_of_db_entries + 0.01 ASTR * number_of_bytes

shiden_rent_fee = 0.1 SDN * number_of_db_entries + 0.0001 SDN * number_of_bytes

We’re open to comments and suggestions!

EDIT: For the sake of thread completeness, please find the used numbers here. We will also add better description of these numbers to the official docs.

5 Likes