i think its just the matter of tweaking the tier thresholds and increasing the slots in certain tiers for more appropriate rewad distribution. This current tiering is very aggressive at lower levels. I am sure team will listen to our feedback and act upon it. These are growing pains and i am glad we all are speaking about this issue.
1 Like
My proposal to increase the number of Tiers to five is to smooth out the difference in the quantity of ASTRs required per Tier. At the current thresholds, the ASTRs required per Tier would increase as follows
Tier4 → Tier3: 1000%~1333%
Tier3 → Tier2: 333%~375%
Tier2 → Tier1: 400%
With the parameters I suggested, it would be as follows.
Tier5 → Tier4: 300%~400%
Tier4 → Tier3: 333%
Tier3 → Tier2: 333%~375%
Tier2 → Tier1: 400%
Then, in this state, the balance of each parameter can be rebalanced to adjust the amount of reward while keeping the overall number of slots the same. Of course, it is also possible to adjust parameters without adding tiers.
Also, this is not good because if the Tier 4 requirement is less than 10M, even 1 ASTR will be rewarded if it is staked. A minimum threshold is necessary.
3 Likes
I’m not a developer, but putting myself in the shoes of the @Sfy Labs Team it’s very easy for me to understand their frustration and disappointment. I have been following them since the beginning and I can only say that they are exemplary professionals, probably one of the few (VERY FEW) dapps who have not only really worked, but have also done it well, as they have always done.
We are at the beginning of this V3, I am confident that Team Astar can patch things up and review this system which does not seem to be (at present) meritocratic and reward small/medium developers who truly deserve it.
My2cents
3 Likes
I’m completely agree 
2 Likes
Who paid for this?
The holders always get the same percentage.
The validators/collators? (we do not know)
The small to medium dapps have in fact been thrown out.
Dapp staking wasn’t a timed event or contest, but astarr’s flagship narrative, which brought developers and interest to the chain. The team is top, they have always worked top-notch. Today it completely failed with the v3 rewrds.
developers are not INVESTORS. they have fixed costs to deal with. I understand that it’s easy for an owner to say: even a little today will be a lot of money in the future also depending on the greater burn, but we don’t pay for development with promises. This must be clear. And whoever, as a dapp owner, answers us like this and agrees with this idea, means that in reality he is not developing anything at all, and is in it at 0 cost.
3 Likes
Marketing activities through economic incentives have acted like a cheat code, forcing some projects into a price war, and small teams unable to sustain such losses have been completely excluded from the competition.
Although it is known that such incentives are not free and cannot bring about a sustainable voting effect, there is a possibility of illegitimate gain through the financial incentives of baseless teams with each voting cycle. Ideally, this issue could be resolved through the optimization of parameters mentioned above; however, if not, the rewards for vote from the candidates should not be monetary. Economic incentives surpass any developmental advantage or marketing activity for stakers.
Judgments should be based on non-monetary criteria, leveraging the power of collective intelligence for decentralized decision-making. This discussion is the responsibility of all ecosystem participants.
At the same time, the current focus for projects and developers should be on securing grants or investments if they have the skills. Otherwise, they should concentrate on community engagement and communication to enhance marketing effects through legitimate means. The notion that nothing comes for free applies both to the Astar Network and to the projects themselves.
3 Likes
We want to start by saying something that many perhaps have not understood: We have never requested any grant.
We wanted to make it with our own efforts alone, and using dapp staking and our own work. A team makes plans, has fixed costs to pay, if 1 more or less astr puts you in one tier or another, with a difference of 10 times what was expected, then we are really talking about nothing.
This doesn’t just apply to SFY, it applies to all projects and all tiers.
The only difference is that the larger teams have not suffered the losses that we have suffered, in fact going from 40-50 million to 270 in staking like Neurolanche and having losses of 20-30% in total? totally sustainable and acceptable if the burn narrative affects everyone. Having a 90% decrease is not sustainable. Do you think that the top teams have all disproportionately increased their astars and staking just for a question of greater visibility and trust of the community? or was there a different push? For example DeStore and Neurolanche, but also other teams… let’s be honest, the v3 rewards for the same amount of astar collected are in fact 0 for the dapps… few teams have had a parachute. We are not denigrating anyone’s work here, it is important to be in a healthy and collaborative environment.
fair enough, i can support your argument and proposal.
4 Likes
Tokenomics 2.0 - dAppStakingV3 is adjustable.
( We already used over 1 year from proposal.)
But we know this is NOT a key.
Manta( same Polkadot Parachain ) grow up Manta Atlantic( L1 ) and
Manta Pacific( PolygonCDK->L2 ), L2BEAT( No.3 ), DefiLlama( No.10 ) TVL, Start with airdrop, but still growing.
We shoud know what we realy need.
( What’s the difference between us? )
2 Likes
One more new proposal.
(Forgive me for saying what I want, even though I am not a developer.)
The problem with rewarding dApps in v3 is that if you are not even slightly short of the Tier threshold, your reward will not increase. For example, to go from Tier 4 to Tier 3, you need to get 10x the ASTR, and if you fall even slightly short, there will be a huge sense of loss for everyone involved. This may not be good for the developer, nor for the supporting Staker.
This third proposal, in addition to yesterday’s proposal, makes a bolder change.
It is to make the mechanism for generating rewards for v2 and v3 dApps a hybrid.
To make it easier to visualize, I will present a diagram first.
In the current tier model, the amount of compensation is fixed for each tier. In the hybrid tier model proposed here, a reward cap will be set for each tier, and the amount of reward will change dynamically (linearly). This ensures that Stake is not wasted until the Tier 1 cap is reached, and the efforts of the developer and community are rewarded.
Advantage
- Reduces disparity between tiers
- For developers and the community, there is an incentive to collect Stake up to the Tier 1 limit
Disadvantages
- Less burn than the current model
- Less incentive to move up a tier.
(However, as noted in the advantages, the incentive to collect Stake is considered stronger)
In this model, the parameters are set as follows to make the amount of reward as close as possible to the amount of reward in the current model. With this parameter setting, you will get a reward close to current Tier when PJ get the same TVL as the threshold of current Tier.
*The APR in the table is the value when the threshold is at its maximum. It is not important as it is only a guide.
Slot Portions
Tier1: 5% → 5%
Tier2: 20% → 15%
Tier3: 30% → 30%
Tier4: 45% → 50%
Reward Distribution
Tier1: 25% → 25%
Tier2: 47% → 35%
Tier3: 25% → 25%
Tier4: 3% → 15%
Threshold
Tier1(Limit): 200M - 300M
Tier1: 50M - 75M
Tier2: 15M - 20M
Tier3: 4.5M - 6M
Tier4: 1.5M
Tier Zone
Tier1: 50~200M↑ - 75~300M↑
Tier2: 15~50M - 20~75M
Tier3: 4.5~15M - 6~20M
Tier4: 1.5~4.5M - 1.5M~6M
Currrent Model
The simulation of the reward from this is shown here.
Thresholds are calculated using the current (lowest) value.
In the simulation, the amount of rewards and burns varied as follows
- Rewards(q/Era): 34,620.47 → 47,812.13 (+13,191.66 | +38.10%)
- Burn(q/Era): 173,996.42 → 160,804.76 (-13,191.66 | -7.58%)
However, I do not believe that the current situation where the threshold is set at its lowest value is the best situation. This is because the threshold is calculated to go down as dApps listings increase. This does not work because it is more likely to increase than decrease. Therefore, we will re-set the threshold to the highest value and run the simulation.
In this simulation, the amount of rewards and burns varied as follows.
- Rewards(q/Era): 34,620.47 → 39,352.76 (+4,732.29 | +13.67%)
- Burn(q/Era): 173,996.42 → 169,264.13 (-4,732.29 | -2.72%)
We believe this will result in a fairer system with minimal impact on inflation.
v3 is a revolutionary update that solves many of the problems of v2 and also has the effect of reducing ASTR inflation. However, the current situation seems to favor the holder (staker) too much. Astar is a chain that originally favored developers, and many community members must be proud of that. I hope that the system will be balanced for both developers and holders.
12 Likes
Sorry, correction.
It is correct that the threshold changes as the number of slots increases or decreases, not the listed dApps.
Currently it is at the minimum value, so that as the price of Astar decreases and the number of slots decreases, the threshold value will increase.
After correcting this error, we think it would be better to reset the threshold to the maximum value or to an intermediate value.
Since the Tier thresholds do not necessarily need to be exceeded in this proposal, we do not see a problem with starting the threshold at a higher value.
3 Likes
Brilliant solution. We vote for this.
2 Likes
I think it’s a great suggestion.
If this proposal is adopted, it will create healthy competition even among the same tiers, and I believe it will greatly increase the incentive for the project to gather staking.
I think it’s difficult to modify the system immediately, but I hope we will consider adopting it to make dApp Staking a better system.
6 Likes
yes,anyway… it is utopian to think that it can be taken into consideration.
Let’s be real, the narrative of helping dapps is over, now there is only interest in talking about how low inflation is.
2 Likes
To put my feet in dev view, 5-tier is one of the easy-fix solutions. But to add more tiers from 4 tiers esp the 4th tier was just added when we got up to DApp v3… it’s just we going to go into v4,v5,v6 eternally.
The hybrid solution was best for long fixes, but the percentage and algo will be hard to find the balance. Each tier had a limited slot, and each tier had its allocation. Nightmare would happen when every slot of each tier, is just right at the limit. I will try to explain in math.
For now, the inflation caused in each era is:
tier 4 is 66 ASTR * 94 slot = 6.204 ASTR/era
tier 3 is 827 ASTR * 63 slot = 52.101 ASTR/era
etc… etc…
when we make a hybrid model, say 3/4 of tier 4 reaches almost tier 3, then the allocation will be wrecked.
In this sample, Astar Safe is a good example. 200 ASTR per era * 105*3/4 = 15.750 ASTR/era
The difference is huge just for tier 4, it’s 2.5x!
In my opinion, decreasing number of number of allocated is more reasonable rn. Since we don’t have 200 DAPPs right now. Reducing the number to 100 or 150, and adding more rewards is better for the devs. But, this is against the holders because the burn is lesser in this way. All in all, we want to keep rewarding dev, but in a way keep inflation not so high, so week keep the economic more appealing. And Inflation is not that bad actually, but the distribution what make them important.
6 Likes
Thanks for your feedback.
Yes, from a development standpoint, it would be easiest to increase tiers. But, as you say, eventually the number of tiers will only increase with each complaint, and this will not be a fundamental solution. Will we make it to tier 100?
I think the most important aspects in v3 are
- Reduction of too high rewards
- Fairness of rewards
- Voting fluidity (reset)
I do not believe the purpose of v3 is to reduce inflation. Without qualified dApps, inflation will only be reduced as a result, and the goal should not be to unreasonably reduce developer compensation.
For reference, the dApps reward allocation was reduced by almost 30% (from 105M to 76M) with the update from v2 to v3. Additionally, more than 80% is now burned. Is it necessary to go this far?
Even if all dApps fees were distributed, the current inflation rate is about 4.7%. Inflation has been cut by nearly 30%, or 4.2% if you factor in the burn on dApps rewards, plus the burn on gas.
(Sorry it’s hard to see…)
The real APR for Staker now is 14%, up significantly from v2. Even if the Stake amount is the same as in v2, the real APR is 6.5%, plus Bonus Rewards.
For reference, please take a look at the real APRs of the top projects.
- ETH: 4.06%
- BNB: 6.63%
- SOL: 0.8%
- ADA: 0.56%
- AVAX: 2.39%
We can clearly see that ASTR is the dominant performer.
To be clear for fairness, when ASTR’s Stake rate reaches 50% of total supply, the real APR is around 4%. Still, this is excellent performance.
This creates an imbalance within the community, as Staker has an overwhelming advantage over dApps. Nevertheless, it would be wrong to allow a huge amount of rewards to be distributed to a few dApps as before. Therefore, I proposed a hybrid model in which the percentage of rewards distributed varies depending on the amount of Staking. This is equivalent to having a large number of Tiers with very finely chopped thresholds: the higher the Tier, the smaller the amount of reward per ASTR, working to reduce the disparity per Tier.
I also expect this to increase developer and community engagement. The current model has a large gap between Tier and Tier thresholds, so there is no incentive for projects that are just barely over the threshold to work hard and collect Stake. Also, the community may be less inclined to Stake, so making the rewards per Tier dynamic would create an incentive to attract new holders by making it more fluid, and I believe community support would be more active.
Having stated my thoughts thus far, I would like to respond to your concerns.
Yes, that is correct. But isn’t this the same thing with the current Tier model?
I think this is just a matter of adjusting the parameters as needed.
Yes, I understand what you are saying. However, the example is a bit extreme and realistically looking at the current situation, I don’t see how it could be that way. Also, as I wrote earlier, dApps rewards have already been reduced enough that I would have no problem with them being distributed in full. Also, if that much activity is being generated, then Astar is a huge success. Isn’t the gas burn pretty big as well?
Yes, this was my first thought. However, I don’t think this approach bridges the gap between Tiers, nor does it properly reflect the evaluation by Stake. Also, what do you do when the number of dApps increases? Do you add more slots? I think this is an ad hoc solution and more fundamental improvements are needed. If you are going to reduce the number of slots, it would be better to increase the number of tiers.
Yes, agree. And I believe the best move that can be made to distribute correctly is the hybrid model.
3 Likes
Yeah, I think we conclude that the dev must work harder to find the right hybrid algorithm for Dapps reward.
Indeed reducing inflation was the bonus, but the right allocation and the right and fairness are what we discuss right now.
Couldn’t agree more about our real reward was in higher performance. But, inflation is also an important part of what makes a good chain have better economic. Just like a nation, if the economy is too hawkish, people tend to save money, and the economy not growing. If the economy is too dovish, people tend to spend and take credits that are exposed to bad debt.
And responding for specific reply,
and this
After hearing your explanation, I do agree that increasing the number of tiers is better than reducing numbers of slots, as we keep new DApps ready to join. Each new Dapps, increase interaction and gas burn.
In the end do agree to this part very much. Now we let the dev to think and try to develop the newest hybrid tier 
Hope this will not be too long. Not until we get another Dapps not happy with the reward.
4 Likes
I have read what was written since the initial post by SFY_labs and will provide a few comments from a perspective of a dev who worked on dApp staking from the idea to the architecture, implementation and the docs.
(this isn’t necessarily the stance of the Astar team but it is mine)
First, I have to commend @you425 for doing an analysis, modeling and explanation. It’s refreshing to see someone take in-depth dive at something, especially related to tokenomics. 
Discussions tend to be “echo chambers”, but this was something new & thought out.
Tier System
From all the discussions I can see, everything seems to be working as intended.
Tier system was explained over a year ago, so calling it absurd or nonsensical is “absurd” in itself.
Tier system has a purpose, as does resetting the staked amount.
It’s all explained in the original post, in the tokenomics post(s), in the official docs.
Rewards & Price
I’ve commented it here, but to repeat, ASTR price has increased roughly 3-4x in the last 4 months. The amount of rewards received by the developers has also increased by the same factor - however, this hasn’t been mentioned once in the discussion so far.
For easier reference, here’s the breakdown of rewards per tier:
Tier 4 rewards are meant to be entry level, they are supposed to be meager.
Tier 3 rewards are meant to be much more substantial.
For a well established project, with a solid (and loyal) user base, achieving tier 3 (or 2) should not pose a significant challenge.
And to repeat what I wrote in the linked forum post, it’s expected that developers will stake on their own dApp. It’s web3, it’s decentralized, there’s no mechanism to prevent this (and why should we?). Rewards for tier cannot be so high that they’re enough to keep buying higher tiers, and also support the development. There has to be a balance.
Parameters
One thing that is planned, and expected with every new major feature, are tweaks & updates. We can assume a lot, analyze, make models, tests, simulations, explanations, but in the end, what matters is how it works “in the field”.
We are observing how it’s working, and will continue to do so.
It’s still super early, and some time will need to pass before we have sufficient data.
Situations like this are part of the observation.
However, dApp staking is bigger than one app, and many different factors need to be considered. Just because on dApp is dissatisfied, it doesn’t mean something needs to be changed immediately or that there’s something inherently wrong.
Hybrid Solution Proposal
For the solution proposed by @you425, I really like the approach, effort and mentality here. I’m repeating my commendations right now 
.
It’s not clear to me how would you define total number of dApps that the protocol can support? This is very important, since based on this proposal, dApps are almost always in between the the starting & ending point of the line.
The system should not"punish" dApp A when dApp B increases its stake amount. I don’t see how you can achieve this without extremely reducing the amount of dApps that protocol can support.
Inflation Comment
The reduced inflation does not only benefit stakers, but every token holder.
If a developer receives ASTR as reward, that also makes them a token holder.
I’m stating the obvious here, but it’s important to keep that in mind.
Future Work
Right now, the concrete planned future work is to get tier configuration recalculated more often, and to introduce more dynamic pricing (via oracle).
The other part is the aforementioned observation.
Based on that, we’ll be adjusting parameters & logic.
10 Likes
Hi Dino, just a question:
Today it happened that for a very short time the Lucky dapp moved to tier 4. now it has returned above 15 million, what happens if in the next era 2 more dapps arrive above that threshold?
Who among these 3 dapps will be in the last 2 missing slots?
Don’t think that because a system was explained long ago it is easy to assimilate, many critical issues are discovered only by experiencing it.
The only advice we give you is not to make supporting dapps involved in real development a roller coaster.
Nobody is against your work, it’s difficult to think about all aspects of this system.
Please check here.
Also, there are more slots than the UI shows.
There’s no point in showing empty pages.
From on-chain:
numberOfSlots: 230
slotsPerTier: [
11
46
69
103
]
First number refers to tier 1, second number to tier 2 and so on.
4 Likes