UnETHbonded (UEB) minipools

2-I partially agree , because NO is responsable for validating so it must earn some commission

I agree, and I would go further by raising the cap to 200 % RPL, so NO could buy more RPL to start more Minipools.

@ken why we must wait the merge? the demand for rETH is there , Aave just aproved an increase to stETH because of the higth demand for borowing ETH to mint stETH.
I think this is urgent. We are loosing market share and the oportunity cost will be very high AAVE proposal link

1 Like

The only reason I see to wait for the merge (or near merge) is that the devs are actively working on the needed changes for RP to be ready for it. The code is scheduled for auditing. I think that this proposal has merit and carries some priority. I am looking forward to having the devs comment on the feasibility and the degree of complexity of UEB minipools. Perhaps folks attending ETH Amsterdam with them can inquire more during the meetup.

3 Likes

more math not counting the eventual ODAO 100/500 minis each:

  • 4000 more 32eth minipools----) 160.000 ETH —) 80 times staking pool top up

  • 7000 more 32eth minipools —) 224.000ETH —) 112 times staking pool top up —) doubling the Rocketpool total staked ETH

providing that rETH demand will remain stable (why not? it’s a no brainer) i think it’s the right road to tackle LIDO and ramp up

I think we would have to figure out how to handle the withdrawal credential exploit with this new type of minipool.
I’m not convinced on the right amount of RPL per UEB minipool. 0x03 is not implemented so there is no way to deal with underwater UEB minipools.
And of course this design would heavily lean on the RPL auction mechanism, which would have to be fixed first.

I think we would have to figure out how to handle the withdrawal credential exploit with this new type of minipool.

  • This could be addressed by requiring that 1 ETH be submitted to the deposit contract. In essence, making it a 1 ETH + 16 ETH-worth-of-RPL minipool.

I’m not convinced on the right amount of RPL per UEB minipool. 0x03 is not implemented so there is no way to deal with underwater UEB minipools.

The amount of collateral would need to be financially equivalent to the amount needed for a normal 16 ETH minipool (17.6 ETH of collateral). This value comes from the beacon chain failsafe that kicks out a non-performing validator once their effective balance is at 15.75 ETH. The worst case (assuming that the blockchain is reaching finality) is that the node operator then gets slashed with only 15.75 ETH remaining. This will result in a further penalty of ~1 ETH. So total exposure (loss of funds) is 17.25 ETH. Thus the need for 17.6 ETH worth of collateral.

And of course, this design would heavily lean on the RPL auction mechanism, which would have to be fixed first.

Agreed but I think they may have done this already. It looks like it is working in beta 1.3 RC2 on Prater. Yes/No?

Yes, I think that seems reasonable.

With a regular minipool, we can be certain that there is at least 16 ETH collateral at all times. What I mean by UEB minipools going underwater is this: RPL ratio can change over time, in particular if I start a UEB minipool with the RPL equivalent of 17.6 ETH today, it could be less than 16 ETH tomorrow if the ratio drops enough. I don’t think we have a good way to deal with this situation (no forced exits possible). So if the design is just that you need RPL equivalent of 17.6 ETH when you start the UEB minipool, it is strictly more risky than a regular minipool. We can reduce the risk of a UEB minipool going underwater by requiring more than 17.6 ETH, but it will never be as good as just using 16 ETH instead.

Not sure what the 1.3 RC2 changes with regards to auctions, but I am talking about the auction mechanism needing a new design, including smart contract upgrades, as I am trying to discuss in: RPL Auction Mechanism Design
I didn’t get a lot of answers from the team, but it seems like they agree that the mechanism needs work if we want to lean on auctions more. I think using 100% RPL as collateral qualifies.

2 Likes

IMHO starting a minipool with 16 eth or 17.6 eth of RPL is not worth the hassle.

i think only 300 minipools are more than 100% collateralized.

we are starting on the best case 300 more 32 eth minis, 9600 eth worth, 4.8 times the pool…

to scale up a lot more are needed and this solution i think will not ease the rETH or the
NO problem neither in short nor in the long run

