Reward Account Selection for bakers

To improve the security and ease of public baking operations, we are kindly asking protocol developers to consider introducing the concept of a Reward Account designated by a baker. The protocol deposits all rewards (baking, endorsing etc) into this account, instead of the baker’s account.

Motivation

A public baker must distribute rewards to its delegators. This is done outside of the protocol, by regular transfers typically performed by reward distribution software.

It is common for public bakers to first send some amount of tez to an intermediate “payout account” that a payout engine has private keys for. There are drawbacks:

  • with a Ledger, the operation is necessarily manual, requiring opening the wallet app and confirming on-screen,
  • the baker has to strike a balance between frequency of transfers, either doing transfers at every cycle which is time consuming, or doing it less frequently with bigger amounts, putting more funds at risk in a hot wallet,
  • if the baker forgets or is unable to transfer funds to the payout account, the payouts are not going through, which leads to a poorer experience for delegators.

This proposal simplifies this flow: at the bakers discretion, the protocol directly deposits rewards to a payout account. This alters the operation of the payout engine: it distributes rewards to delegators, and the remainder goes to the baker’s account, potentially increasing its stake and deposits limit.

It also simplifies readability of rewards: for every cycle, it is expected that the balance of the reward account will be zero after the reward distribution has completed. This gives bakers and delegators more confidence that the reward distribution has completed and has been done fairly.

A simpler and more reliable public baking experience potentially increases the number of public bakers and delegators, which is good for decentralization.

Spec

New Operation

The rewards key is stored in a new column of the tables in the context storing current and pending consensus keys as of Lima protocol.

  • one main table storing the active rewards key of a baker,
  • and a second table indexed by baker and cycle and storing pending reward-key updates.

At the end of each cycle, the table of pending updates is traversed: reward keys that must be activated in the next cycle are removed from the pending reward-key table and inserted into the active reward-key table.

A new operation Update_rewards_key(<public_key>, <cycle>) with the same semantics than Update_consensus_key(<public_key>, <cycle>), lets a delegate record the public key hash of an implicit account. It will record the update in the pending reward-key table. It must be signed by the manager key of a baker.

At any time, a reward key can only be used by a single baker, the operation fails otherwise.

All rewards (baking, endorsing, nonce reveal, drain, slash, etc…) go to the currently active reward key.

If the reward key is empty, the burn fee is taken from the reward. Any kind of possible reward is above the burn fee so there is no edge case.

Migration

The proposed amendment needs to initialize the new column in the key table. It will iterate on all registered bakers (around ~2500) and set the reward key to be equal to the manager key.

The stake snapshots for the next PRESERVED_CYCLES are also reallocated. They now snapshot the consensus public key, the reward public key and the manager public key hash. Yet, the baking and endorsing rights are unchanged.

CLI Changes

New commands in tezos-client

A reward key can be changed at any point. This may be done with the command:

tezos-client set reward key for <mgr> to <key>

The current registration command still works:

tezos-client register key <mgr> as delegate

It is also possible to register as a delegate and immediately set the reward key:

tezos-client register key <mgr> as delegate with reward key <key>

Or even set the reward and consensus keys altogether:

tezos-client register key <mgr> as delegate with consensus key <ckey> and reward key <rkey>

The above commands send the Update_reward_key operation batched with the other operations.

RPC Changes

  • GET /chains/main/blocks/head/metadataThe block metadata is extended with the active rewards key of the baker and proposer. The field proposer and baker still holds the respective public key hash of the manager keys of the proposer and baker.
  "proposer_reward_key": "[PUBLIC_KEY_HASH]",
  "baker_reward_key": "[PUBLIC_KEY_HASH]",
  • GET /chains/main/blocks/head/context/delegates/[PUBLIC_KEY_HASH]The delegate data is extended with active and pending consensus keys.
{ "full_balance": "4000000000000",
  "current_frozen_deposits": "200000000000",
  "frozen_deposits": "200000000000",
  "staking_balance": "4000000000000",
  "delegated_contracts": [ "[PUBLIC_KEY_HASH]" ],
  "delegated_balance": "0",
  "deactivated": false,
  "grace_period": 5,
  "voting_power": "4000000000000",
  "active_consensus_key": "[PUBLIC_KEY_HASH]",
  "pending_consensus_keys": [
      { "cycle": 7, "pkh": "[PUBLIC_KEY_HASH]"},
      { "cycle": 9, "pkh": "[PUBLIC_KEY_HASH]"}
    ],
  "active_reward_key": "[PUBLIC_KEY_HASH]",
  "pending_reward_keys": [
      { "cycle": 7, "pkh": "[PUBLIC_KEY_HASH]"},
      { "cycle": 9, "pkh": "[PUBLIC_KEY_HASH]"}
    ]
  }

