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.
Thanks @Valdorff for the great RPIP. I compiled the below notes while going over the proposal.
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:
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.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().rocketMinipoolManager.decrementNodeStakingMinipoolCount should to the same as above, but it should decrease matchedETH by the user deposit balance instead.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.
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.
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).
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.
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.
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:
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
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.
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.
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.
Two questions:
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:
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ā¦
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.
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.
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.
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:
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.
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.
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.
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
Overcollateralized NOs (current collateral 150%+: Massive winner
Intermediately collateralized NOs (current collateral 30-150%): Equivocal
Poorly collateralized NOs (current collateral 10-30%): Loser
New NOs: Massive loser
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)
rETH: Massive loser
Rocket pool decentralization: loser
Ethereum health: loser
The following are just my ramblings in defense of the above, they are less coherent:
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:
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.
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.
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 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.
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.
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.
This is a long topic, and both sides were better discussed in @NonFungibleYokemās post. But:
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.
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:
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 !
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.
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.
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%.