Another option to increase minipool is to leverage the collateral deposit of 16ETH , minting rETH to NO, allowing to deposit into Defi and borrow ETH to start another minipool. This is already happening with Lido and Aave.

if 16 rETH are minted from the NO 16ETH and used to start another mini, is not the same starting it up with the pool ETH directly?

I think this is a great idea, it would generate additional demand for RPL while at the same time enable large chunks of 32Eth / minipool to be taken out of the deposit pool.

i think the Node Operator should recieve commission though. A normal NO only recieves comission on the Eth provided by the deposite pool, this is independant of his own ETH stake so i see no reason why a Node Operator staking purely with RPL should not recieve Comission. I would go as far as to say that a pure RPL node Operator is exceptionally beneficial to the protocol by driving big demand for RPL while taking larger bites out of the maxed out DP which we desperately need. Therefor i would even suggest such a NO should recieve comission on the whole 32 Eth from the DP.

i think this should be explored immediately. Im sure with some thougth and ingenuity this could be fleshed out pretty well and we really need some new mechanic in the protocol to get some more NOs up and running.

2 Likes

I really like this proposal, though as Knoshua pointed out, we need to address the security concern of RPL/ETH ratio fluctuations, which will be present even with a reduced commission. From my POV, this market risk can and should be decentralized. Under this model, the NO is directly leveraging their RPL, so we could use a leverage-liquidation model to help with security:

  • Only allow over-collateralized minipools (16+X% ETH worth of staked RPL = 1 minipool)
  • Record the ratio on pool creation
  • Implement a mechanism to liquidate the entire RPL stake via auction if the RPL/ETH ratio goes below the liquidation price (ratioOnCreation-X%)

Pros:

  • Allows us to keep full commission on these nodes
  • NOs can choose personal risk tolerance

Cons:

  • Big liquidations could cause negative feedback for RPL/ETH ratio, which leads to more liquidations
  • Solid amount of additional work on both smart contract and smart node sides
  • Doesn’t allow full use of staked RPL for minipools (though I don’t think it’s possible to do this safely anyway)
3 Likes

