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.