Add Rewards page

[rloomba]

display rewards for a specific cycle

similar to tzscan rewards page

• display cycle at top
• ajax request to load rewards data
• calculate reward from RPC, and factor in the fee
• paginate in case there are lots of rewards to pay
• use tezos node RPC commands to gather data

[rohitverma007]

Here's how I am planning on retrieving the delegator info via the rpc:

• Get first block of current cycle (which is the last block +1 of last completed cycle)
  /chains/main/blocks/head/helpers/levels_in_current_cycle
  Above command returns: {"first":262145,"last":266240}
• Subtract (4096*8) blocks from first block of current cycle to get the first block 7 cycles ago
  262145 - (4096*8) = 229377
• Use the computed block from last step, i.e the first block 7 cycles ago, to get delegate data:
  /chains/main/blocks/229377/context/delegates/<pkh>/delegated_contracts
  Above command returns an array of contracts
• Query each contract to obtain and display required info:
  /chains/main/blocks/229377/context/contracts/<contract_id_from_above>

Let me know how if I am missing anything

[rloomba]

@rohitverma007 there are some slight nuances to the baking process, there's a FAQ here that summarizes up the process pretty nicely: https://tzbake.com/index.php/baking-explained/

The delegation is made somewhere in the middle of the current cycle (3 days), if you remember there are 16 roll snapshots taken in each cycle, so depending on where the cycle is right now, the delegation may not be recorded in some of the previous roll snapshots of the current cycle. Now here it gets tricky, when baking rights are being calculated, one of these 16 roll snapshots is chosen randomly ! so if you are unlucky and one of the roll snapshots is chosen that your delegation is not recorded in , you would lose the profit of that cycle (3 days) completely.

Snapshots are taken every 256 blocks, and then one of those snapshots is randomly chosen, so I'm not sure just picking the first block of the cycle would be accurate?

I think it might be best to potentially split the reward logic into two parts(and maybe make this evident in the UI as well):

1. actual rewards received for past cycles
2. "predicted" rewards for cycles that haven't been backed yet. We could take an average of the balance over these 16 snapshots?

Re: 1, Is there an RPC endpoint to show what the actual rewards were for a previously baked cycle? or maybe it tells us which specific snapshot was used? Once we have that we can get the delegate data, and then query the required info from the contract

[rloomba]

Ok @rohitverma007 let's go with two pages:

• Index page, that includes cycle #, staking balance, block rewards, endorsement rewards
• Show page, as many details as we can fit