One SaaS to rule them all
The secret is out. Everyone and their mother’s investment manager wants of piece of the ETH staking pie. Every day the validator queue increases in length as one VC or another drops $200M into Lido or Coinbase. It seems that there is no competitive edge in the space. The lindy effects strongly emphasize Lido’s role in the market for any DeFi-centric whale and the KYC protections of Coinbase and co. separate themselves as the only options for some.
There is another path forward. To beat the market you must adapt what the market offers to what the market demands. I do not say this lightly, the first SaaS to effectively onboard people to Rocket Pool without the end-user interacting with Rocket Pool is going to explode. By the end of this, I think you will agree.
The current market
Lido dominates 75% of all new ETH inflows. This is total ETH staked and increases if you look at just liquid ETH staking. Lido offers some compelling advantages, namely infinite deposits, incredibly deep liquidity, and strong lindy effects. Institutions who don’t want exposure to non-KYCd entities are forced to stake with CeXs mainly and avoid DeFi. Opportunistic VCs/hedges see Lido as the best way to access staking yield and build complex strategies. Despite all these benefits, the most profitable method of staking ETH is outside the Lido ecosystem entirely – it’s offered by Rocket Pool but no one wants to run a node.
The lack of edge for new SaaSs of the classic type
To understand why Lido dominance is up only, consider the headwinds facing new SaaSs. APRs are only decreasing. The current highest APRs are found in the protocols that launched early, however, these APRs are trending down towards the mean ETH protocol APR. This is an effect of the APR being higher when less ETH was staked. Most large intuitions have already diluted these high early yields into the much larger recent deposits (lido for example). Thus, any new SaaS entering will start at a lower APR and work downwards, meaning it’s disadvantaged in even more ways.
The Possibilities unlocked by RPL for Node Operators
A Rocket Pool node operator requires at least 10% of ETH locked to be backed by RPL when the pool is launched. For this additional cost, node operators are rewarded in RPL inflation, with a higher coll ratio (up to 150%) rewarding a higher share of the inflation. Currently RPL APR is 13.7% vs 5% for ETH. This is a huge discrepancy. Further, the RPL rewards are paid out ~monthly so they are available immediately rather than locked like ETH rewards until Shangai. The operator also earns a 15% commission on 16 ETH pulled from the Rocket Pool DP, about 3x higher than Lido node operators.
Currently, node operators at max collateral earn around 10-11% APR overall, giving a 5-6% window above normal ETH APR. This creates headroom where a SaaS can adjust APRs by selectively selling RPL inflation and managing commission.
An outline for the RP SaaS with 3 novel ways to create an edge:
Simple High Yield (variable) Liquid Staking Token
If a SaaS wants to keep things simple it can create a token that accrues value along the following formula (ETH APR + commission APR + RPL APR - SaaS fee). This is similar to the Lido model where 10% is cut from staking rewards and the rest goes to the stETH token.
Another formula worth exploring is one in which the RPL and ETH APRs are separated apart. Since Rocket Pool gives a higher base APR for the nodes based purely on commission, a Lido-like SaaS built on top of Rocket Pool can elect to keep all RPL rewards and instead release a token (ETH APR + commission APR - SaaS fee). Lido takes a 10% cut from base ETH APR and so this simpler method gives the SaaS >25% of the APR higher. (Lido is 10% below baseline, this SaaS at 0% fee would offer 15% above baseline)
This division of the ETH and RPL APR could allow for separate staking of RPL such that the SaaS does not have to have RPL exposure. A splitter contract is currently being researched and may be ready very soon. Such a contract will allow one party to put up ETH and another party to put up the RPL while both parties retain individual custody. In this scenario, RPL price risk is removed from the SaaS and the liquid staking token and absorbed wholly by independent pure RPL stakes.
However, if the SaaS chose to offer the higher APR route that compounds RPL, the SaaS would be able to take a large cut and still offer above-market rates while RPL APR is high and the RPL/ETH ratio is steady. The SaaS would be able to supercharge growth by providing minor incentives to the token in a liquidity pool as seen by Rocket Pool in the rETH/wstETH pool. A high base yield should draw attention to itself and reduce liquidity costs. Liquidity will be important pre-withdrawals for growth. Using Rocket Pool as infrastructure reduces the cost of liquidity by increasing base APR.
This RPL variable rate strategy does not have to be a liquid staking token. This strategy would function just as well as a vault where users deposit ETH or RPL. For many, this would also create a tax benefit since there is no swap.
TLDR of this section: A SaaS can retain RPL custody and keep RPL rewards, retain RPL custody and distribute RPL rewards, or could let users hold RPL custody and separate rewards out. Current ideas for this separation are based on Argent/Gnosis safe separating control of RPl and ETH.
Fixed ETH income products
The large RPL APR headroom allows any creative SaaS the ability to create niche products like vaults with different fixed ETH return rates. A smart SaaS might price these like yield curves in tradfi and would pay for the yield through RPL rewards.
For example, the current ETH APR is ~4.9% so normally a fixed income product for ETH staking would have to have a negative curve following the natural decline in ETH return as more validators come online (perhaps a 4.5% rate). However, by staking RPL as collateral and liquidating the RPL rewards for ETH, the SaaS can offer as short as a 1 month fixed ETH staking vault with a year-on-year 10% APR. Since withdrawals are not yet live, the SaaS would pay a liquid token representing locked ETH (sETH). This liquid staking token would be paid out after 1 month plus the bonus income that was priced in from RPL rewards. Since RPL rewards are claimable monthly, these can be paid in ETH. In the case of a 10% vault, half of the rewards would be payable immediately in ETH from RPL sold. Yield from the short-term vaults would ostensibly be higher than 10% for the ETH deposited into the vault and so this excess should be used to supplement the longer-term vaults (or go to a central treasury).
The SaaS would be most performant running near a 150% collateral ratio so that the treasury builds and is able to maintain a surplus insurance layer. In other words, the headroom is large enough at the current ETH and RPL APR discrepancy, that a SaaS would be able to offer very high ETH rewards and build up a treasury for safety (in case of black swan events such as RPL price crashing for some reason). This also does not factor in the commission being earned which could be used to boost yields higher or increase the SaaS treasury.
Some other fixed-income product ideas are:
-f-inETH - fixed product form that locks in a rate for x years
-d-inETH - dividend style inETH that represents pools where the RPL rewards are sold for ETH immediately for dividends
-min-inETH - min RPL coll minipools, lowest risk lowest return
-max-inETH - max RPL coll minipools
institutional liquid staking with KYC (would require internal LPs too)
Here things get more theoretical. One strategy based on how rocket pool works would be as followed: 16 E comes from DP (randoms) and 16 E comes from the user for the node. The 16 DP ETH is represented by rETH and cannot be KYC compliant. The SaaS can issue 16 inETH, institutional node ETH, to represent each validator spun up (similar to the liquid staking idea presented above). Since the SaaS is permissioned, it doesn’t have to worry about responsibility misalignment as Rocket Pool did when they tried to implement something similar. This inETH is then only traded on KYC channels.
Challenges for KYC
Buying RPL at size may be difficult, but OTC with worthalter may be plausible. A SaaS can opt to create a system for users to stake pure RPL in return for part of the RPL inflation. This would reduce the capital requirements of the SaaS but reduce overall revenue (however, with a proper fee on inflation this may actually be net profitable) -selling RPL to kyc’d institutions seems limited with no major CeX listing, perhaps a 3rd party liquidity provider such as GSR may be used.
Is this actually sufficiently KYC only?
Yes and no. Technically speaking, only at the point the validator goes live does the SaaS ETH mix with the Rocket Pool’s non-KYC pool. When live the ETH is in one pool. However, the deposits to the beacon chain are made separately such that a singular chain of custody with KYC can be established up until depositing into the chain. This is, practically fully isolating the SaaS’s ETH from the non-KYC pool. I believe it is an important distinction that the KYC pools will all have their own deposits made exclusively of KYC’d ETH with KYC’d operators. However, the SaaS will earn commission from the non-KYC 16 ETH’s rewards. This may open up exposure. For example, say Evil Inc. deposited to the RP deposit pool. Overzealous Inc comes in and says “Hey you institutions! You have Evil ETH in your possession!” SaaS can say “Hey Overzealous, in fact, we only have access to and interact with KYCd ETH. The ETH is deposited separately and we have no interaction with Evil Inc.” This argument fails if the Institutions are profiting from commissions on Evil ETH. Thus, I suggest that the SaaS, to retain complete separation between institutional funds and any ETH that could be Evil, keeps the commission for themselves. Technically, the commission can only be separated out once the pool is withdrawn and so it is not possible to completely separate KYC commission from non-KYC commission
Even more theoretical extreme KYC compliant route
Do a 32E deposit using KYCd ETH to Rocket Pool and then immediately request a refund for 16ETH. Then, redeposit ETH for rETH, and sell rETH for KYCd ETH from someone like GSR, repeat. All ETH in the minipools will be KYC compliant and so commissions will be compliant as well. However, 16 of the pool’s ETH will be marked for the protocol, meaning the SaaS loses custody. This is made whole only after the sale of rETH for new ETH. There are clear cons to this strategy. It requires significant organization of funds. rETH demand is incredibly high so market makers should want to access this market. It requires the SaaS to accept custody of non-KYC ETH even if the institutions have no exposure.
The present optimal route forward would be for a competitor to emerge that emulates Lido’s design principles but is built on top of Rocket Pool. Such a SaaS will have many options as outlined above.
General design flow:
ETH deposit comes into SaaS, minting new liquid token → When ETH in waiting reaches 16, RP Deposit Pool contract is queried → if the pool has >16ETH* available, randomly assign one of the whitelisted operators a newly formed minipool
*depending on SaaS design an RPL insurance check may be required as well. In a SaaS where users stake their own RPL, the contract must simply make sure the overall SaaS collateral ratio remains >10% before launching new pools.
Problems to be overcome:
The Lido smart contracts may need modification to handle RPL reward distribution and commission. Further, this strategy is limited by the demand for rETH in RP. This can be overcome from the Rocket Pool end by incentive, or the SaaS can mint rETH with some of the inflows. Such a flow might add the step to deposit some ETH into the deposit pool if the deposit pool is less than 16ETH while the SaaS waiting pool is over 32 ETH. A trustworthy node operator set would have to be assembled. Such a fork would have success looking toward the existing Rocket Pool community of nearly 1000 individual operators.
Philosophically any better?
Such a SaaS should, at the outset, commit to growth limits so that the woes that befell Lido are not repeated. Having pre-set limits will reduce the chance that such a SaaS consumes all of Rocket Pool. Any SaaS that chooses to proceed without self-limiting philosophies in mind likely will not see support from the broader Rocket Pool operator community. Perhaps, the SaaS should give the Rocket Pool DAO an avenue to intervene.