Staking operations reported 3 cycles late in endpoint v1/rewards/split

[p76dub]

Hi,

I was playing with the /v1/rewards/split endpoint and I noticed a small issue in the API response regarding the stakedBalance of delegators. It seems that (un)stake operations are reflected 3 cycles after they occurred. The issue seems present from the beginning (Paris C upgrade introducing staking). Since staking rewards are accumulated immediately, I would expect those operation to be reported also immediately.

Here are some examples:

• tz1StJMgCK7N6CSRw7BQJL4TcdcrRWJB4Xou staked its first 100k tez at cycle 827. Querying the /v1/rewards/split/tz1aRoaRhSpRYvFdyvgWLL6TGyRoGF51wDjM endpoint gives me the following staking balances:

  • cycle 826 (before staking 100k): no entry
  • cycle 827 (when staking 100k): no entry
  • cycle 828: no entry
  • cycle 829: no entry
  • cycle 830: 100090111901

• tz1QFyu5PHfNN1mZ4n5YWKyX5WcBimEs45distaked 10k more tez at cycle 822. Querying the /v1/rewards/split/tz1aRoaRhSpRYvFdyvgWLL6TGyRoGF51wDjM endpoint gives me the following staking balances:

  • cycle 821 (before adding 10k to previous stake): 42215077670
  • cycle 822 (when adding 10k to previous stake): 42266678864
  • cycle 823: 42314500409
  • cycle 824: 42373868100
  • cycle 825: 52901109973

• tz2H7ttWtVVA7dzSvCV4wXXjSwDN8EtK93oQ staked the first time at cycle 748 but again, stakeBalance is only updated at cycle 751.

Interestingly it seems that rewards are accumulated during this 3 cycles period, because for the last example the first reported staked balance is 1,000119 tez whereas the stake was 1 tez.

Just wondering if this on purpose :D

Thank you for your time!

[Groxan]

Hi! Thank you for the neat explanation! Yeah, that's a known specific of the cycle rewards entities on tzkt.

Cycle rewards were initially designed for delegation rewards, which are fully aligned with baking power/baking rights and therefore delayed by several cycles. Indeed, if you delegate to a baker in cycle N, baker's power will actually increase only in cycle N+consensus_rights_delay+1 (because at the end of cycle N the protocol, roughly speaking, will take snapshots of all delegated balances, forming baker's power, and based on it will distribute baking rights for the future cycle N+consensus_rights_delay+1, that is N+3). So, while your delegated balance doesn't increase baker's power (and therefore doesn't make "money"), the baker shouldn't pay you any rewards. Therefore, in the rewards split you see only those delegators who have actually contributed to your baking power and therefore deserve delegation rewards.

However, the situation with staking rewards is sligtly different, because staking rewards are paid automatically by the protocol to all stakers, regardless of whether they already contributed to baking power or not. For instance, if you stake in cycle N, baker's power will also increase only in cycle N+consensus_rights_delay+1, and until then your staked balance won't make "money", actually. However, since staking rewards are paid to all stakers, you start receiving them immediately, simply diluting other stakers.

So, all the balances in a cycle rewards entity are those balances that were used by the protocol to calculate baker's power and distribute bakign rights for that particular cycle. This is why all changes to staked/delegated balances are delayed. And this is why staking rewards, received during first 3 cycles, are not counted.

Yeah, the approach we used for delegation rewards is not really suitable for staking rewards.
But I have a good news: we plan to rework staking rewards accounting in the near future, that should fix all the issues :)

[p76dub]

Hi! Thank you for the detailed answer, I found a workaround to compute the correct staking balance (using stake/unstake operations provided by endpoint /v1/operations/staking. I also wasn't aware of the baking power increase being also delayed with staking, I learned something new :D

In any case, thank you for your work on tzkt, it's a fantastic tool and I will keep an eye on next updates.