LEB8 discussion thread

This thread is for discussion of RPIP-8, the proposal for 8-ETH Lower ETH Bond minipools (LEB8s). Pull request is at https://github.com/rocket-pool/RPIPs/pull/4.

For quick clarifications or particularly noisy back & forth, please consider using the active discord thread instead.

7 Likes

Thanks @Valdorff for the great RPIP. I compiled the below notes while going over the proposal.

RPL stake required is based on Protocol ETH

In order to require a NO to have 10% of matched Protocol ETH in staked RPL value, we need to now store total protocol ETH used on a per node operator basis. This is easy to calculate going forward, but we currently don’t track that for past minipools so we will need some migration path.

Simplest way to handle this migration is to make the following changes:

  1. rocketNodeStaking.getNodeMinimumRPLStake checks the new “Node Operator’s matched Protocol ETH balance” (matchedETH) value. If it is equal to 0, it then queries rocketMinipoolManager.getNodeStakingMinipoolCount for the node and multiplies the result by 16 ETH. That value is then used in place of matchedETH for the purposes of calculating the minimum RPL stake.
  2. rocketMinipoolManager.incrementNodeStakingMinipoolCount should do a similar thing as above. If matchedETH is 0, calculate the correct value by multiplying active minipools by 16 ETH. It should then store that value into the matchedETH storage. It can then also increase matchedETH by minipool.getUserDepositBalance().
  3. rocketMinipoolManager.decrementNodeStakingMinipoolCount should to the same as above, but it should decrease matchedETH by the user deposit balance instead.
  4. getNodeEffectiveRPLStake, getNodeMinimumRPLStake, and getNodeMaximumRPLStake on rocketNodeStaking should all be updated to feature similar backwards compatibility logic.

This works because all previous minipools have (half) or will (full) take 16 ETH from the protocol. And in the case this is the NOs first minipool, this calculation just results in 0 which is the correct value anyway.

Reward tree generation should be unchanged as calls to rocketNodeStaking.getNodeEffectiveRPLStake will return the correct value for pre- and post- migrated Node Operators.

Snapshot voting does not take into account effective RPL stake below the minimum requirement. This is because it uses RocketNodeStaking.getNodeEffectiveRPLStake() which does not return 0 if the NOs RPL stake is below the minimum threshold.

Breaking delegate rollbacks

The upgrade to LEB8 supporting delegate has to be a one way ticket. Otherwise there are attack vectors in upgrading, migrating to an LEB, then downgrading. For this reason, we will have the migration to an LEB “break” the state of older delegates such that downgrading results in a non-functioning delegate.

We create a new rocketMinipoolDelegate which contains some migrateToLEB method. Calling this method sets the existing userDepositBalance storage slot to (2**256)-1. It stores the correct value in a new storage slot which takes the name userDepositBalance. The new distribute method reads the new correct value. Whereas rolling back to the old delegate would now result in the NO not receiving any of their ETH back if they call distribute.

Handling existing rewards

This problem is decribed in more depth in my post here: Design decisions for LEBs aside from collateral requirements

In short, we need a way to handle rewards accrued up to the point of migrating to an LEB. As there will be undistributed beaconchain rewards that are owed to the NO at the existing collateral ratio. Seems like most people agree that a merkle tree solution is the way to go. The decision remains on whether we do a single “line in the sand” tree or something more like Ken’s idea of including the migration data in each reward period merkle tree for some period of time (12 months).

Credit system

Calling migrateToLEB would perform a further call to a new method on rocketNodeManager called increaseNodeETHCredit. The method increases the amount of credit the NO can draw from when deploying a minipool.

During a call into rocketNodeDeposit.deposit, this credit balance can be decreased to top up any shortfall in ETH supplied via msg.value. The ETH must be available in the deposit pool at the time of deposit.

If a NO’s credit falls below the minimum required to perform a deposit, I think allowing them to refund that amount is desirable (thanks Knoshua for this idea). This involves a new method called withdrawDustCredit on rocketNodeManager.

New commission rate

The upgrade process can set “network.node.fee.minimum”, “network.node.fee.target”, and “network.node.fee.maximum” to 14%.

Should a minipool that migrates to an LEB have its node fee reset to 14%? This would require updating “node.average.fee.numerator” for the given NO.

Distributor upgrade

Currently, the priority fee/mev distributor contract assumes a 50/50 split of user and node funds. We will need to upgrade this to support LEBs that no longer meet that assumption.

We run into the same issue we did with varying node fees per minipool. ETH rewards simply appear in the distributor contract so we do not know from which minipool they were contributed.

There are 2 ways I can think to handle this:

1. Averaging supplied ETH collateral ratio

