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
2 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?

1 Like
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.

4

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

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.

1 Like
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.

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.

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:.

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.

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.