I would like to open a discussion to know what could be done to improve dApp staking V3 threshold system and/or dApp dashboard as ATM projects have absolutely no visibilty nor previsibility on the direction threshold will go (up/down) and up/down to how much.
with the current setting it is absolutly impossible to determine up to how much the tresholds will climb and thus how much effort have to be put in order to bring additionnal TVL on a dApp in order to stay above its current Tier entry treshold.
Further more, with the great instability of the market, threshold system seem to be heavily affected, inducing important change in tresholds within a short period. We could use this discussion too to identify what could be done to slow down those drastic changes and thus give more time to projects to adapte knowing that the bonus system lock an important portion of the TVL during a B2E period and prevent stakers to redirect some of their asset to support a dApp in need of it without bearing financial loss.
Indeed, it is currently difficult to deal with the variation of threshold values.
Furthermore, the maximum and minimum values of the thresholds have also recently changed depending on the amount of ASTRs issued.
This has increased the number of variables and made it more difficult to know the threshold in advance.
Adding the next ERA tier threshold prediction to Portal might make it easier to understand.
I think we should aim to get at least one week prediction, through trend graph with various number of extrapolation considering market trend (24h / 7 day) and other model parameter giving up to 7 days forcasting. IMO it is not necessary to be very accurate when considering more than current era +2 or +3 eras for the trend but we need to know if the treshold will continu to rise and up to which value.
so we should also have an indicator of âfinalâ treshold value if parameter stays the same until treshold stabilize.
In this fashion, we would have a trend (forcasting the speed of the variation) + an estimate end point for threshold value
In forecasting the trend over a week with an estimate of the final threshold value, this is a solid approach. This allows us to see the rate of change and where it could settle, making it possible for us to keep track of things.
I donât think there is any particular systemic improvement. It only means that it will be easier for dApps and Staker to predict thresholds.
The next ERA can produce a threshold calculated from the current ASTR price, which is not difficult to design.
At +2ERA and above, it is very difficult to predict. It may be possible to create a model that calculates the volatility for the last week to month and predicts the range of fluctuation by standard deviation, but it requires mathematical knowledge.
It is quite questionable how helpful this calculation would be, and it does not seem to be as useful as a future price forecast.
As I mentioned earlier, the next ERA would be sufficient as a reference value, since the threshold can be calculated from the current ASTR prices.
If we are considering more than +2ERA, we will need to provide a specific calculation method.
@you425
Thank you for this detailed explanation, You. Since this is not my area of expertise I am looking to clearly understand the whole system, learning from you is helpful.
as always, thanks for your reply. It is always nice to have your opinion and feedback.
IMO opinion, next era threshold is a good start but is far to be enough.
A project need a forcast of at the very least 1 week if itâs not 2 to get a sufficient amount of time to try to react to threshold fluctuation if they get close to lower Tier threshold. Especially if, like the passed weeks it increases at an insane rate thanks to drastic astr price drop and the recent update meant to add token emission rate in the threshold calculation (I do not have the exact value but threshold for T2 increased by about 10M within a month, this is insane).
We have to keep in mind that staking environemnt is completely locked between 2 voting period, thanks to the bonus system rendering mobilization of significant amount of ASTR to rise a stake on a dApp close to impossible. this is especially true since staker have, now, absolutely no interest to move their stake from a dApp to another to support a project in difficulty during B2E period as they will be financially penalized for doing so with the loss of their bonus.
As i already mentioned in another discussion the current bonus system is completely imcompatible with a dynamic threshold system, go against the philosophie of a community supporting projects through dApp staking and creat a 4 months stake&forget dynamic for stakersâŚbut letâs talk about that in another discussion)
To come back to the maine subject, an accurate prediction model is not necessarly easy to design for multi parameter systems, but here, we just need a thrend + a endpoint based on past & current ASTR value, threshold history and token emission.
The team already have the formula to claculate the threshold with those parameters + a 7 days price average which is currently used to damper the threshold fluctuation.
We already have everything at hand to get an easy 1 week trend forcast if we set the end point at current Astr value. If we update the curve at each era, after daily threshold recalculation, we will have our âweekly threshold trendâ
later, the accuracy of the model curve can also be improved by adding a 7 days average trend on token emission and another one for threshold value, if deamed necessary
However, I am not aware of a specific way to calculate the predictive threshold for dApps to use as a reference. Can you create actual simulations etc.?
I know that theirâs some explanation on the wiki but honestly I donât have time to recreat the formula that is already existing in the system.
It would take maybe 15-20 min to the core team to extract the formula and provide it in mathematical scripture while probably hours for me to recreat it based on the wiki with risk of missinterpreting the explanation and/or making mistakesâŚ
In addition, Iâm pretty sure that they have a model existing for trial and error update or parmeter twiiking
I agree that over the past month, particularly with the recent market downturn, tier threshold amounts have risen rapidlyâby ~15% for tier 2 thresholds in the last 30 days. However, itâs important to note that the new feature, where tier thresholds are calculated based on total issuance percentage, hasnât added any additional volatility. Even under the old static model based on TVL amounts, we observed a similar deviation in the last month. The moving average calculation on price, which acts as a âlaggingâ indicator, was designed to help attenuate drastic fluctuations, but it may not fully prevent significant changes during high volatility.
For now, you can use this spreadsheet as a quick tool to anticipate upcoming threshold amounts with the new v5.43.0 release (date is not defined yet, but probably in early September for Astar). Itâs a practical, temporary solution that should provide some visibility and help you prepare accordingly.
Also, Iâm investigating a modulation capping feature. This would limit how much threshold amounts can change in a single period, which could help stabilize the system further and prevent the kind of rapid increases weâve seen recently. Feel free to suggest other ideas.
Thanks for the breakdown. Totally get the marketâs been nuts lately, driving those tier thresholds up fast. The moving average helps, but yeah, itâs not bulletproof in crazy times.
The spreadsheet for the v5.43.0 release is a solid temp fix. Looking forward to that modulation capping featureâdefinitely need something to keep these spikes in check.
thx for the explanation and the file. I will look into it with interest.
The capping feature would indeed be of great help as it would give to all project a minimum amount of Astr that they should secure to be out of the wood for the ongoing/uncomming (during voting period) B2E periode.
Also, and I will repet it again and again and again, it is mandatory to implement a stake swap from a dApp to another without losing bonus, at least once during a B2E period to allow dApp staker sur support projects in need of it during a B2E. Because the static staking system created by the bonus is completely incompatible with the dynamic threshold system. And even with the proposed capping feature mentionned above, staker/projects need to be autorise to move (not unstake) their stake at least once without being penalized to make the system.
I agree with you regarding bonus rewards. I think there should be more flexibility.
Allowing conditional moving to other dApps would increase tier fluidity, and prevent dApps that join later from being unduly disadvantaged.
The penalty of losing bonus rewards for changing the voting location would be useful in itself, as it would make people more cautious about voting, but I feel that it is currently too severe.
Well, this is a different axis from the current agenda, so it might be better to discuss it separately.
I am interested in modulation capping. It seems like it could be a complex implementation, but I think itâs worth a try.
Also, I agree with enabling dApp staking migration without penalties during the B2E period. However, as for flexibility, I think there is room for consideration as @you425 has written. There seem to be several patterns for the migration method, so it might indeed be better to discuss it in a separate thread.