Similarly to how we average the node fee across minipools, we average the collateral ratio. This would mean keeping track of the sum of all matched Protocol ETH and NO supplied ETH on a per NO basis. Then during distribution, we use this ratio when splitting rewards.

rocketNodeDistributor.distribute would change from something like this:

halfBalance = balance / 2
nodeShare = halfBalance + (halfBalance * averageNodeFee)
userShare = balance - nodeShare

to something like this:

collateralRatio = protocolSupplied / (nodeSupplied + protocolSupplied)
userBalance = balance * collateralRatio
nodeShare = (balance - userBalance) + (userBalance * averageNodeFee)
userShare = balance - nodeShare

2. Separate distributor

With a separate distributor for LEBs, we could keep precise track of which minipools contributed rewards. Regular minipools would set their fee_recipient to the current distributor which does a 50/50 split and LEB minipools would be set to send rewards to a different distributor which does the 25/75 split.

This is more accurate but requires an additional contract deployment per node operator and requires the smartnode to be able to set a fee_recipient per validator which is not as robust and brings about more complexity with some smartnode setups.

Minipool queue overhaul

The current minipool queue is designed around having 3 distinct deposit types (half, full, empty) and items are dequeued in series. E.g. all half minipools are assigned first, then only after all half pools are assigned, the full queue starts to get assigned.

This queue system no longer works as we will want to have both 16 ETH and 8 ETH pools in the same queue. Since deploying we have also removed both full and empty minipool types so it makes sense to overhaul the queue system to support the new design and remove the unused stuff.

For this, we can create an entirely new queue which can take both 16 ETH and 8 ETH deposits (as well as any other future amount). During _assignDeposits on rocketDepositPool, we now simply dequeue a minipool from the global queue and call userDeposit on the minipool with the value calculated as 32 ETH minus the value returned from rocketMinipool.getNodeDepositBalance. This now supports any node deposit amount we may decide to add in the future including variable amounts.

Of course, we need to service the existing queues too as they will likely have minipools waiting to be assigned at the time of the upgrade. So _assignDeposits would check if the old queues have any items and assign them before moving to the new global queue. In some future update we can remove the old queue code entirely for some marginal gas savings.

Misc notes

  1. RPIP-8 mentions “Migration from higher commission minipools SHOULD be prioritized if there is any kind of queue for migration”. Migrating an existing minipool happens immediately by way of refunding the difference to the NOs credit balance. There is no queue to migrate. However, if there isn’t enough ETH in the deposit pool, the NO may not be able to make use of the credit balance until further ETH deposits are made.
  2. Minipools with < 32 ETH balance should be prevented from migrating to LEBs.
1 Like

Yes, that was the intent - migrating would include a commission change to 14% regardless of previous setting.

I think we’re on the same page here, but want to check. If I have 1 minipool, I could immediately migrate it to an LEB8. I would also receive an 8ETH credit, which I could use for another LEB. Using that credit would go through the standard queue, just like doing an actual ETH deposit for a new minipool. The described structure has no easy way to prioritize specific commission pools, so that recommendation (b/c a should is a recommendation, not a requirement) is not being followed.

I like a line per rewards period. What’s the added cost/complexity to that? I assume that would be the reason to do a single line in the sand? I think this is pretty important if indeed credit-created LEBs need to go through the queue. I think we may also get bailed out of this when skimming is implemented, so hopefully it’s for a pretty small number of reward periods. Once skimming is online, we’d just need to skim before migrating. (btw, if tree generation is expensive, we could always do one every other period; there could even be a message telling the NO how much they’d lose in rewards fairly easily and when the next tree is being generated to save rewards)

I like this concept better than a separate distributor both because of lesser complexity now, and b/c it’s easier to adapt if we add, eg, LEB4s at some point.

You’re talking about this as an approximation. What makes this non-exact? Is it mostly luck? Premise: I have a minipool16 and an LEB8. I get 4 proposals on the minipool16 and none on the LEB8; ideally, from those proposals, I would get (0.5 + 0.5 * 0.15) * proposal_rewards = 0.575 * proposal_rewards, but here I’ll get 0.375 + 0.625 * 0.145 * proposal_rewards = 0.466 * proposal_rewards so I get underpaid. Ofc, if the proposals were all on the LEB8, I would ideally get 0.25 + 0.75 * 0.14 * proposal_rewards = .355 * proposal_rewards, so then I’d be getting overpaid. I believe this is the main issue, but please correct me if I’m wrong.

I think the expected value is correct, and I don’t see a way to cheat it. Ie, if I got many LEB8s and few minipool16s to increase my chance of getting overpaid, then the collateralRatio changes so I get less overpaid on the LEB8 proposals and more underpaid on the minipool16 proposals.

The biggest issue I see here is explaining this complexity.

