Rewards Tree Spec v7

Governance
1

Following some initial discussion on Discord, I’m proposing two changes to the rewards tree spec following the process for rewards tree changes:

  1. Count minipools in the beacon chain queue like active validators for RPL reward calculation.

  2. In case there is not a single eligible node at the time of the reward snapshot, RPL inflation meant for node operators goes to the pDAO instead.

Rationale

Beacon Chain Queue Minipools

Not counting these minipools creates a disincentive to bond reduce: For nodes with high RPL collateral and if the queue is long enough, node operators reduce their share of RPL rewards when they convert to a LEB8. But we do want people to bond reduce- we are punishing people for behavior that we want.

NO Reward Edge Case

In theory it is possible that no node qualifies for RPL rewards (for example if no node meets the minimum 10% collateral requirement). In this scenario, the spec calls for raising an error “because the calculation has excessive error”.

Sentiment Polls

Should minipools in beacon chain queue count like active minipools?
  • Yes
  • No
0 voters
Should NO inflation go to pDAO if there are no eligible nodes?
  • Yes
  • No
0 voters
4 Likes
2

Idle ramblings: just wondering if it makes more sense to send to burn address if no eligible NOs? Since we are talking edge cases, diverting 98% of inflation to an address may increase the sweetness of governance attacks/oracle manipulation; and if every NO is below 10%, the pDAO done f’d up bigly somewhere and should we really be giving them (ourselves) more RPL?

3 Likes
3

I have no preference here, because I don’t think it will ever happen. For me this is purely about removing undefined behavior from the spec, so that nobody has to worry about the case.

2 Likes
4

Strong support. I think pDAO>>>>Burn in terms of growth potential at this stage.

1 Like
5

The process says “If contentious, they should be run through our usual Snapshot voting process.”

Given current poll states I feel “Should minipools in beacon chain queue count like active minipools?” is not contentious and could be implemented. The second poll “Should NO inflation go to pDAO if there are no eligible nodes?” is on the edge of my comfort level – there’s a strong bias to yes, but “contentious” shouldn’t be a high bar (as of this writing, 26 yes and 4 no votes).

I’d like to dig into the problem(s) as seen by the current “No” voters to see if we can address it in situ, or if it would be better to remove that item from v7 and discuss further (would love to hear from @Uisce @ken @underwood @CryptoBarista).

Currently, if there are no eligible nodes, behavior is undefined. I’m guessing that’s not desirable to anyone? If so, is the issue where the funds would go?

Other possible definitions (beyond sending to the pDAO treasury) that make some sense to me:

  • Burn (essentially distribute to all RPL holders staked or not)
  • Ignore minimum for the period (note that this then has an edge case if no nodes have any stake… but then RP is truly non-existent so probably whatever)
  • Send to EF/Gitcoin/similar wallet
  • Lido treasury (taking epineph’s “we don’t deserve it” argument to the extreme)

I do want to emphasize that, like knoshua - I don’t think this will ever happen and we’re mostly looking to avoid the “undefined” fork’s existence more than create a policy that is likely to see the light of day.

2 Likes
6

I do not think it is worth any time defining logic for a scenario that should never occur, no eligible nodes would suggest a critical/malicious oracle error or complete breakdown in incentive structure.

There is no good way to handle such a scenario, sometimes things should just fail ungracefully.

1 Like
7

My suggestion: If there are no eligible nodes in this cycle; NODE inflation will be accumulated to the next cycle; I think this will not only comply with the agreement of 70% inflation to NODE, but also solve the problem.

1 Like
8

@underwood
The proposal requires like a line of code or two. This would be much more complex. And again – this isn’t expected to ever come up.

@Uisce
Interesting. I’m really just wanting to have an answer so we don’t spin up conversations about it anymore :stuck_out_tongue:.

1 Like
9

Beacon Chain Queue Minipools

Yes - because the stupid queue is stopping people from making new minipools. This lessens the blow and may properly incentivise more growth.

NO Reward Edge Case

pDAO > burn, because pDAO can use to improve protocol.

1 Like
10

Generally, I would suggest that instead of saying ‘let the implementor decide’, we should then say that the oDAO should not generate a tree for that interval.

Otherwise we have undefined behavior. As it stands now, I strongly suspect Joe’s implementation of treegen will divide by 0 and die. This is, of course, an implementation detail. If we wind up with multiple treegen implementations, the defacto behavior may be something worse.

Edit: Knoshua pointed out to me offline that the spec already has safety rails which would cause it to abort deliberately instead of implicitly.

Edit 2: Knoshua pointed out to me offline that the spec actually encodes a divide by 0, which we really should fix if we don’t supercede it with a change to send to the pDAO instead.

1 Like
11

Update and discussion on discord starting here.

3 Likes
12

I have officially compiled these changes (and a few other clarifications / fixes for Holesky) into this draft v7 spec:

If we are able to release a new Smartnode this week, I expect this to be the ruleset used for Interval 15 on mainnet. Ramana already has an implementation of it which has parity with mine.

2 Likes
13

As a note, I’ve added some supplemental clarifications / minor changes that will not affect Mainnet but were necessary for the upcoming Holesky testnet deployment to work, which are covered in the summary of the spec change notes but are repeated here for clarity:

  1. In the Time of Eligibility section, startTime is refined: if the value from RocketRewardsPool.getClaimIntervalTimeStart() is 0, use RocketTokenRPL.getInflationIntervalStartTime() instead.
    • This is just a safety precaution in case of an anomalous contract state during initial deployment; it was intended as a workaround for a contract bug that occurs when the first rewards interval occurs after Atlas has been deployed (which has been fixed).
  2. In the Collateral Rewards and Oracle DAO Rewards sections, the “epsilon” value used as an upper bound for errors during sanity checking has changed. Instead of the total number of minipools, it is now the higher of the total number of nodes and the total number of minipools.
    • This is needed for the sanity check to work properly when there are more Oracle DAO nodes than there are minipools on the network.
  3. Clarified in RPL Amounts per Group that if the amount of pending RPL rewards is 0, this block cannot be used for rewards submission and the user should just wait until the next interval rolls over.
    • This just ensures that if the interval time is set to a number below 1 day (which is the minimum for when RPL can be minted), the Oracle DAO won’t generate “empty” intervals.

None of these changes affect Mainnet so I don’t anticipate any concerns releasing them together with the rest of v7, but if anyone has any issue with them, let me know.