Protocol migration

The proposed amendment needs to initialize the new colum in the key table. It will iterate on all registered bakers (around ~2500) and set the rewards key to be equal to the manager key.

The stake snapshots for the next PRESERVED_CYCLES are also reallocated. They now snapshot both the consensus public key and the manager public key hash. Yet, the baking and endorsing rights are unchanged.

6 Likes

There is another way how Reward Accounts are useful to public bakers.

When a public baker is overdelegated, they may have trouble paying their delegators because baking and endorsing rewards are “clawed back” by the protocol at the beginning of the new cycle, as additional security deposits, before the baker has a chance to pay them out.

A known solution to this problem is to set the deposit limit to a lower value, so that there will always be some free balance to pay out delegators. But then, the public baker needs to periodically reevaluate the appropriate deposit limit, which is time consuming.

Having a reward account means that the rewards are always available to the baker. They pay out the delegators, then transfer the balance to the baker. The baker’s free space then grows incrementally and the deposits limit value no longer needs being set.

4 Likes

I love this, I hope this gets implemented

2 Likes

Love it! You should also request an inflation fee as compensation for your work

You should also request an inflation fee as compensation for your work

This is just a spec, mind you. Shall an independent dev take this on, I think they would be entitled to an on-chain invoice upon merging. (hopefully @G_B_Fefe is reading this :wink:)

Otherwise I hope the core teams see the value and are able to allocate some time to this improvement.

Great idea!

This makes total sense and reduces the fear of wanting to become a baker, since it reduces the fear of messing up your stake.

What do you guys think of eneabling an “automation” setting that would automatically distribute the rewards to all delegators. The baker could switch between the manual/automatic mode. Only thing that would be left is for the baker to specify the “fee”. This way, explorers would be able to monitor the current “fee” value of the bakers by crawling the blockchain.

Such a great, useful idea!

2 Likes

This idea is deceptively more complex than it appears. A simple fee on chain is not enough information for example. Who pays the tax fees? Who takes over delegation losses? (Baker and delegators or just delegators?)

When do they pay? We don’t want the chain to programmatically DDoS itself when everyone tries to pay at the same time.

I’m not again the idea but need to see all these things considered in a separate thread. Let’s not hijack this one.

2 Likes

Bakers already automate reward distribution and rating service are already able to measure their fees so what problem do you try to solve?

The automated reward distribution happens off-chain; enabling on-chain automation of reward distribution is something that has been discussed a lot in the past; mainly in the context of the “Programmable Staking” feature, a variant (see Enhancing Baking Accounts | Protocol Research & Development | METASTATE for the details) of the “Baking Account” feature (proposed in Florence but rejected because of a bug) which lead to the “consensus key” feature (proposed in Lima, the current protocol proposal), which finally lead to this proposal.

2 Likes

Bringing this one back…

In Oxford, there are now 3 baker parameters stored in the context: consensus key, limit_of_staking_over_baking and edge_of_baking_over_staking.

Let’s add a 4th parameter, rewards_destination, as described in the original post? Assuming Adaptive Issuance activates, this will only direct rewards from delegation, not rewards from staking which will be handled in-protocol.

The arguments I initially brought up still apply. Plus:

Adaptive Issuance is great for bakers because they no longer have to run a third party software to pay rewards from staking. But they still have to pay out rewards from delegation with a third-party software.

They might just stop doing that and instead, opt for being a staking-only baker. But we’d lose an important facet of tezos governance in the proces, if this happens.

rewards_destination makes public baking easier, removing the requirement to periodically move funds from the offline baking address to a hot third wallet used for payouts from delegation.

The easier baking is, the less likely people will stop paying rewards from delegation.

2 Likes