What priority does this get? Can this take from DP even if there’s a queue? Can it take from vault? I think it makes sense to have it take from anywhere and have priority above the minipool queue.

Yep. Agree with this way.

Yep. Exactly as you describe.

Indeed, complexity is the main draw back. One merkle tree could be generated and included in the upgrade vs having to update the whole reward submission system to include this addon. Again, you’re right about the skimming. This seems like a reason to go with the simpler design IMO. If people don’t migrate in the short term, they just have to wait til skimming then migrate after a skim.

This is my preference too.

You got it. Spot on.

It won’t actually be used in the short term because 8 ETH refund results in precisely 1x 8 ETH pools. So there is never any dust. It only matters if we ever include variable collateral deposits (e.g. 6 ETH).

To answer your question though. I don’t think there are any issues just taking it from the DP immediately without a queue. We could address it in the future if it became an issue.

1 Like

Two questions:

  1. If we did the simple design (merkle tree is part of the upgrade) and skimming was taking a very long time to release, could we push an upgraded merkle tree with a contract upgrade? I’m guessing that would need to be audited, but could be pretty easily tacked on to any other audit cycle?
  2. How likely do you think it is that skimming will come at the same time as withdrawals?

If (1) isn’t too hard, then I think I agree we should do the simple thing; if (2) is “likely” then that leans us even more that direction. We’d pretty much have a new merkle tree whenever RP does upgrades and then when skimming comes by it would obsolete the need.

Minor thought, we need a switch to disable migrating. Otherwise we could get into trouble if the tree says I’m owed .5 ETH even after skimming. So we’d disable migrating when skimming is about to be added, then re-enable with the new migrate style that uses skimming.

I think I agree; just need to have it revert if there’s not enough ETH on hand. And yes - I agree it shouldn’t come up for LEB8s.

I also find this confusing. Please correct me if im not understanding something.

There are two things that I believe:

  • the less ETH you put up as a node operator the less commission you should receive
  • all stakers should pay 15% commission.
    • if it’s some moving target, I think from a staker standpoint it can be really confusing. especially when Rocket Pool markets commission as a single number a staker would pay.
    • If we have a moving target, the total pool will not end up being 15%.

Here is what I came up with, that makes intuitive sense to me.

Node Operator ETH (N) % Of Node % of Staker Staker % Commission (C) Node Operator % Rewards (nR) Staker % Rewards (sR) Total Reward % Ratio = nR / % Of Node
16 0.5 0.5 0.15 0.575 0.425 1 0.15
12 0.375 0.625 0.15 0.46875 0.53125 1 0.25
8 0.25 0.75 0.15 0.3625 0.6375 1 0.45
4 0.125 0.875 0.15 0.25625 0.74375 1 1.05

This works out to be:

Total Rewards (nR) for Node Operater with Staked ETH (N):
nR = (0.0265625*N+0.15)

Total Reward (sR) for the Staker:
sR = (1-N/32)*0.85

So… A few things…

  • The calculation you quoted was about how to calculate overall commission when a single node operator has different commissions (which already exist) and different amounts of NO ETH in their minipools (which is getting added). The rest of your response seems to be talking about commission in general, ie, it would aaaply to an NO with a single minipool.
  • “the less ETH you put up as a node operator the less commission you should receive”. I disagree and, interestingly, so do you. Your example table showed increasing commission with decreasing NO ETH. Higher total rewards, yes, but less commission.
  • “commission should always be 15%” I’m not willing to set a rate for all time. I will note that we’ve only talked about decreasing commision going forward, so I don’t think rETH holders will be upset. For example, LEB8s are planned to have 14% commission - this number was chosen b/c it would still give better ROI than a current 20% commission minipool. For calculating ROI, see https://github.com/rocket-pool/RPIPs/blob/main/assets/rpip-8/2022-08-03%20LEB%20Discord%20Discussion%20Summary.pdf - you need to include the RPL investment.

Is it feasible to calculate nodeShare at the minipool level and then sum up for the node? The reason I ask is that using the simple averageNodeFee results in slightly skewed nodeShare values for nodes with existing minipools with a wide node fee range.

An extreme example is an existing node with a number of 5% minipools who then decides to add LEB8 without converting the existing minipool16. Let’s say a NO has 4x minipool16 @ 5%. Then they decide to add 4x LEB8 @ 14%. The values for the above formula would look as follows:

Parameter Value
nodeSupplied 96
userBalance 160
balance 256
collateralRatio 0.625
averageNodeFee 9.5%
nodeShare 111.2
userShare 144.8
nodeShareRatio 0.434375

where nodeShareRatio = nodeShare / balance.

If instead we calculate nodeShare per minipool and aggregate across all minipools, I think we get a more accurate value for node-level nodeShare and nodeShareRatio.

