Rent fee for asset creation (#578)

Author: Dinonard

docs/build/builder-guides/leverage_parachains/interact_with_xc20.md

@@ -46,6 +46,10 @@ Currently, the best way to create XC20 asset is via [Polkadot.js](https://polkad
         - **Note**:  We suggest setting the `minimum balance` to `1 Pico`, which will only require 0.000000000001 unit of the asset.
     - `asset id`: the selected id for the asset. This should not match an already-existing asset id.
 
+:::note
+Please make sure the account creating the asset has sufficient balance to pay the [rent fee](/docs/learn/tokenomics2/tokenomics2-network-fees.md#Rent_Fee).
+:::
+
 ![Untitled](mintable-xc20-cookbook/Untitled.png)
 
 - Set the managing addresses for the XC20 asset:

docs/learn/interoperability/xcm/building-with-xcm/create-xc20-assets.md

@@ -26,6 +26,10 @@ Before the asset's Metadata can be set, we will need to create an asset on the n
 6. When everything is filled in, click **Next** on the next screen.
 7. Set your **roles** and create the asset by signing with the creator account.
 
+:::note
+Please make sure the account creating the asset has sufficient balance to pay the [rent fee](/docs/learn/tokenomics2/tokenomics2-network-fees.md#Rent_Fee).
+:::
+
 ![Create your asset](img/5.png)
 ![Set roles](img/6.png)
 

docs/learn/tokenomics2/tokenomics2-network-fees.md

@@ -4,7 +4,6 @@ sidebar_position: 1
 
 import Figure from "/src/components/figure"
 
-
 # Fee Model
 
 Each block is a limited resource - it can only fit a limited amount of transactions. This is an oversimplification, but the point is that every transaction included in the block consumes a portion of the block’s resources.
@@ -13,11 +12,11 @@ Astar is a parachain in the Polkadot ecosystem, which relies on the shared secur
 
 As a simple example - consider a token transferred from **Alice** to **Bob**. If such a transaction consumes **0.001 seconds** of execution time, executing two such transactions in a single block would consume **0.002 seconds**. Calling a smart contract, e.g., a DEX swap, is much more resource intensive and may, for example, consume **0.01 seconds, or 100x that of a simple transfer from one account to another**.
 
-The other limiting factor is the __Proof of Validity__ (PoV) size. Since Polkadot validators provide security by validating blocks authored by parachain collators, they need access to the data required to validate the block. Expanding on the previous example with **Alice** and **Bob**, Astar would need to provide Polkadot validators with information about how many initial tokens ****Alice** and **Bob** had and the transaction itself. This is (almost) enough data for validators to work with, but it is strictly limited to only **5 MB (megabytes)** per block.
+The other limiting factor is the **Proof of Validity** (PoV) size. Since Polkadot validators provide security by validating blocks authored by parachain collators, they need access to the data required to validate the block. Expanding on the previous example with **Alice** and **Bob**, Astar would need to provide Polkadot validators with information about how many initial tokens \***\*Alice** and **Bob** had and the transaction itself. This is (almost) enough data for validators to work with, but it is strictly limited to only **5 MB (megabytes)** per block.
 
 In summary, there are two main factors limiting block production: `ref time` and `PoV size`, which taken all together, are collectively referred to as `weight`, an important concept when calculating transaction fees.
 
- <Figure caption="Block Consumption" src={require('/docs/learn/tokenomics2/img/Astar-Block-Consumption.jpeg').default } width="100%" /> 
+ <Figure caption="Block Consumption" src={require('/docs/learn/tokenomics2/img/Astar-Block-Consumption.jpeg').default } width="100%" />
 
 Transaction Fees on Astar comprise of Native (Substrate) and EVM fees. Native and EVM transaction fees are calculated in different ways. Tokenomics 2.0 aligns the fees calculation between the two systems so that transactions consuming the same amount of block resources are priced roughly the same regardless of transaction type (Native or EVM).
 
@@ -67,7 +66,6 @@ s &= \frac{block\_weight}{max\_block\_normal\_dispatch\_weight}
 \end{align}
 $$
 
-
 with several configuration parameters:
 
 - $s*$ - ideal block fullness; desired long term average block fullness.
@@ -77,15 +75,15 @@ with several configuration parameters:
 - $c_{max}$ - the largest possible value of fee multiplier $c$.
 
 and using $s$ to describe current block fullness:
+
 - If $s > s*$, meaning block fullness if **more** than the ideal, the adjustment will be a positive number.
 - If $s < s*$, meaning block fullness is **less** than the idea, the adjustment will be a negative number.
 
 Based on the network usage (congestion), factor $c$ will either increase or decrease from block to block. If network is used heavily and blocks are full, it will increase, scaling up the weight fee and thus making the transactions more expensive. If network congestion is below the ideal the fee multiplier will decrease, making transactions less expensive.
 
-
 ## EVM Fees
 
-Astar is fully Ethereum compatible. This means it also supports Ethereum’s [gas concept](https://ethereum.org/en/developers/docs/gas/). Gas is similar to weight but not quite the same. As a result, Ethereum transaction fees are calculated a bit differently. A simplified formula looks like this 
+Astar is fully Ethereum compatible. This means it also supports Ethereum’s [gas concept](https://ethereum.org/en/developers/docs/gas/). Gas is similar to weight but not quite the same. As a result, Ethereum transaction fees are calculated a bit differently. A simplified formula looks like this
 
 $$ethereum\_fee = used\_gas * (base\_fee\_per\_gas + priority\_fee\_per\_gas)$$
 
@@ -107,31 +105,53 @@ base\_fee\_per\_gas_{n} &= base\_fee\_per\_gas_{n-1} * (1 + adjustment + \frac{a
 $$
 
 with the following configuration parameters:
-- $base\_fee\_per\_gas_{min}$ - the smallest possible value of base\_fee\_per\_gas.
-- $base\_fee\_per\_gas_{max}$ - the largest possible value of base\_fee\_per\_gas.
+
+- $base\_fee\_per\_gas_{min}$ - the smallest possible value of base_fee_per_gas.
+- $base\_fee\_per\_gas_{max}$ - the largest possible value of base_fee_per_gas.
 
 ## Fee Model Parameters
 
 Values of all the Fee Model parameters are listed in the table below.
 
-| Parameter name                                            | Value on Shibuya          | Value on Shiden | Value on Astar | 
-| --------------------------------------------------------- |------------------         |-----------------|----------------|
-| $base\_weight$                                            | 98974                     | 98974           | 98974          |
-| $weight_{factor}$ (per byte)                              | 0.030855 SBY              | 0.00030855 SDN  | 0.030855 ASTR  |
-| $length_{factor}$ (per byte)                              | 0.0000235 SBY             | 0.000000235 SDN | 0.0000235 ASTR |
-| $max\_block\_normal\_dispatch\_weight$                    | 375,000,000,000           | 375,000,000,000 | 375,000,000,000|
-| $s*$                                                      | 0.25                      | 0.25            | 0.25           |
-| $v$                                                       | 0.000015                  | 0.000015        | 0.000015       |
-| $c_{min}$                                                 | 0.1                       | 0.1             | 0.1            | 
-| $c_{max}$                                                 | 10                        | 10              | 10             |
-| $price\_per\_item$                                        | 0.00004 SBY               | 0.0000004 SDN   | 0.00004 ASTR   |
-| $price\_per\_byte$                                        | 0.000001 SBY              | 0.00000001 SDN  | 0.000001 ASTR  |
-| $base\_fee\_per\_gas_{min}$                               | 0.0000008 SBY             | 0.000000008 SDN | 0.0000008 ASTR |
-| $base\_fee\_per\_gas_{max}$                               | 0.00008 SBY               | 0.0000008 SDN   | 0.00008 ASTR   |
-
+| Parameter name                         | Value on Shibuya | Value on Shiden | Value on Astar  |
+| -------------------------------------- | ---------------- | --------------- | --------------- |
+| $base\_weight$                         | 98974            | 98974           | 98974           |
+| $weight_{factor}$ (per byte)           | 0.030855 SBY     | 0.00030855 SDN  | 0.030855 ASTR   |
+| $length_{factor}$ (per byte)           | 0.0000235 SBY    | 0.000000235 SDN | 0.0000235 ASTR  |
+| $max\_block\_normal\_dispatch\_weight$ | 375,000,000,000  | 375,000,000,000 | 375,000,000,000 |
+| $s*$                                   | 0.25             | 0.25            | 0.25            |
+| $v$                                    | 0.000015         | 0.000015        | 0.000015        |
+| $c_{min}$                              | 0.1              | 0.1             | 0.1             |
+| $c_{max}$                              | 10               | 10              | 10              |
+| $price\_per\_item$                     | 0.00004 SBY      | 0.0000004 SDN   | 0.00004 ASTR    |
+| $price\_per\_byte$                     | 0.000001 SBY     | 0.00000001 SDN  | 0.000001 ASTR   |
+| $base\_fee\_per\_gas_{min}$            | 0.0000008 SBY    | 0.000000008 SDN | 0.0000008 ASTR  |
+| $base\_fee\_per\_gas_{max}$            | 0.00008 SBY      | 0.0000008 SDN   | 0.00008 ASTR    |
 
 The values for the parameters above are set so that EVM fee and the Native fee are equal and equal to 0.5 ASTR or 0.005 SDN for an average weight and length transaction with no rent fee.
 
-## Fee Alignment Transition Period
+## Rent Fee
+
+Executing certain on-chain actions can result in additional storage being created.
+E.g. if an account decides to create an _identity_, this has to be stored on-chain, whoever is running a node needs to store this piece of information somehow.
+To prevent _spamming_, such actions usually incur some _rent_ fee which needs to be _deposited_.
+Unlike regular transaction fee, once the storage entry has been removed, the _rent_ fee is also returned to the account.
+
+For concrete values per entry & per byte, please refer to the table above.
+
+Some actions which incur _rent_ fee are:
+
+- creating an identity, including sub-accounts
+- creating a multisig call
+- creating an asset & metadata (**NOTE: see table below**)
+- creating a proxy, announcing proxy calls
+- interacting with WASM smart contracts
+
+
+For `pallet-assets` _asset_, creation price is higher than the regular price.
+This is because creating an asset carries more _weight_ than simply creating an e.g. _proxy_.
+Assets can be registered as cross-chain assets and they can be interacted via precompiles, which makes them usable by any account.
 
-Legacy Astar Network tokenomics fee model was not aligned between the two systems - same resource consumption via native or Ethereum transactions resulted in significantly different fees. To allow network stakeholders to adjust to the Tokenomics 2.0 fee model, alignment of fees between the two systems will be gradually introduced once the change is enacted (live) on the network.
+| Action         | Price on Shibuya | Price on Shiden | Price on Astar |
+| -------------- | ---------------- | --------------- | -------------- |
+| Asset creation | 10 SBY           | 10 SDN          | 1000 ASTR      |