Enriched staking metadata exports #785
tinker-michaelj
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The Hedera network pays staking rewards using an opportunistic mechanism defined by HIP-406. When an account is involved in a transaction that changes its staked amount or staking metadata, it automatically receives any rewards it has earned from the
0.0.800
account.This means we cannot interpret the
0.0.800
balance as the amount of staking rewards that could still be earned in the future. We have to recognize that part of this balance is reserved for staking rewards that are already earned, but not yet paid. Furthermore, only the unreserved part of the0.0.800
balance at the end of a staking period affects the reward rate that will be paid for that period; c.f. HIP-782.In principle, anyone can compute the reserved rewards by iterating through each account's staking metadata and computing
its pending rewards. By tracking the end-of-period
0.0.800
balance and current network properties, they can then computethe unreserved
0.0.800
balance and the HIP-782 reward rate for that period. But this is an exorbitant amount of work, and consensus nodes could just as easily expose all this information directly to mirror nodes via the end-of-periodNodeStakeUpdateTransactionBody
transaction.Hence we propose adding four fields to the
NodeStakeUpdateTransactionBody
transaction:reserved_staking_rewards
- the total staking rewards earned but not collected at the close of the previous staking period.unreserved_staking_reward_balance
- the funds available for future staking rewards at the close of the previous period.reward_balance_threshold
- as defined in HIP-782.max_stake_rewarded
- as defined in HIP-782.We recommend that relevant mirror node APIs (such as the Hedera public mirror node endpoint
/api/v1/network/stake
) expand to include these new fields.Beta Was this translation helpful? Give feedback.
All reactions