Easiest way would be to just consider the amount of astr locked in staking for each wallet at the beginning of B2E periode, whatever the dApp it is staked on. If astr locked drop bellow this value during B2E period, complet bonus would be forfeited. In this fashion, locked astr could be moved from a dApp to another during B2E periode without penalty on the bonus. Honestly, I feel that the “give weight to the choice” is now, with dynamic threshold, completely outdated. But if the team absolutely want to continu to push on what’s now an archaic feature (sorry guys but if you puch for evolution, you need to accept also that side effects need to be addressed too), a cool down period of X days can be set up to prevent moving stakes from dApp to another too often (it will however be more complicated to code)
That’s good. If I may, I’d like to ask a few more questions.
As we understand, the price of crypto tends to fluctuate quite a bit, both on the upside and downside. How does the team plan to address this volatility in order to maintain stability in the long term?
The formula covering how the price change impacts other variables can be found here. Price change directly impacts number of slots, which then impacts how the thresholds move/adjust.
I’m not sure which formula is missing from the docs, but if some is we’ll add it.
For the system as a whole, I would say it’s working as intended. We could adjust the window length of the moving average window, that would ease up the changes in the thresholds a bit. BUT it works both ways - now ASTR is on the upwards trend so the thresholds would get reduced at a slower rate.
I made a (few) very lengthy posts explaining philosophy of the developer rewards and the requirement behind TVL requirements. It’s also stated (in the docs I believe) that devs should do their best to maximize their TVL.
I won’t comment on these things again as I’ve got nothing new to say.
For the suggested prediction tool, I’m not sure that our UI team currently has capacity for that. But it sounds like a good community project that could be reimbursed via treasury proposal.
Thank you!
I believe Base native currency price was implemented to address a bug that occurred when Oracle was implemented previously. I don’t think there is any mention of this in the documentation, so I think it is necessary.
I also agree that keeping dApp staking bonus while moving from one dApp to another dApp (at least once partially or fully) would be a great flexibility and plus in general for the stakers. I am sure it is not intended but keeping the staked ASTR fixed over the course of the build&earn subperiod seems to limit staker activity, aside from occasionally claiming rewards. Making it flexible will give the stakes more choices and support during the build&earn subperiod, for example, to support newly joined dApps.
I agree, but I don’t know how we can ensure this.
Although I see people who want to develop many projects from time to time, the impotence at the threshold and in the market makes it difficult for them to make decisions for the future.
I will follow the comments and I will be positive about the developments in this field.
I’ve used the spreadsheet to produce graphs showing threshold value based on ASTR price. This give a fairly good approximation of the threshold evolution range.
However, I’ve seen that spreadsheet also use token emission as a variable parameter but i do not understand well what impacts token emission and in which way.
would you mind taking the time to explain this to me?
Thanks for working on this—it sounds super interesting and could be a valuable resource for the community! When you mention “token emission,” are you referring to the “total issuance”?
The inputs in the spreadsheet are:
Total Issuance - This represents the total amount of Astar tokens (ASTR) in circulation. Total issuance grows over time due to inflation. You can read more about how inflation impacts issuance in this section of the documentation. The current value can be found in the Astar portal.
The Average USD Price of the Astar token - This is calculated using a moving average of ASTR prices, stored in what’s called a “circular buffer.” Right now, the only way to access this moving average value is by querying the chain state on Polkadot’s portal. Here’s how to do that in a simple way:
Select priceAggregator as state query, and valueCircularBuffer.
Regarding price, using 7 days average do not give any interesting information to predict futur threshold (we can BTW see the result on Astar Portal as it is the current threshold). However, using current price (on Coingeko for instance) allow us to calculate futur threshold value if price stay stable for 7 days (which give the trend of the threshold variation ie. up or down, toward this futur value)
Your point seems contradictory. You reference the current price but assume it has remained stable for the last 7 days—but that assumes stability, which isn’t always guaranteed in volatile markets. Using a 7-day moving average, as already highlighted in previous comments, smooths out short-term volatility and provides a more reliable trend indicator.
If you’re suggesting a different methodology, such as comparing real-time trends against the moving average to better capture short-term momentum, it would be helpful to clarify and propose a concrete solution.
I was only commenting that in the framework of creating my trend graph of threshold evolution as a visual tool for futur threshold calculation and did not meant to modify threshold calculation in the system… sorry for the missunderstanding
In my reasoning :
last 7-day average (which is used to calculate current threshold value) serve as the trend starting point
current price on coingeko (which is used to calculate forcasted threshold value in 7 days) serve as the trend endpoint
this second point consider the threshold value we would tend towards if price stay stable for 7days
Of cours this method induce inacuracy as forcasted threshold value will depend on market variability, but will give a good indication of what could be the treshold in 7 days.
In period of high volatility, a “Last 4h to 12h average” could be used to smoothen the fluctuation value for the trend endpoint
but if the trend is updated once or twice a day is won’t really matter as the utlimate goal is to give an indication of toward where the thresholds are going (up or down) and up/down to what value.
if we really want to add precision, we could add in between points which could be based on 3-day average and 24h average for instance then perform a simple linear regression on those 4 points (threshold caluclated with 7day, 3days, 24h average and current value) to establish trend slop and end point in 7 days
