RPL Staking Rework Proposal

Valdorff · 24 August 2023 17:25

All right folks – discussion has slowed to a gentle simmer both here and in #research. I’m going to put up two polls:

Sentiment poll – please vote
A specific question about the formula – vote or ignore as you wish

Sentiment poll

Support moving to vote; I think this proposal is great!
Support moving to vote; I think this set of documents is “good enough” and we shouldn’t let the perfect be the enemy of the good
Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
Oppose moving to vote; other
Undecided; I have a specific question I’d like clarified in the comments below
Undecided; other

0 voters

Formula preference

Natural log variant
Piecewise linear

0 voters

Gory formula details

Either way we’re talking 0 weight below 10% pETH ratio. Then:

Natural log variant
weight = (13.6137 + 2 * ln(100 * (staked_rpl_value_in_eth / borrowed_eth) - 13)) * borrowed_eth

Piecewise linear variant
weight = rpl_stake_from_0-15% + .75*rpl_stake_from_15-17% + .5*rpl_stake_from_17-20% + .25*rpl_stake_from_20-30%

See also, discord for plots showing the total rewards, marginal aprs, and overall spending pie chart.

m3thos · 25 August 2023 12:09

please separate into terms, makes it human readable, compiler can optimize the math
thanks

that term based formula makes me happy enough

m3thos · 25 August 2023 12:13

i really like the simplicity of your approach.
my math brain wants another dropoff after the 0.3/25% for 12.5%

the downside of this formula is “noise” in rpl rewards due to high variance of rpl/eth ratio, so it makes it harder to predict how much NO earns at the rewards period

adorableraccoon · 28 August 2023 21:19

I agree, this should be voted on.

SohoJoeEth · 2 September 2023 05:25

Hey @Valdorff, I really appreciate the effort to fix the current system. But for me, the elephant in the room is that as a NO’s, I don’t want to speculate on RPL.

RocketPool has a beautiful value prop of a low friction decentralized was to stake with a small upside vs solo staking. Why are we screwing around trying to force RPL into the mix. For me, I would rather we allow NOs to use rETH as the bond and then split the fee with the protocol like LIDO does.

Darkmessage · 2 September 2023 16:58

We are not, though. RPL is already in the mix. We just distribute existing RPL inflation differently.

Valdorff · 2 September 2023 22:19

This proposal is a much smaller scope. It’s not reimagining the role of RPL, simply saying “how can we best leverage the RPL we already spend on NOs to achieve protocol goals.”

The specific thing you’re suggesting doesn’t work math wise. 9-day old math said if we took 100% of all revenue (leaving zero for Node Operators) we’d cover just over 80% of the monthly revenue for oDAO and pDAO. Obviously zero rewards for NOs is untenable. It would also entirely destroy the value of RPL, which is also untenable (per the pDAO charter it shouldn’t pass, and it certainly wouldn’t).

I think there’s more realistic variants that are definitely worth exploring/refining, eg, Draft Proposal: Expanding Rocketpool's Market Reach with No-RPL-Bonded Megapools. I don’t see that as interacting much with the proposal on this thread.

Valdorff · 3 September 2023 12:23

Hi all – PR to finalize this RPIP is live at rpl_staking_rework_finalizing by Valdorff · Pull Request #70 · rocket-pool/RPIPs · GitHub. (link to full RPIP)

Please review. I plan to have this up 2-3 days to allow folks to review before requesting that this RPIP be finalized.

Changes from the long-standing draft posted here

Explicitly noting that tree spec is still mutable exactly as before

A new section showing the terms broken out for the equation per @m3thos’ request.

NonFungibleYokem · 3 September 2023 13:13

One potential issue in the withdrawal process: It seems to be possible to end up withdrawing below the 10% minimum. Ie, 1) Node operator is at 25% collateral, 2) Operator requests withdrawal of enough absolute quantity of rpl to reduce to 15%, 3) After 28 days, the price of RPL had fallen enough that the withdrawal of that absolute amount would take the operator below the 10% minimum threshold.

There probably should be some logic that says - the withdrawal request is an ‘up-to’ amount. At the time the withdrawal gets executed, the amount of rpl to be withdrawn is only the ‘up-to’ requested amount, or however much would take the operator down to the 10% level at the price at that withdrawal time.

Valdorff · 4 September 2023 02:49

So the way I’m seeing this is that the “friction” we’re including is the cost of missing one reward period plus the cost of price risk during that period. From the protocol point of view, that friction is being added even if folks can go below 10% in an extreme edge case. More or less “we checked that it was ok when you started withdrawing – at that point the protocol has approved letting it go, we just have a little delay”.

Pieter · 4 September 2023 08:38

Agree with this reasoning, especially as RPL in the withdrawing state already does not count as effective anymore for rewards and voting purposes. So from the protocol POV, it’s already unstaked at the moment of initiating the withdrawal process.

Patches · 27 October 2023 14:49

Gov Stuff

I’ve generated a rewards tree using the proposed formula for target interval 15 which ended a day ago. Attached you’ll find the tree, along with a csv showing how each node’s rewards would have been different if this proposal had been enacted before interval 15.