minipool nodeSupplied userBalance collateralRatio nodeFee nodeShare userShare nodeShareRatio
1 16 16 0.5 5% 16.8 15.2 0.525
2 16 16 0.5 5% 16.8 15.2 0.525
3 16 16 0.5 5% 16.8 15.2 0.525
4 16 16 0.5 5% 16.8 15.2 0.525
5 8 24 0.75 14% 11.36 20.64 0.355
6 8 24 0.75 14% 11.36 20.64 0.355
7 8 24 0.75 14% 11.36 20.64 0.355
8 8 24 0.75 14% 11.36 20.64 0.355
Total (unless otherwise indicated) 96 160 0.625 (avg) 10.4% (wgtd avg) 112.64 143.36 0.44 (avg)

The weighted-average node fee is higher than the simple average owing to the higher userBalance that the minipool fee is applicable to for the LEB8 (i.e 24 ETH each) relative to the minipool16. I’ll concede that the difference between nodeShare from the two calculation methods is very small (111.2 vs 112.64 ETH, or ~1.3%), and would be smaller yet if a NO has minipool16 with commission values closer to 14%.

In any case, the key parameter that we could report on a per-node basis is the nodeShareRatio, which captures both the nodeSupplied and nodeFee values. This ratio would be used to split the proposal rewards. I think the above calc would help explain the complexity to NOs relative to the concerns about them thinking that they’re being overpaid or underpaid.

1 Like

You cannot have an unbounded loop in a smart contract so it’s not feasible to calculate nodeShare per minipool and sum them up on chain. At some number of minipools, the gas used to process the loop exceeds the gas limit of a block and then it becomes impossible to call it.

Yes, it is is an imperfect approximation and the reason I provided two options with different trade offs. Thanks for running the numbers so we have a concrete example of how far off the approximation could be.

1 Like

Ah understood. Thanks for the explanation!

@Valdorff and I just had a quick offline discussion about this and came up with what we think is a better compromise.

It is only an unbounded loop if we are concerned about future compatibility with a non-discrete variable deposit system. i.e. If we commit to only supporting a few specific deposit sizes in the future (e.g. 4, 8, 16 ETH) and never allow an arbitrary deposit amount then we can track the sum of node fees and minipool counts on a per node per deposit size basis. This will give us a more accurate approximation at the cost of a few more storage writes. It would be the same as the “weighted average” in the post by @faisalm.eth

It is still an approximation because we are not distinguishing the rewards on a per validator basis but it is a closer approximation.

3 Likes

had to let this sit for a bit and did some more reading before replying. right now this is more educational for me, as i’m starting from nearly 0.

Correct.

I understand now. I added a column at the end “Ratio = nR / % Of Node”. This isn’t quite ROI but it represents something similar. In end (minus RPL rewards). In my example someone is more incentivized to make 2 x 8eth validators vs 1 x 16eth validator. Makes sense, thanks for the clarification.

is the proposed ~14% number proposed for ALL validators or just 8eth validators?
thanks for the link. I never really thought about ETH + RPL as the “principle” or total outlay of investment and the % return is the total ETH for the validator. ignoring RPL rewards. I think that’s a simple and clean way to looking at it.

Switching from minipool16s to LEB8s implies significantly increasing exposure to RPL (from 10% to 30% of your investment given minimum collateral). If many people decide to do that, our future problems related to the RPL price may be significantly aggravated. In the current system, once we reach a steady state in which the number of staking pools is constant, RPL becomes inflationary and we would expect some NOs to exit and switch to solo staking. LEB8s would give them 3 times as much reason to do this, potentially creating an RPL bank run. (See also my thread here: Concerns about long-term RPL tokenomics) Edit: this was wrong, see my later post.

This effect would not be limited to users of LEB8s. If LEB8s become popular this would create much more demand for RPL and hence large price increases in the short to medium term. Hence, current operators of minipool16s would also see their share of RPL increase, increasing incentives to exit and cash out. In summary, I expect a larger increase and subsequent collapse of RPL if LEB8s are implemented.

In my opinion, we should have a long-term RPL strategy before implementing LEB8s. I expect some of you to disagree given previous discussions, but maybe we can at least avoid further pumping of RPL. What about these ideas:

  • Don’t allow newly created LEB8s, only allow people to transform their existing minipools under some strict conditions. For example, they need to have had surplus RPL collateral (say, 50%) for at least 6 months. This would avoid NOs to buy new RPL on the market to fund LEB8s, so it will keep the RPL price from increasing.
  • Use mixed collateral for LEB8s. Say, a third RPL and two thirds rETH. So minimum collateral for a LEB8 would be 0,8 ETH in RPL and 1,6 ETH in rETH. I like this best but I guess it would be complicated to implement.

