Thank you for the update!
This feature is very important and I look forward to its implementation.
Practically a timely solution was adopted to protect some teams from lost earnings due to the drop in the price of $astar token, but nothing has yet been done to implement a healthy and linear policy between the various tiers.
If a tier 2 team complains about a drop in rewards, a solution is found in a short time.
If a team that is part of a lower tier points out the non-linearity and that a few Astars can decide to lower the Astar rewards that are received by 90% or more, that’s right, you deserve a tip.
We didn’t even want to reply, but this is another example of how the interests of a few are better protected, and how dapp staking thrives on centralized autonomy.
this is why this change was necessary and was implemented quickly: Build2Earn Rewards Query 1.1
It’s impressive how you’re able to twist information to find a way to complain without knowing what you’re talking about.
The work on an Oracle dedicated to dApp Staking was initiated long before Destore shared concerns about tier reward calculations. In fact, it was even initiated by Dino before dApp Staking V3 as future work to be completed after V3’s launch.
The issue was created back in January 2023 (Before V3 launch):
The code development and first PR on Astar Github are from March:
This work required months of development on Dino’s part and has nothing to do with Destore’s recent post, it’s just coincidence that the work was finalized around the same time.
It might be worth asking questions instead of making false assumptions underneath the emotions, in order to move the discussion forward on redesigning the tier reward model which, by the way, could take months to develop and implement compared to the level of change to be made in the dApp Staking code.
Incredible coincidences then.
We are witnessing what we tried to make you and the entire core team understand 3 months ago without success.
Dapp staking is no longer of interest to anyone (evaluate the requests here on the forum), there is no promotion in the lower tiers (you don’t even receive replies from those who a few months ago were present 24/7 and always writing on this forum).
Want to know what will happen at the end of the build and earn era? our dapp (which had to change its proposal due to insufficient support after a drastic change in the rules) will have 0 trust from those who have supported us up to now, putting the work of my team in a bad light.
This will also apply to other projects. If for now the tokens are still there it is only because changing would cause you to lose bonuses.
In a few months, the only way your team will have to prevent the tokens from arriving only and exclusively on a few dapps will be to distribute them arbitrarily by pretending that they are real people who vote.
At that moment having 4 tiers and numerous slots will be useless. Don’t always say there is emotion in what we say in an attempt to belittle us. We are probably the most honest in here in expressing what we think.
Thank you for the information.
By the way, the release of Astar v5.38.0 was announced the other day.
Is my understanding correct that this includes related updates?
New Release Anouncement: Astar v5.38.0
Hello Builders, We are excited to announce the release of Astar v5.38.0!.Release Highlights
Polkadot Base Update : The codebase has been upgraded to polkadot-v1.3.0, introducing numerous changes to the runtime code and client
dApp Staking Enhancements : dApp staking has been updated to re-calculate tier config at the end (or the beginning) of each era. Shiden & Astar will now utilize oracle backed moving price average for tier config re-calculation. These changes will make tiers more adaptable to the off-chain trends.
Yes, that’s what’s included in the release. Solution should also be live on Astar this week.
Thank you for your reply.
According to the polkadot telemetry site,
I have confirmed that version of the node already comprises 25% of the total.
The version of the node doesn’t matter for this, since it’s “just” the client.
The runtime, state-transition-function, is what matters for the level of features as dApp staking, tokenomics, etc.
This will explain it more:
Last week we did Shiden runtime upgrade, and tomorrow we’ll do Astar.
Thank you for the additional comments.
Yes, I am aware of the importance of runtimes and related concepts. However, I wasn’t familiar with the details, so I will refer to the web page you provided.
I’m also looking forward to the upgrades for Astar
Astar has been upgraded, and devs will see their ASTR rewards increase during the coming days (docs link).
NOTE: this only relates to developer rewards, staker rewards aren’t impacted.
Thank you very much!
By the way, where do you get the ASTR prices from for this oracle?
Prices are fetched from a few sources, like L1 oracles, L2 oracles, and our dedicated price API. The prices are combined (median), and published on a 1 hour interval on chain.
It’s relatively simple oracle service, but for this purpose it’s more than enough since it’s not supposed to be a DeFi-grade service.
Thanks for the reply!
I would like to know a few more details. Specifically, from which source do you get the ASTR prices and take the median?
I am curious because oracles can also lead to targets of attack.
Pyth, DIA, Band, GoinGecko right now.
The possibility of attack is low, and impact is also negligible.
If we detect large deviations from what’s submitted on-chain, and what’s available from other sources, we’ll take a look at what’s happening (hasn’t happened yet, but we’re still early of course).
Understood, thank you!
I would like to know if it could be possible to modify Bonus reward system in order to allow, during B2E period, the transfert of a portion, if not all, of the Astr staked on a dApp during voting periode to another without losing the eligibility to the bonus related to this stake.
I beleive it is necessary to implement such an adjustement in order to get the flexibility required to support a dApp who need it during the B2E period to keep its Tier. Best exemple is Astar Degen DAO who’s currently using all its treasury to support lower Tier dApp but once voting period is over, their capacity to give additional support to lower Tier dApp is frozen if they don’t want to loose the bonus. SFY would have beneficied of this flexibility as what they needed was staked on a dApp who did not need it to keep its Tier.
I understand that this rigidity has been programmed in order to give a certain stability to the Tiering but with the implementation of the Oracle system, Tiering treshold is now moving and adjustment HAVE TO BE POSSIBLE without being penalized.
I would suggest, to prevent people to modify their stake all the time, to add a cooldowm period of 10 days after the modification of a stake during which if the stake is moved again, the bonus of this stake will be lost.
ex :
during voting period Mr X stake :
- 1.4M astr on dApp A to help him reach its Tier 2
- 2M astr on dApp B to help him reach its Tier 3
- 5M astr on dApp C to help him reach its Tier 3
during B2E period, dApp B fall bellow its Tier treshold by 1M due to dynamic Tier 3 threshold or a big fish unstaking its Astr. Mean while dApp C have a confortable 10M Astr above Tier 3 treshold.
Mr X want to help dApp B to keep its Tier 3 by transferting 2 of the 5M staked on dApp C as it will not impact negatively dApp C but will help dApp B tremandously.
With current system, Mr X will be penalized for such behavior as 2M from voting period have been moved to another dApp making its stake on dApp C fall bellow the 5M allocated during voting periode - he will thus lose the bonus associated to the 5M staked on dApp C.
Such operation should be autorized without loosing the bonus if Mr X do not move the 2M from dApp B to another dApp within the 10 days cooldown periode
wow, another problem associated with tiers… never even thought about this, the dynamism is interrupted in numerous examples it seems. It was definitely better to stay at v2 with a drastic cut in rewards. To fix everything that arises from the bad ideation of the tiers and tokens to burn (rewards, UCG, Bonuses…) whoever designed the Tier system will have to work 10 times more than usual…A certain point has been reached it will not be possible to justify one of the many aspects connected to the new V3 dappstaking as “right” or “meritocritical” but only to say “this is the rule, accept it”. Rule voted by?
There was no vote, but there was ample time for discussion. I do not have a problem with this.
This thread was started in January 2023 and the report, which also includes Tokenomics, was submitted in August 2023.
However, as I mentioned earlier in this thread, the parameters were changed near implementation, and this is a very big issue regarding this.
I think this is a good idea if possible.
Currently, I feel that newly listed dApps are at too much of a disadvantage during B&E. 1Period is about 4 months, which is too long in this industry.
Or, I think one of the suggestions would be to shorten the Period itself, as 4 months is so long that even as a Staker, Staker would forget to vote. Personally, 1 month (30ERA: Voting 5ERA + B&E 25ERA) is enough for me.
This is another suggestion, but how about adding a mechanism to prevent dApps from free-riding?
As always, I’m not a developer so I’m ignoring this as far as implementation and system burdens. Thank you for your understanding.
There are currently several dApps that report their activity on the forum, but it would be difficult for Staker to check them all. Therefore, how about the following process?
- Add an activity report section to the dApps page of Astat Portal
- Each dApps is obligated to report monthly (30ERA) (sections that are not likely to generate additional development, such as tools and infrastructure, should just report on usage, etc.)
- Write to the on-chain at the time of reporting
- Reduce compensation if no report is made for each of the past 30 ERA at the time of each ERA compensation accrual
30ERA → -33%, 60ERA → -66%, 90ERA → -99%, 120ERA → Delist - Reset the penalty if reported (I think it would be preferable to move back one penalty tier if the system is less loaded)
The advantages of this system include
- Staker can easily see activity reports
- Forum threads will be able to prioritize discussions
- Penalty mechanisms will be in place to encourage activity reports
- Ghost dApps will disappear because dApps with low activity will be automatically delisted.
Although it is an optimistic system (false reporting is possible), it will be much better than the current situation. Currently, we can use Forum, and in the future, we can use on-chain governance to prove fraud.
I think it would be relatively simple to implement if Period were to be 30ERA, as in one previous post. In that case, the activity report would be fixed to the Voting Period, which would make it easier to manage the parameters.