Click here for the rewards tree
Click here for CSV summary

Once downloaded, you can search the CSV for your node id to find your personal impact. You’ll need to lowercase your node id first.

For example:

node	interval15rewards	proposed	factor	delta
0x18845fd4aa047d6d43c934cc37aca94f85def683	25.0122713590862	21.3127893045889	0.852093318460127	-3.69948205449725

This is my node. In interval 15 I received 25 RPL of rewards. This proposal would reduce that to 85%, or 21.3 RPL, which is a difference of -3.7.

On the balance, I’m in favor of measures to make inflation impel growth, so I’m leaning in favor. However, I’m sensitive to the notion that some people may feel rugged.

node	interval15rewards	proposed	factor	delta
0x17fa597cec16ab63a7ca00fb351eb4b29ffa6f46	6023.22623367632	3373.75553590557	0.560124326236104	-2649.47069777075
0xca317a4eccbe0dd5832de2a7407e3c03f88b2cdd	2142.75795001593	974.570809890287	0.454820764931962	-1168.18714012564
0x895f6558f0b02f95f48ef0d580ec885056dcccc6	1808.81809820746	778.456936814446	0.43036772884233	-1030.36116139301
0x7c5d0950584f961f5c1054c88a71b01207bf9cb7	1808.81809820746	778.456936814446	0.43036772884233	-1030.36116139301
0xacb7cfb56d6835d9e2fa3e3f273a0450468082d9	1808.81809820746	778.456936814446	0.43036772884233	-1030.36116139301
0x663cbbd93b5ee095ac8386c2a301eb1c47d73aa9	1808.81809820746	778.456936814446	0.43036772884233	-1030.36116139301
0x22ffba127f6741a619fa145516ef4d94b90f093a	1417.00027016498	406.753997115619	0.287052871957646	-1010.24627304936
0xb8ed9ea221bf33d37360a76ddd52ba7b1e66aa5c	1549.03842573998	765.819471099213	0.494383779236064	-783.218954640764

These are the biggest losers by total swing. It’s a mix of whales whose support the protocol has benefited from. They can mitigate their losses substantially by migrating to leb8s, but I would like to hear from them to understand why they haven’t already done so, and in general to get their opinions.

At the top we have @thomasg followed by an anon, then patricio and marko’s nodes, and some more anons.

node	interval15rewards	proposed	factor	delta
0x2fc184459069dc780b478f7e3c9ffd79e40842a3	449.767509478073	770.649998412312	1.71344079368161	320.882488934239
0xfd0166b400ead071590f949c6760d1ccc1afc967	371.75691749514	677.058729081032	1.82124043216999	305.301811585892
0xd91eecc267ff626399798040d88de62c9e70acf0	359.930169559552	655.519377559656	1.82124043216999	295.589208000104
0x84ba027280cc6cc1e592a01270c5f21a494f46cb	291.487883004815	530.869518016004	1.82124043216999	239.381635011189
0xacfad9f0d80f74ad7e280a55ea025f4f09844b0f	271.330533561145	494.158138203814	1.82124043216999	222.827604642669

These are the five biggest winners. Unsurprisingly, they have leb8s and are closer to their borrow limits. Interestingly (for me, anyway), 0xfd0166b400ead071590f949c6760d1ccc1afc967 - click here reprises his role as a governance subject. See my last post about him - click here.

Not that the impetus to exit to stay above 10% is a function of the rewards power curve, but I do worry this change will reinforce that behavior. 0xfd01 has exited over a third of their minipools to stay above the 10% collateral threshold, which has kept them in the “sweet spot” on the proposed curve to maximise their rewards. I wonder if there shouldn’t be a mechanism that ramps the rewards power up after 10% creating a local maximum at the collateral rate we consider to be an optimal balance between security and capacity before decaying. As it stands, with this proposal, a node operator skating by at 10.00% will be in a position we have financially defined as borderline undercollateralized, but still receiving the maximum rewards power.

That’s all for my ambling.

Tech Stuff - skip this. please.

Methodology - click here

This proposal includes a ln(), which, obviously, is feasible. The problem comes in the standardization. Treegen is primarily a specification. Specifying integer math was fairly straight forward- you say that the integer container size is unbounded, you specify the order of operations, and everyone gets the same result.

ln() presents more of a challenge, and will likely need to be approximated. Because floats are stored in a representation of s(2^x)*y, a log2() transformation may actually be easier to specify. However, for ease of implementation, I’d suggest what Val originally suggested to me when I complained about this: a LUT which approximates the desired curve.

The curve is actually 3 dimensional, so the simplest LUT would be one that takes a decimal value for staked_rpl_value_in_eth / borrowed_eth (ie where the number of sigfigs is preordained, see below) and simply returns the weight. We can set a reasonable upper bound on the input (because nobody is likely to care about rewards growth above, say, a quotient of 20). The LUT itself will likely need to be generated not by hand but by machine and stored in a way where implementors can trivially convert it to a compile-time constant value in the language of their choice, well-optimized for interval queries.