This should NOT pump RPL more than 16 ETH minipools. Please see the discussion document linked from the rpip (RPIPs/2022-08-03 LEB Discord Discussion Summary.pdf at main · rocket-pool/RPIPs · GitHub for convenience).

As you can see in that model, the same value of rETH is linked to the same amount of staked RPL - what changes is how many minipools we need. This is, in fact, the very argument for keeping percentage of RPL as a function of protocol ETH constant.

I apologize for being unaware of the previous community discussions. However, I can’t see anything here that conflicts with what I said. If rETH TVL remains constant then indeed the price of RPL should remain constant. But if rETH TVL remains constant no one can transform his minipool16 to a LEB8, since rETH supply would need to grow.

(Unless NOs exit some of their minipools. For example, if a NO with three minipool16s exits one and transforms two of them to LEB8s, the freed up protocol ETH from the 3 minipool16s – 48 ETH – is exactly sufficient for filling up the two LEB8s. But this NO will now have only a third of his initial investment staked.)

LEBs will accomplish that with the same amount of ETH staked by NOs we can attract three times as much rETH. This will also require three times as much RPL, and naturally that will raise the value of RPL a lot. I think we should aim for a constant RPL value, since what goes up must come down. Hence my suggestion to require two-thirds of LEB8 collateral to be supplied in rETH instead of RPL.

So what you’re discussing sounds like you assume infinite rETH demand, such that our minting is NO limited.

In the end, it doesn’t matter to RPL price if we meet rETH demand with more 16 ETH pools or fewer 8 ETH pools. The only time we’d have a difference in price is if we FAIL to meet the demand for rETH. I consider that a bad thing and would like to ensure we can meet demand. (I’ll make an exception for us getting “too large” - I do think we should plan to self limit, but that’s mostly a separate topic).

Looks like I overlooked something important: while LEB8s need more collateral, they also accrue more rewards, which offsets their missed rewards from collateral if RPL APR is 0% (the maximum expected in a future steady state). Hence, I was wrong when I said that once we hit a steady state NOs of LEB8s will have more incentives to exit than NOs of minipool16s. In fact, the situation is slightly better for LEB8s.

Calculation

Suppose r is the solo staking APR, the commission is 14% and the APR of RPL collateral is 0%. Then a 10% collateral minipool16 has an APR of
(16*r + 16 * 0,14*r) / (16+1,6) = 1,036*r

A 30% collateral LEB8 has an APR of
(8*r + 24 * 0,14 * r) / (8+2,4) = 1,092*r

So it’s much less bad than I thought. The only concern I have left is that LEB8s have the potential to accelerate rETH and RPL growth. This means we move more quickly towards the dreaded steady state for which we don’t have a solution yet. It also might mean we arrive there with higher stakes (i.e. more exposure to RPL) such that implementing a solution or a crash of RPL will be more painful. I’ll say more about that later on Discord.

1 Like

I’m very conflicted on this one. However, after @Wander’s justified complaints over unvoiced opposition to an earlier RPIP, and since i’ve had several months to consider this one I figured I’d add my concerns here.
LEB 8 seems like an obvious ‘yes’ vote as it would benefit me personally, and probably fellow overcollateralized NOs are in the same boat. It’s nice to be in the select group of winners for once. However, the particular choices that were made to prioritize RPL price appreciation over other parts (namely growth and decentralization) seem to be so damaging to the rocket pool protocol that I feel obligated to vote against my own interests. And because Atlas will have so much stuff rolled into it, i think it is better to discuss any fine tuning now rather than at snapshot.
I would welcome any criticism or changes, particularly to my list of winners and losers!

The original sin:
From what I can reconstruct, the narrative (including from FireEye’s early discussion of the tokenomics changes and the rocket pool docs) was that min/max collateral was based on node operator ETH bond. There had been discussions ongoing in #trading about changing this to collateral based on protocol ETH. Based on an 8/1 and 8/3 discord chat, the following RPIP was submitted for community review to codify this change in defining collateral. While innocuous on the surface, this solitary change severely restricts any benefits of LEB offers to the protocol, increases centralization of RPL, and negatively affects Ethereum.

For brevity in this post because they are referenced so much, i will use pETH (protocol ETH) and noETH (node operator ETH) and vETH (validator ETH)

Collateral choices:
3 choices were given with the following minimum RPL per minipool in ETH terms for LEB 8/LEB 4.

  1. Collateral based on pETH 2.4/2.8
  2. collateral based on vETH 1.6/1.6
  3. collateral based on noETH 0.8/0.4

pETH maximizes RPL/ETH ratio as TVL rises; noETH maximizes TVL growth at expense of slope of RPL/ETH appreciation; vETH is a compromise between both.

