Table of contents
- Introduction
- Current Tokenomics Overview
– Block Rewards
– Transaction Fees
— Native Fees
— Ethereum Fees
– Rent Fees - Problems We Like To Address
– High & Fixed Inflation
– Scalable & Inclusive dApp Staking
– Native & Ethereum Fee Alignment
– High Treasury & Collator Rewards
– Materials - Proposed Solution
– Inflation
– Treasury
– Collators
– dApp Staking
— Stakers
— Builders
– Transaction Fees
– Rent Fees - Summary
- Materials
- Next Steps
Introduction
Hello everyone,
This post will explain in more detail how the recently announced Astar Tokenomics 2.0 will drive Astar’s sustainable growth & improve user engagement.
Our team has invested significant time and effort into simplifying this information by breaking it down into more digestible chunks while ensuring that all the essential aspects are covered. Nevertheless, we acknowledge that it remains a vast and intricate topic that may require some time to grasp fully.
We worked closely with an external tokenomics expert team for 3 months to help us analyze the current tokenomics state and propose a new model to ensure Astar’s sustainable growth.
After reading this post & accompanying documents, you will have a clearer picture of the following:
- How the current tokenomics works.
- How Astar inflation will be reduced & why that’s good.
- How native & Ethereum fees will be aligned.
- How dApp staking v3 tier system is integral to the new tokenomics.
This post will serve as a summary of all the information. For more details, please refer to the linked materials, which contain more in-depth information & explanation. These are mandatory for readers who want a more in-depth understanding.
TL;DR
Considering if we deployed the proposed model immediately along with dApp staking v3, the inflation would be around 5.8% (and likely even lower since this estimate does not account for transaction fee burning).
Current Tokenomics Overview
The best place for the reader to start is the current documentation which can be found here. Please make sure to familiarize yourself with it before reading on.
Block Rewards
Each block produced on Astar emit 253.08new ASTR tokens. This is how inflation works. This amount is fixed, meaning the inflation rate is set to roughly 9.5% per year, based on the initial supply.
Once the253.08 ASTR tokens are emitted as block rewards, they are distributed to various actors in the network. The collator responsible for authoring the block receives a part of that amount, and the on-chain treasury receives a fixed amount plus some dynamic amount, depending on the TVL. Most of the treasury amount will go to the dApp staking protocol - to reward builders and stakers.
Under the current model, the builder’s reward pool receives a fixed amount of the rewards, making it a zero-sum game. As more dApps are registered, the same reward pool is split among more dApps. On contrast, as the total value locked (TVL) increases, the protocol provides stakers a larger chunk of the block reward.
Some readers will take issue with this approach (you’re also encouraged to check dApp staking v3 forum post) - which we’ll discuss more in the following chapters, but first we’ll explain the fee system.
Transaction Fees
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.
Astar is a parachain in the Polkadot ecosystem, which relies on the shared security the Polkadot relay chain provides. However, it comes at the cost of having certain limitations placed on block resources. Most readers should know that a block is produced on Astar every 12 seconds - a limitation imposed by Polkadot. Only 0.5 out of those 12 seconds account for the time required to execute the block. This means it takes 0.5 seconds of execution time on some CPU to execute the block logic. This is the first limiting resource - usually called ref time (time required to execute on the reference machine).
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 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.
Native Fees
Native fees are applied to normal transactions, native to Substrate. For example, balance transfer, using dApp staking, creating a multisig, voting on a referendum, etc.
They are calculated using a model commonly used by Polkadot and (probably) all parachains.
tx_fee = tx_length_fee + base_fee + c * weight_fee + tip
- tx_length_fee - this is part of the fee related to the transaction length (number of bytes).
- base_fee - a fixed fee that needs to be paid for every transaction included in the block.
- weight_fee - is the fee related to the weight of the transaction; right now, it scales with
ref time- the more CPU time required, the higher this fee will be. - c - adjustment factor; if network utilization is above ideal, c factor will increase, forcing users to pay more for weight.
- tip - extra payment transaction submitter pays to ensure their transaction gets included faster into a block.
Ethereum Fees
Astar is fully Ethereum compatible. This means it also supports Ethereum’s gas concept. 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:
tx_fee = gas * (base_fee_per_gas + priority_fee_per_gas)
- gas - encapsulates all the resources spent to execute the block.
- base_fee_per_gas - how much needs to be paid by the user per unit of gas.
- priority_fee_per_gas - how much is the user tipping each unit of gas.
Comparing it with the previous example using native fees, it’s clear that Ethereum transactions are quite different. They are less configurable, and more information is hidden from the user. Regardless of the transaction type, 20% of the fee is burned, adding a deflationary force to the system. The remaining 80% is received by the collator responsible for authoring the block.
Generally, the more block resources consumed, the more user has to pay. That sounds fair 
.
Rent Fees
Rent fees are quite simple - the idea is to charge users who perform an action that results in the creation of some new storage. E.g., database entries on-chain. If the user removes some of the entries and reduces the amount of data stored on-chain, the rent fee is returned. Essentially it’s a deposit.
It’s commonly used in governance functionality, identity, multisig, and Wasm (ink!) smart contracts. E.g. if users create a new identity on-chain, they must pay a deposit fee. If they decide to remove it after some time, they get their full deposit back.
This is important for Astar since we support Wasm (ink!) smart contracts that rely on the rent fee mechanism. On the other hand, we also support EVM, which operates differently - when storage is created, the price of that storage is included in the gas fee, and even if some storage is removed later on, the user doesn’t receive a refund.
Problems We Would Like To Address
High & Fixed Inflation
The block reward is fixed regardless of how much the network is utilized. E.g., whether TVL is 5% or 40%, Astar still issues the same block reward. The same goes for dApp staking rewards, where it doesn’t matter if there is only 1 dApp, or 100 dApps - the reward pool stays the same.
The inflation rate should be lowered and made adjustable based on certain network parameters.
Scalable & Inclusive dApp Staking
Issues inherent in the current dApp staking (V2) model were outlined here, along with a proposed solution. The new design will require slight changes, but the core concepts remain unchanged.
The dApp staking rewards pool should be dynamic, based on how many dApps we have active in the protocol. The inflation rate should be raised if the rewards pool supports 50 dApps, compared to where it should be if it only supported 5 dApps.
Native & Ethereum Fee Alignment
Currently, native Substrate & Ethereum fees are not aligned with one another. Ethereum fees are inexpensive, while Substrate native fees are greater, they are still inexpensive.
Let’s consider a transaction that consumes 50% of a block. Ideally, fees should be the same whether executed on the native Substrate or Ethereum VM. Considering how the two systems differ, we should at least strive to align the transaction execution fees as much as possible.
We want the solution to be as inexpensive as possible while making fees tangible compared to the total supply and inflation rate.
High Treasury & Collator Rewards
The treasury receives excessive rewards at the moment. It’s important to consider that the dApp staking protocol is essentially an extension of the treasury, to which a significant portion of the inflation rewards is allocated to developers. It’s important to maintain this treasury. However, its allocation as a percentage of the total block rewards should be reduced.
Collator rewards are still quite high, even after a reduction some months ago. It’s important to consider that collators don’t bring any security to the network - that’s why there are Polkadot validators. Having 72 collators means that the inflation rate has to support 72 actors in the network, who all have to cover maintenance expenses.
Materials
For a more detailed explanation of the current state, please refer to the official report:
Some changes were made to the document to make it public, but all the information important for this post remains.
Proposed Solution
No solution is a silver bullet. Instead, the changes need to occur incrementally through a series of progressive steps to elevate Astar’s tokenomics to a better place for a sustainable future.
Inflation
Unlike the current system, where block rewards are fixed, the new inflation rate will dynamically adjust every year based on the total supply at the time of adjustment. Using current on-chain data, an estimate of yearly inflation, considering if we deployed the proposed model immediately along with dApp staking v3, would be around 5.8% (and likely even lower since this estimate does not account for transaction fee burning).
Treasury
Remove the dynamic treasury allocation and assign a fixed rate of 5% of the yearly inflation.
Collators
Collators will receive 3.2% of the yearly inflation. This is a reduction compared to what it is currently. However, since EVM fees will be aligned with Substrate native fees, collators will earn significantly more from fees overall.
The collator system will be addressed in a separate project (Astar Consensus) to make it more inclusive & robust. We expect this next year.
dApp Staking
Stakers
The amount of inflation going towards stakers will remain roughly the same, but the ideal TVL will be reduced with overall inflation. This means that inflation-adjusted return will be increased for all stakers, giving their earnings higher value.
The ideal TVL will be reduced to 50%, making it more attainable, and base staking rewards will be increased to help achieve that.
Given that dynamic treasury inflation will be removed, the dynamic staking portion will only be minted if certain TVL requirements are met. Consequently, this means less inflation overall when the ideal TVL is not met.
Builders
Builder rewards will receive the biggest overhaul compared to the old system.
dApp staking v3 will introduce tiers, making the system more inclusive for new dApps, while continuing to provide lucrative rewards for existing ones. Before starting a new period, the system will calculate the tier configuration based on the average ASTR token price during the last period. This aims to ensure each tier’s rewards are significant, however, not excessive. Clearly, if the ASTR token price is 1$, we can support a greater number of dApps than if it were only 0.05$.
We’ve opted for 4 distinct tiers in the new model. The following table roughly approximates what the reward distribution might look like per month (full B&E period month):
| ASTR price (in $) | Number of slots | Tier 1 reward per dApp (in $) | Tier 2 reward per dApp (in $) | Tier 3 reward per dApp (in $) | Tier 4 reward per dApp (in $) |
|---|---|---|---|---|---|
| 0.01 | 60 | 7 812 | 2 929 | 1 302 | 488 |
| 0.025 | 75 | 16 739 | 5 859 | 2 663 | 945 |
| 0.05 | 100 | 23 435 | 8 788 | 3 906 | 1 465 |
| 0.1 | 150 | 31 247 | 11 718 | 5 208 | 1 953 |
| 0.2 | 250 | 37 496 | 14 061 | 6 249 | 2 344 |
| 0.5 | 550 | 42 609 | 15 978 | 7 102 | 2 663 |
| 1 | 1050 | 44 638 | 16 739 | 7 440 | 2 790 |
To qualify and be selected for a particular tier, dApps must meet certain TVL requirements, which may change as the network grows. If dApp staking slots aren’t filled, the rewards for the periods the slots are empty are burned.
Transaction Fees
The solution here is quite simple - align Substrate native & Ethereum fees as much as possible. If transactions consume the same amount of block resources, they should be priced roughly the same. There will also be some improvements to this in the near future, as we’ll be able to measure Ethereum transaction resource consumption similarly to how we quantify Substrate native fees.
These fee changes won’t happen overnight. Instead, they will be implemented gradually over a period of time (e.g. 3 months). The fees being burned will be increased to 80%, with 20% being deposited to the collators. This does not include the tip portion that will be paid out to collators in full.
Rent Fees
Rent fees will be reduced by a factor of 100, making on-chain storage significantly cheaper. The balance we’re striving for is between that of network security and the impact of the overall fee amount.
Summary
The main modifications to the inflation model and dApp staking protocol are summarized below:
- If TVL is not in the ideal range, not all staking rewards will be minted.
- If empty slots are present in dApp staking during a period, the rewards for that period normally allocated to those slots will be burned.
- Transaction fees will incur a significant burn.
- The inflation rate will constantly adjust to on-chain parameters.
Let’s remind ourselves that whatever we implement on the network isn’t written in stone. Anything can be adjusted. However, we should consider making changes slowly and quite deliberately for the stability and health of the network.
Materials
Over the course of 3 months, a few working docs were created:
- Working Inflation Report (part 1)
- Working Inflation Report (part 2)
- Analysis of Collators
- Discarded Build2Earn Model Proposal
- Experiments - Factor m
The final report can be found here:
Next Steps
- Open up community forum discussion
- Share implementation plan & execution (plan will be shared this month)
- Create comprehensive documentation (goes parallel with the implementation and execution strategy)
EDIT: For development progress, please follow-this issue ticket.
! Let’s go for big Astar family!
