[proposal] change the time frame of uptime and expected return on the staking dashboard

Web3 Staking
1

expected return
Expected return on the staking dashboard is calculated using the average of expected return snapshots over the last 30 elected epochs of a validator. This has become misleading since return has stabilized at a 10%-15% level and likely to decrease slightly moving forward. I would suggest we use the data from the past 10/20 epochs.

image
image728×568 44.3 KB

uptime
The most popular complaint is there is a higher chance of missing signatures during network transition (e.g. slot increase) and this surely will happen again in the future thus average uptime is not a good indicator. As Ionut has suggested, the Median uptime over the past 10-20 epochs might be a better measurement.

4 Likes
3

Well, frankly saying…this should have been changed at the very beginning to be based on the last epoch only so it would not mislead users into thinking first validators are in fact more profitable just because they started earlier. But since now we have transitioned to many epochs already, it will come to a time that eventually the expected return will pretty much the same as the last epoch return, so i am not entirely sure it is worth changing now that so much time has passed already.

Anyway, lowering the calcs from 30 epochs to 20 or 10 would still help at this point. So i would still vote for a yes.

1 Like
4

Thank you for the proposal Maggie! There has been strong community sentiment in favor of this since the early days of staking, therefore a strong Yes!

Could the team elaborate on the process that changes like these have to undergo to come to fruition? Many have struggled with it from pretty much epoch two, and a lot of voices have been asking for a change for a long time. It seems like such a minor change, but with a massive impact on sentiment and network health. Still it took a long time to even be considered.

I’m wondering:

  • Is the community is underestimating the work that need to put in towards the change?
  • Is it just a slow moving process?
  • Was the team aware but the issue had a low priority?
  • Can we, as a community, improve the communication of such things?
3 Likes