The choice for this RPIP was made to go with the collateral definition that maximized RPL/ETH appreciation. (2.4/2.8)

Winners and losers of choosing pETH over noETH

Please note, every stakeholder gains from this RPIP as written compared to current status quo, so this is specifically not a analysis of LEB vs no LEB.

Speculators/LPers/rocket pool team: Winner/Equivocal

  • increased volatility given the wider range of collateral requirements before forced buyers/sellers
  • increased RPL/ETH ratio for a given TVL
  • Poorly collateralized NOs will need to buy more RPL (RPL up), but RPL demand may actually decrease if there aren’t enough new NOs to make up for this (RPL down)

Overcollateralized NOs (current collateral 150%+: Massive winner

  • all RPL becomes effective collateral, earning staking rewards
  • decreased competition to roll out new minipools/solo migration as soon as LEB 8 and 4 are permitted
  • other NOs become forced RPL buyers to benefit from LEB, buoying RPL price

Intermediately collateralized NOs (current collateral 30-150%): Equivocal

  • all NOs can form LEB 8 immediately; however, only some will benefit from LEB 4
  • other NOs become forced RPL buyers to benefit from LEB, buoying RPL price
  • decreased RPL rewards as more effective stake occurs from overcollateralized NOs

Poorly collateralized NOs (current collateral 10-30%): Loser

  • cannot benefit from LEB 8 immediately and must purchase more amount of RPL to do so
  • following this, RPL/ETH ratio needs to >double in order to benefit from LEB 4
  • decreased RPL rewards due to dilution from current overcollateralized NOs

New NOs: Massive loser

  • new NOs have to triple their RPL exposure to join; for NOs that have not joined because they don’t want a 10% exposure, they definitely will not want a 30% exposure
  • ETH denominated ROI goes down substantially (see RPL price dropdown below)
  • at the lowest level of ETH holders, those with between 8.8 and 10.4 ETH cannot become NOs; with LEB 4 this is true from 4.4->6.8ETH.

SAAS: Loser (please note, this is a bit beyond my comfort zone and I don’t think the rules are in place so ranking is speculative at best)

  • huge amount of overcollateralized RPL that could either be churned into SAAS or UEB now becomes effective stake and cannot be withdrawn through protocol without further upgrades
  • additional capital financing fees (ie need to borrow 30% RPL instead of 10%) drags down ETH rewards

rETH: Massive loser

  • severely limits how much rETH commision can be decreased- in this case, only decreased 15->14% which is far above the long term expectation of 10% that rocket pool has promoted; more worrisome, because rETH supply will nearly triple, this multiplies how difficult it is to lower rETH commission in the future in response to market forces [ie new competition]
  • rETH supply is decreased because fewer new node operators join
  • rETH supply is decreased because fewer poorly collateralized NOs can form LEBs
  • rETH supply is decreased there are no longer any overcollateralized nodes to convert RPL to minipools.
  • fewer NOs can benefit from solo migration

Rocket pool decentralization: loser

  • Exclusion of new NOs at the lowest levels of ETH ownership (ie, between 8.8 and 10.4 (8E LEB) or 4.4 and 6.8 (4E)
  • decreased number of small NO minipools (these tend to have the lowest collateral)
  • higher concentration of the largest NOs both because they tend to have higher collateral and because even at lower collateral they can convert a proportion of minipools to LEB (for example, the top 10 NOs control ~37% of rocket pool validators; about ~97.5% can transition to 8LEB and vast majority can transition to 4LEB; however ~40% of other NOs can’t transition to LEB8 and ~60% can’t transition to LEB 4)
  • less ETH rewards and RPL rewards to the lower collateralized minipools to allow them to make more minipools going forward

Ethereum health: loser

  • if rocket pool TVL is diminished and fewer small NOs are able to join, this limits the decentralization of the entire ETH network until other decentralized competitors come along.

The following are just my ramblings in defense of the above, they are less coherent:

RPL price, ROI, and capital gains

Valdorff laid out a great tool for calculating capital efficiency in LEBs for ETH rewards:
relative ROI = (NO_ETH + Protocol_ETHcommission_pct)/(NO_ETH + Protocol_ETHmin_rpl_pct_of_protocol)
At 10% commission and 10% pETH, the relative ROI is 1; as commission goes up, ROI goes up; as %pETH goes up, ROI goes down.
Let’s plug this in for some numbers to show how much ROI is expected, assuming 14% commission and 8E LEB.
For 10% pETH, ROI improvement is 1.09; if ETH APR is 5%, this is equivalent 5.45%
For 10% noETH, ROI improvement is 1.29; if ETH APR is 5%, this is equivalent to 6.45%
For RPL demand to be more in noETH model, it will need to generate 3x as many new NOs as pETH. It’s likely that this will, but not certain.
However, I think this ignores a glaring hole in the argument. I believe (always dangerous) that most new NOs are not buying ETH and RPL from fiat and staking. They are taking ETH already accumulated and staking with it. This is particularly true as we talk about solo migration and stealing value from the centralized exchanges, but is similarly true for the 85% of ETH that is not currently staked.
To convert any sizable amount, capital gains taxes have to be paid and these enter into the capital efficiency equation. These vary country by country, but US, UK, and Australia appear to top out around 20-22%. I’ll use united states as an example, which has a top capital gains rate of 20%.
To cash out 1 ETH for RPL, you need to sell 1.25 ETH. Multiplying by the min RPL * 1.25 gives:

  1. For 10% pETH, ROI improvement is 1.03; if ETH APR is 5%, you’ll earn an effective 5.15%
  2. For 10% noETH, ROI improvement is 1.26; if ETH APR is 5%, you’ll earn an effective 6.3%
    It is very very very easy to imagine that the second option will generate more than 3 times as many takers as the first option and thus RPL demand will actually be higher under noETH collateral

In terms of sell pressure, with noETH, every NO who currently has effective stake continues to have effective stake- so no immediate sell pressure from current (see whale conundrum below). Over time there will be additional sell pressure if we don’t figure out a way to use additional RPL collateral- but many ideas are in the works.

Security of protocol

Most proponents of this RPIP are in favor of transition to 4E +2.8RPL LEB. 8E NO bond is even more safe, and so security shouldn’t really be an issue in 8E LEB for RPL collateral at either 0.8 or 2.4. However, because of poor RPL liquidity a new method of utilizing collateral should be researched. Also please see the new post on upper levels of RPL collateral.

What this means for rETH commission (one of the levers of demand):

A 10% pETH means that to compete with solo operators, the minimum rETH commission would be 11%. In order to provide some benefit to rETH over current, the maximum is 14%. This is a very tight range of options (and tightened further with capital gains concerns), and the benefit to both NOs and rETH is obviously limited

Let’s see how that works for collateral based on 10% noETH. So to be more profitable than solos stakers you’ll need commission above 3.5%. So the range of commission could be 3.5%-14%. Within this range are multiple values that provide large benefit to both NOs and rETH, and for these levers to be adjusted should demand dry up on one side or another

The choice of 14% commission

The reasoning here is understandable: 14% was chosen to convince all 20% operators to migrate to 8E LEBs. I disagree with this reasoning (a lower commission would still encourage most NOs to migrate to increase TVL in short term, and then a slightly lower commission could be done in 4E LEBs would encourage any remaining 20%ers to migrate), but that is not my major concern. It’s challenging to explain succinctly, but it is much, much, much, easier to raise rETH commission over time in Rocket Pool than to lower it, can explain my reasoning if anyone disagrees. So at 14% with 8E LEBs using pETH, it is unlikely we will ever drop below 13% or so. Which could be a problem facing decentralized competitors (obol, swell, and the ones in the pipeline) who are already projecting 5-10% commission.

So how does this effect rETH supply?

Basing collateral on Protocol ETH allows all NOs over 30% collateral to form new minipools. This is most of them (rough guess 80-90% of minipools). Less collateralized NOs would need to purchase RPL to form LEBs.

Basing collateral on NO ETH allows ALL current node operators to form LEBs; more particularly, when LEB 4 pools exist it would also allow all current NOs to form pools.

Most importantly: people who have not bought RPL already for 15% gains on 10% capital expenditure seem very unlikely to buy RPL for 42% gains on 30% capital expenditure; particularly when you assume many of these these ETH holders are paying 10-25% capital gains taxes. This means the influx of new NOs is unlikely to rise appreciably. This is counteracted somewhat by solo migration from current overcollateralized whales, but I don’t think there are enough of them to make up the deficit.

The whale conundrum

So what will we do with our overcollateralized nodes?
Some will sell RPL to get more minipools (this is good for rocket pool as it decentralizes RPL ownership and creates more TVL)
Some will keep it speculatively for RPL price appreciation or eventual UEB/SAAS/Eigenlayer/other use cases (this is good for rocket pool)
Some will plow it into liquidity (this is good for rocket pool, particularly given its use as a collateral)
Some will sell excess RPL and move the profits elsewhere (this is not good for rocket pool, but does help decentralize)
all told, I suspect most of the RPL value will stay in the system.

Maximum collateral

This is a long topic, and both sides were better discussed in @NonFungibleYokem’s post. But:

  1. The wide range of collateral (10.4->44 ETH) doesn’t make sense for insurance, as we should by now have a better idea of how much is optimal per minipool.
  2. this RPIP not only increases RPL collateral but also total collateral allowed per node, despite the fact that RPL has never actually been used been used once as collateral
  3. RPL liquidity is not sufficient to sustain any moderate black swan (ie, in 8E LEB, if a 17% correlated slashing occurred, then in the ballpark of 700k RPL might need to be auctioned in a month, which would certainly drop the RPL price to near 0). Thus increasing collateral further seems unlikely to actually increase the insurance value.

Ultimately, to me the question boils down to how to judge the success of Rocket Pool? Do we measure ourselves primarily on the success of RPL or on the success of rETH? Is RPL the main product, or is it just a lucrative means that we are using to encourage decentralization of the network?
And who is we? Are we just the NOs with enough RPL to get 51% of pDAO votes? Or are we also the small node operators who may not even feel it is worth voting? Are we the future NOs who haven’t even heard of RPL yet? Are we rETH holders? Are we the ethereum ecosystem as a whole? If we feel these various groups are part of our community, we as delegates should advocate for their benefit too.

1 Like

I’m gonna hit 3 little sections…


I think the main issue is that you’re not accepting the core conclusion in “NO supply Growth” from RPIPs/2022-08-03 LEB Discord Discussion Summary.pdf at devs_and_pdao · Valdorff/RPIPs · GitHub

The consensus was that we would not be NO-limited. This means TVL in ETH isn’t affected, which means Ethereum health isn’t affected. This also means 3 of the rETH “loser” bullets don’t apply.

If you do believe we’re NO limited, then I agree protocol ETH scaling is the wrong choice per “Belief → LEB structure”.


Also, you’re including several items related to max collateralization in your post about min collateralization. Eg, with my recent proposal:

  • “Overcollateralized NOs” section loses a bullet
  • “Poorly collateralized NOs” loses a bullet
  • “SaaS” loses a bullet
  • “Rocket Pool decentralization” loses a bullet

Finally, I don’t understand the equating of size with conviction in RPL. If I didn’t have enough ETH to run a minipool with >50% collateral, I wouldn’t have a minipool. Instead I’d hold RPL naked, and maybe have some rETH. Anyone of any size can do this.

I routinely advise people on discord to consider the ratio they want first between ETH and RPL, and only then determine if/how they’ll run minipools. If one expects large ratio appreciation, then the small APR is a modest difference.

There is only an extremely specific size and target RPL:ETH ratio that will result in someone being unable to be an NO due to the difference you note. Not only is it between 8.8 and 10.4 ETH, but they also have to want ~10% exposure to RPL.

I’m not saying there will be zero people in that bucket, just saying it’s a really small bucket.

Thanks @Valdorff !

1.

So if I’ve learned anything in the last 12 months, it’s that both sides are wrong. I have a 5% and a 20% minipool, each from when the going theory was the status quo would last forever. Later a 200 NO queue seemed unconquerable and it fell in a matter of days. To me, the necessary attribute is dynamism because we cannot reliably predict future demand on either side, and the Rocket Pool model of matching is so unforgiving. Using noETH, commission can be heavily tilted to favoring rETH or NOs (4-14% commission) while still providing increased ROI relative to solo staking. Thus, even if we are rETH constrained, we can throttle the NO queue to boost rETH demand.
But if our long-term goal is in the ballpark of a 20% share of 50% ETH staked, it means we need to be looking at 30-50x TVL growth. So a 7x from converting all current NOs to LEB 4 isn’t enough from either rETH or NO perspective.

2.

To be fair, my post was regarding RPIP 8, which changes increased both min and max collateral. I don’t think min and max collateral need to be linked, although conceptually it is easier for many if they are; I think that using pETH for min and noETH for max, as you suggested in another post, gives most of the benefits I am seek, and I’ve argued as such in other posts on max collateral; it also has an added benefit over my proposal of a significantly narrower range of effective RPL to decrease volatility. The main downside, however, in increasing the minimum collateral is it doesn’t allow us the actual growth in new NOs that I would like to see in rocket pool if we are going to increase by 1-2 orders of magnitude. As such, I think it will, in the long run, be worse for TVL and RPL price.

3.

Sorry, I don’t quite know what this is referring to, but I was sleep deprived while writing so maybe I missed my own point.

Blockquote Finally, I don’t understand the equating of size with conviction in RPL.

But regarding the rest:
A quick peruse of rocketscan.io shows the vast majority of single minipool NOs that have joined in the past few months have close to 10% collateral. I count only 3 of 50 from October as having 30%+. Maybe all those other 47 would still join if forced to get 30% collateral, but it seems unlikely. new node operators are a different breed from diehard rocketpoolers, and while you give good advice on 50% collateral, new NOs aren’t buying it. They want 10%.