A good in-depth discussion in discord happened here [Discord](https://Discord Link).

The fundamental question that this proposal asks is “'How much ETH can we afford to have just RPL backing?” or “How much additional ΞRPL security is necessary per rETH?”

To expand on @ken’s point, I think we can calculate this empirically using the current minimum collateral requirement, at least to a first approximation. Currently collateral requirements are 110-250% (100% ETH + 10-150% RPL). So in theory an overly collateralized NO should be allowed to operate within that range, by taking on UEBs to go from 250% all the way down to 110% collateral.

An example:

Let’s say a NO has 100 minipools and 150% RPL collateral. Effectively they are 250% collateralized. If we allowed them to take on UEBs all the way down to 110% collateral it would enable them to stake an additional 2036 ETH, or 63 full validators.

This would be building additional NO capacity without making any compromises on security.

Although to take it a step further, I think the ideal solution would look like this:

  1. Minimum collateral requirement would be initially set to 110%, but would be a configurable parameter that could be changed without code (no audit). I have a hunch that this collateral % could be safely lowered in the future, but that’s a separate discussion that requires further security analysis.
  2. Effectively, NOs could provide a collateral breakdown of their choice – an arbitrary mix of ETH and RPL – so long as they meet the 110% collateral minimum. This could unlock a new suite of NOs who are heavy on RPL but don’t have enough ETH to fully stake their position.
1 Like

I mostly like this idea for the short/medium term, but I think a more permanent solution to this issue for scaling may be needed.

A solution that, after the merge, would allow fungible node entry/exit and help maximize pool utilization (or at least keep it off of the cap and out of the “red” zone on the pool.

The idea of an unbonded ETH node is definitely a good one. I think, however, it would be better in the long-term to have a pool that can hold rETH until it hits the equivalent of 16 ETH + 1.6 ETH * RPL/ETH ratio. At that point, if the pool is full (or deep in red territory), the rETH would be converted to ETH through the rpool contract (ie. the rETH would be burned dropping the total pool amount), and would then launch a new minipool.

This pool would be spread on multiple accounts across multiple cloud providers. It would also have a similar buffer of liquidity so individuals that want to stake in that pool would be able to help fund additional nodes coming online without a specific person/user running/operating the node(s). RPL rewards would be used to pay for the infra in the accounts with remainder of RPL rewards converted to rETH until another pool could be brought online.

I haven’t started writing the proposal just yet, because I still need to work out the math (ie. how many nodes and at what collateralization would result in profitability for the pools).

The shorter-term solution of having unbonded nodes or just providing the bond would probably draw in more people, but we’re still talking about a lot of ETH for a single user that also has the skills/tech to run a node. That’s a lot more rare than I think people realize.

So, I think if we want to incentivize a random Linux Systems Administrator (for example) to run their own node in their own time, we would want to make this a bit easier barrier to entry for the tech enthusiasts that may not have the funds to operate a node, but have the expertise and interest in doing so. 16 ETH is a LOT of $$$ in the current market environment. If they are newer into being a tech professional, they probably don’t have the ~$63k USD they would need to start one from zero ETH today.

2 Likes

I support this proposal because I believe the RPL token should have additional utility to justify its value, and also because it would relieve the NO bottleneck that prevents Rocketpool from scaling.

The only thing I would like to add is that if this proposal is passed, we should try hard to implement it ASAP before the Merge, because otherwise IMHO it will be very hard for rETH to compete with other liquid staking derivatives which have much more marketing power and publicity, not to mention other types of staking services that might launch as well.

1 Like

Thanks for explaining further, I agree with your reasoning. I think the examples I was initially thinking of were in the context of burning tokens pointlessly when they could be more effectively used to grow or secure a protocol. However, in these cases the protocol probably did not have any meaningful utility for their token, nor built in mechanisms to create demand. This is obviously not the case for RPL, and the comparison to ETH and EIP-1559 makes sense, given the inflation is being meaninfully used to secure the network and incentivise growth on the NO side. A burning mechanism could serve a useful purpose to counter the inflation. Interested to see if the idea progresses at all.

1 Like

Generally in favour of the UEB but would like to see it enabled in the context of giving RPL holders special privileges which in turn make it more favorable to hodl and apply it than to sell. Less selling pressure in turn supports RPL value making it more valuable as collateral. Its worth considering a few other aspects which do not seem to have been included in this discussion so far.

  1. How much RPL is available as additional collateral seems to only consider that which has already been staked and is visible in operating nodes. Anecdotally I know of many holders who are hodling RPL off their node hoping that the RPL/ETH ration will increase, thus enabling a more profitable swap to ETH for staking nodes or requiring less RPL to be committed for collateral for a new minipool.
  2. NO’s expectation of RPL rewards has been dramatically reduced due to the rapid diminution of the original high returns caused by RP whale stakers. Rewards now are far more modest and are best regarded as one of a number of benefits to holding RPL rather than the only way to earn a return.
  3. The crypto market downturn in late 2021 has had an impact on the value of RPL meaning that hodlers are keen to see real returns increase as opposed to windfall capital gains which in turn lead to selling pressure.

So what I would like to see is that this UEB concept is advanced as part of a planned series of extra uses for RPL which make it more attractive to hold. These could be :-

  1. Provision of governance capability.
  2. Provision of a lending capability to enable to RPL to earn a return for holders through a market within the RP platform or for us to sponsor such a facility via AAVE or similar.
  3. Prioritising RPL holders for access to SAAS partners in proportion to the collateral they contribute to RP TVL ie both their staked ETH and RPL is considered to be their supporting collateral to participate in SAAS staking projects. I see this as important because there will be SAAS clients who will want RP to provide a panel/consortium of NO’s to meet their staking requirements as opposed to dealing with just one NO.
  4. Similarly prioritising distribution of MEV returns to RPL holders who have staked within the RP system as opposed to passive hodlers or those who have staked on other platforms.

I’m sure there are other benefits that can be provided to RPL hodlers but as you can see there is a lot we can do to make it more lucrative to hold than to sell.

2 Likes

is this proposal dead?

I think we’ve gone a different direction to hit similar goals? LEBs to increase minting capacity, and SaaS to provide fully custom levels of RPL exposure. (see Atlas Discussion).

1 Like