APR computation methodology

This is a topic to discuss the current APR metric that is exposed by the Rated API.

Context

It seems that the current implementation does not take into account the age of each key in a group of key. For example, when looking at the APR value for 30 days, in the current implementation, if a provider has 1 key staked at day - 30, and 99 more keys staked at day -1, the computation will use the sum of rewards of the 100 keys in the last 30 days. As a result, the 99 recently activated keys which were active only for 1 day, will have 1/30th of their APR in the last 30 days, and lower the APR of the group.

This means that looking at a provider which has an increasing number of keys, will show an APR smaller than the reality. When unstake semantics will happen, it will be the opposite: some providers with decreasing number of keys will have an APY higher than reality.

Possible improvement

One possible way to approach this is to extrapolate the APR of each key individually to the period of the APR, then ponderate it to the age of the key. If we take the previous example, we’d compute individually the APR of the 99 keys for 1 day and extrapolate this to 30 days (“as if” they had been live for 30 days), then ponderate so that their contribution only weights for the period they were active. Because the 99 keys were active for 1 day, their contribution is “99 x 1 day”, while the single key has a contribution of “1 x 30 days”.

A more formal way to express this:

EXTRAPOLATED_REWARDS_PER_KEY_30D=SUM(rewards 30d) * (30d / MAX(30, KEY_AGE_DAYS))
APR_PER_KEY_LAST_30D = (32ETH + EXTRAPOLATED_REWARDS_PER_KEY_30D) / 32ETH * (365/30) * 100
APR_GROUP_OF_KEYS_30D=SUM(APR_PER_KEY_LAST_30D * KEY_AGE_DAYS / 30) / SUM(KEY_AGE_DAYS)

This formula uses ‘day’ but it’s possible to do it precisely by using exact durations.

There are likely other possible approaches here, happy to have your thoughts!

5 Likes

@mxs You are right the current calculation is quite crude: it is rewards over active stake and doesn’t take into account stake maturity.

Your proposed change makes sense and is an interesting one. That said, given that base rewards are (marginally) decreasing as more validators join, it will eventually skew towards operators with shrinking validator sets (that is because base rewards in day 0 will be larger than those in day X in a window).

An alternative would be to only consider keys that have been active for the full period.

Both should work, I will let others weigh in on this.

Thanks for kicking off this discussion!

3 Likes

great to see you here @mxs

I like both approaches in absolute terms as they both improve the accuracy of the APR% calculation, in equal measure. now in terms of moving to prod, as a rule, we always prefer opting for the lighter, least complex version of methodologies—especially when the accuracy or net improvement thereof they achieve is equivalent.

for that reason, I would prefer going with @ariskk’s suggestion.

1 Like