A interval tree - click here comes to mind, but there’s more efficient options: We can quantize the inputs- That is, say your input to the function to 3 sigfigs is 0.789, but we quantize to 2, 0.79, and the LUT has fidelity to 2 sigfigs. In this case a simple array provides O(1) lookups, an improvement over a tree’s O(logn) complexity.

And that’s all for my rambling!

Edit: Any of the people I called out as wanting to hear their opinions (thomas, etc), I can make myself available to do more analysis and discuss. Happy to rerun treegen for hypothetical scenarios (eg, what happens if you migrate to leb8s, or exit N minipools, etc)

waqwaqattack · 27 October 2023 14:56

Summary

I’m starting to get a very bad feeling that this vote is going to be a bitterly RPL heavy vs minimal collateral divide, and I fear it’s going to get ugly.

We just voted to enfranchise people who would not have been able to vote on this, and they will almost certainly vote for the changes. This is going to cause a massive amount of tension, and it is likely going to be used as a point to strongly criticize the pDAO for those who are RPL-heavy.

I am hiding my previous statement here because I don’t think it sets a good tone for the vote.

Valdorff · 27 October 2023 16:59

I heavily dislike this framing. Makes it sound like someone is being asked to self sacrifice, which I don’t believe is the case at all.

People who are RPL-heavy (myself included) rely on the protocol doing well long term (in this case, read: growth). I believe what’s best for the protocol is best for my bags. I believe this proposal significantly improves the protocol’s growth incentives. I do believe there’s a tradeoff between “what percent of the pie do I get” and “how big a pie do we get”. That said, I think this proposal gets me a bigger piece of pie by growing the latter more than enough to make up for the former.

Please keep that in mind when comparing before and after RPL rewards. 1RPL != 1 RPL, if we’re talking about different contexts with different growth expectations.

hansgruber · 27 October 2023 19:44

It’s hard for one to appear unbiased when one stands to “benefit” from this proposed change. This would lead to a significant uptick in RPL rewards for my node.

That said, it does seem a good faith effort to grow the pie. Every NO we keep from exiting, that moves to LEB8s, or that we gain from this proposed change…one way or another…grows the pie. At the same time, it lessens the lead that the majority LST provider has…which in turn means a better, stronger network for all participants.

If I’m on the other end of this and am “losing” rewards for the potential long term growth…it would be a much harder pill to swallow.

endressb · 27 October 2023 20:29

I’m a highly collateralized eb16 operator and I am in favor of this change.

This would incentivize me to migrate to an leb8. The minor hit I take on further RPL rewards is still worth it as I believe the ratio will increase faster, allowing me to hit my ETH target sooner and end my speculation of RPL. This also aligns with the purpose of RP.

+1

toad · 28 October 2023 01:07

Appreciate the analysis Patches. As a smaller operator, I’m in favor of these changes (obvious win-win for those with smaller stakes). I do hope that those who stand to see a decrease in their monthly rewards can see the long term benefit to the protocol.

ramana · 28 October 2023 05:37

I have one major problem with the change as currently proposed, as far as I understand it: the proposed change does not allow a node operator to rebalance their RPL and minipool stakes to maximise their yield without significant delay. I think this is unfair because it punishes node operators who were maximising their yield previously, and encourages a full exit and reentry which is a waste of time and gas if they want to rebalance. Can we remove this restriction?

To clarify what I am talking about, consider a NO with 150% of their borrowed ETH staked as RPL who, after the change, wants to unstake their RPL down to 15% and convert the rest to minipools. Compare this to a NO with 15% staked RPL and the same amount of RPL as the other NO in total (the rest simply being held unstaked). The second NO can simply immediately spin up the additional minipools (and additional RPL stake as necessary). The first NO must wait for at least 28 days to achieve their desired allocation. Why? I don’t know. I just see it as a punishment for no good reason so far. Prove me wrong.

ramana · 28 October 2023 05:41

Could this 10% threshold be configured at the time of withdrawal request?

Shokus · 28 October 2023 06:58

In principle, I am agreeable with the proposal.

However, I think keeping the optimal RPL collateralization range at 10-15% is too narrow. As advertised, most NOs will target the 10-15% range as it will provide the highest RPL reward yield.

This can be easily seen when compared to the current situation. At present, all effectively staked RPL give an equal yield. Using this graph:

RPL Restaking Model

One can easily see that with this proposal, the new highest RPL yield will be at 10-15% collateralization range, dropping down to sub-100% (decreased RPL yield compared to today)

I would suggest expanding this optimal zone to 10-50% for the following reasons:

NO stability

10-50% would give NOs the ability to collateralize at 50% while still earning the best RPL yield for themselves. In this situation, even should RPL/ETH drop by 80%, such nodes will remain 10% collateralized and be eligible for rewards. I would like to remind everyone that RPL/ETH dropped by 69% within this bear market alone.

RPL/ETH price stability

With such a narrow range, NOs will be encouraged to min-max their collateralization ratio at every monthly snapshot. There would be increased price volatility which is discouraging to new/potential NOs to join.

These boil down to the fact that RPL/ETH is volatile, and a broader collateralization range will reflect that reality better.