Create "stETH" for rocket pool

I have an idea of creating a new stETH token, using the Rocket pool Node Operator instead of the normal ETH staking.
This would add 15%ETH(+RPL) rewards, while not adding that much risk compared to stETH?

You can still take a fee for like 10% of the rewards, this will benefit both Lido and Rocket pool, since rocket pool are in need of more Node Operators and are now providing constant 15% extra ETH to node operators.

Are there any big risks or reason not to do this?

That is a moderately hard to execute, moderately lucrative thing, but it has two major downsides:

  • it runs against the ethos of rocketpool (getting a lot of independent stakers that use their own money as collateral). It is inevitable to happen if rocket pool wants to have any growth, but I wouldn’t want Lido to exploit this particular disconnect between the ethos and the incentives in the system
  • it will put Lido under governance risk from Rocket Pool, where some high-risk smart contracts (e.g. eventual implementation of withdrawals and rewards distributions) are currently controlled the team-selected Oracle DAO. Given Rocketpool and Lido are competitors, and some voices in Rocketpool community can be quite hostile to Lido, that is undue risk IMO.
2 Likes

Adding to Vasiliy’s points, in my opinion there’s a few big reasons this proposal doesn’t really make sense to do.

The main reason not to do this is it doesn’t line up with the stated ethos/purpose of rocketpool (which is to create a decentralized (implied that validators are somewhat well-distributed across the operator set) network of operators where the operators are putting up their own ETH as the “bond”, which is equal to half of the 32 ETH deposit + >= 10% of that as RPL). If we implement this proposal, then most of the validators on Rocketpool will eventually end being allocated to Lido Node Operators (NOs); this will happen because the relative “cost” of spinning up a minipool for a “normal” rocketpool NO is much larger than for a Lido NO, since in the latter case the bond just comes from deposits to Lido instead of own funds. This leads to a curious outcome, which doesn’t really make sense: what’s the point of a rocketpool operator set that is e.g. 90% Lido operators and 10% rest? If rocketpool wanted something like this, they’d just allow the creation of unbonded minipools, or they’d allow/encourage a set of operators who could draw their bond from users. In either case market dynamics will likely work out in such a way that these “super-operators” will have an outsized majority of validators, so again it’s antithetical.

A second issue is that this likely doesn’t even make sense to do economically speaking, or at least it’s unclear enough that the cost/benefit isn’t easily calculable. One example: when 32 ETH is deposited by Lido to the beacon chain for 1 Lido validator, all 32 of that becomes (32) stETH, and Lido NOs are paid in stETH which means that their rewards are immediately usable. In rocketpool, for every validator created only 16 of the 32 ETH is made available on the execution layer (eth1.0) side in the form of rETH, which means that the other 16 (the bond) is still illiquidly locked on the beacon-chain, and cannot be used in defi. So, doing so only makes sense if the additional rewards in RPL + the extra commission are greater than the possible rewards of using 16 ETH worth of stETH in defi PLUS the opportunity cost of that 16 ETH and its rewards being illiquid, which doesn’t sound appealing or capital efficient (i.e. creates exposure to yet another asset which needs to be managed by Lido and Lido NOs). There’s additional ways that the bonding mechanism creates capital inefficiencies, for example the staking rewards that would accrue to the “operator-side” 16ETH are not immediately represented (liquid) on the execution layer side, so you’d need to create yet another token if you wanted make these rewards available to NOs and – more importantly – the stakers whose money constituted the bond.

A third issue, and perhaps most crucial from a business development and protocol growth perspective, is the inefficiencies this creates with regards to defi. The complications here literally multiply because everything you do for one token (stETH) you need to do for another (new stETH), which means facilitating additional liquidity, building and establishing integrations with defi projects, bridging tokens, etc. For most of these activities, doing so for multiple tokens that pretty much do the same thing is actually anti-synergistic (e.g. 100m liquidity for a certain pair is arguably more than 100% better than 50m liquidity for one and 50m liquidity for another). Apart from this, you’re basically creating/supporting an asset that cannibalizes value from stETH due to how staking on Ethereum works (increases in staked ETH decrease overall APR for all staked ETH), so you end up spending 2x as much and working 2x as hard to support 2 assets and it’s highly unlikely that any additional rewards would make up for those costs.

A fourth issue is that this creates unnecessary complexity from a smart contract perspective and vastly increases the surface area for potential issues.

2 Likes