[Staking] Validator rewards

[raulk]

The flip side of #1051 is validator rewards. To keep validators rational and aligned with correct behaviour, IPC needs to deliver cryptoeconomic incentives for subnet validation.

Framework approach

IPC as a framework should be fairly unopinionated by how and which rewards are distributed, as this will depend on concrete subnet tokenomics, especially in the presence of custom ERC20 subnet tokens. Our framework should allow subnet operators to configure, parameterize, and customize the reward mechanics. This implies design choices that favour modularity via hooks and user-pluggable functions and policies. We should provide one or several basic policy/strategies out of the box as quickstarts / examples.

Considerations

• Coin/token choice. Subnet operators should choose which coin/token rewards get paid in.
• Disbursement site. Can happen at the parent when checkpoints are presented (in which case they must carry a digest of proposers), or at the child (where more information is available and disbursement can happen immediately; handicap: we have no link between a validator and an account yet, but that needs to be fixed for #925 anyway).
• Vault. In both cases, since the subnet does not control the supply, there must be the concept of a rewards vault/treasury, and possibly the concept of convertible debt to handle continuity in case of temporary vault depletion.
• Vault transfers. Because subnets can be created dynamically, amounts in vault must be transferred down at subnet genesis, and any remnants back up at subnet EOL.
• Customizable reward function. Depending on the disbursement site, this may have access to more or less data. We should keep this agnostic of the concrete consensus algorithm (e.g. do not model rounds, since some consensus protocols don't have rounds).
• Vesting curve. Some protocols may want to keep some portion of rewards locked-up for some time, which may be forfeited or not if the validator leaves the network early. TBD.

[raulk]

@sanderpick @bigs @carsonfarmer @angelo-schalley-p @hannahhoward @boneyard93501 would appreciate your input here!

[boneyard93501]

Looks pretty good to me. Thanks for writing this up.

Couple things, bottom up:

• Vesting considerations are pretty critical and an operator should be able to to specify two schedules: one for stake, one for reward
• Disbursement and disbursement site: i'm probably misunderstanding intent but it seems to me that the most critical aspect of disbursement results from a subnets EOL. Seems to me that some specification on genesis would be suitable that way an operator could kill a subnet tree top down and (ideally) expect a bottom up "rollup" of disbursement. would take some extra work, though. regardless, the validator-account link is more than a tad overdue and 1599 availability is a welcome sight for sore eyes :)
• Vault: i get the idea of wanting to manage a gap/deficit contingency to ensure continuous operations but is seems pretty tough to work in an enforceable IOU system (not backed by some collectable collateral such as escrow).

[carsonfarmer]

Thanks @raulk, this is very much in line with our initial thinking, so great to see alignment there!

• Coin/token choice. Subnet operators should choose which coin/token rewards get paid in. For sure!
• Disbursement site. Can happen at the parent when checkpoints are presented (in which case they must carry a digest of proposers), or at the child (where more information is available and disbursement can happen immediately; handicap: we have no link between a validator and an account yet, but that needs to be fixed for Gas completeness (EIP-1559, base fee oscillation, gas premiums, block gas limit) #925 anyway).

Excellent, I think this proposal matches our thinking quite nicely.

• Vault. In both cases, since the subnet does not control the supply, there must be the concept of a rewards vault/treasury, and possibly the concept of convertible debt to handle continuity in case of temporary vault depletion.

The vault here is exactly what we had in mind, perfect. I'm ok with not handling debt at the expense of the possibility of temporary breaks in continuity, leaving ensuring this doesn't happen to the "application", but if there is a sound way to handle this (that doesn't add a ton of extra work), I'd also be in support of that.

• Vault transfers. Because subnets can be created dynamically, amounts in vault must be transferred down at subnet genesis, and any remnants back up at subnet EOL.

Yup.

• Customizable reward function. Depending on the disbursement site, this may have access to more or less data. We should keep this agnostic of the concrete consensus algorithm (e.g. do not model rounds, since some consensus protocols don't have rounds).

Yes please!

• Vesting curve. Some protocols may want to keep some portion of rewards locked-up for some time, which may be forfeited or not if the validator leaves the network early. TBD.

I do think this is going to be relevant for us, and likely other projects targeting customs rewards and issuance frameworks.

[sanderpick]

Great to see this. @raulk for timeline alignment, do you know where this sits on your priority board?