An idea:
Overview: Two insurance pools that work synergistically to reduce loss to rETH, where risk and cost are both spread amongst participants rather than on an individual minipool basis. The first pool (rETH) reduces impact to rETH from correlated slashing and attestation leak. The second pool (RPL) reduces variance risk to NOs and indirectly reduces impact to rETH by reducing the total amount in a correlated slashing. For this, 25% emissions currently targeted at NOs for collateral will be initially used, although these could shift between pools based on supply/demand. I would anticipate this percentage would rise in LEB 8 and LEB 4 as the total impact of correlated slashing increases while the emissions from RPL would not.
Pool #1: rETH insurance secured by rETH
How it works: Anyone can permissionlessly stake to the rETH insurance pool, and get paid a staking yield in RPL to do so. If there is a correlated slashing event (or abandoned validator > NO bond), assets from the insurance pool are burned and used to make the rETH whole up to the total amount lost.
Staked asset: rETH. This has several attributes that make it attractive to back rETH.
- It is yield bearing already, so it is more capital efficient than ETH or USDC
- It has good liquidity that we are actively incentivizing and has a soft peg that seems very unlikely to fall more than 5% relative to ETH even in times of high stress.
- There will be a LOT of ETH ejected from validators into the deposit pool during correlated slashing, so burning rETH will be relatively simple and will actually minimize ETH capital inefficiency.
- It provides another way to gain yield on rETH which drives rETH demand and buoys RPL price.
How much backing: I will base this on a being able to fully insure a 20% correlated slashing (reasoning will be under minipool below), or 6480 ETH currently. For LEB 8, I target 15% (28,000 ETH after 3x TVL increase); for LEB 4, I target 10% (40,000 after 7x TVL increase)
Incentive structure: Rewards would be 10% of 660,000 NO RPL emisions initially. 66,000 RPL rewards, at the target pool size of 6480 ETH, this equates to 15% yield per year at current levels in RPL. The stakers lose if correlated slashing occurs; they win if (as is anticipated) no large correlated slashings occur. If a lower number of people are willing to stake rETH, yield will be higher but risk will be concentrated; if a larger number of people stake, yield is lower but risk is also spread out. I expect a higher proportion of NO rewards will be required with LEB.
Nuts and bolts: rETH can be staked at any time, but can only be unstaked at the end of any rewards period. rETH unstaking will be frozen if a correlated slashing event is occurring (ie, during the 2 weeks after) until after payout has been resolved.
Pool #2: NO insurance secured by RPL
Reason: Ethereum slashing was set up for total loss of ETH bond for a ~33% slashing- this is the level that has the potential to harm the protocol. However, because Rocket Pool NOs effectively operate on leveraged ETH, they will have total loss of ETH bond at ~16% correlated slashing. In LEB 8 they will have total loss at ~7% correlated slashing, and in LEB 4 they have total loss at ~3.5% correlated slashing. As such, almost all NOs in LEB 8, and all NOs in LEB 4 will have the potential for complete loss of ETH through no fault of their own if a client bug happens. This also sets up a moral hazard, as if any client over 7% (LEB 8) will cause total loss, NOs have no incentive to choose a 10% client over a 20% or 30% client. We currently have no accurate way to track or incentivize NOs who use minority clients. This pool is intended to drastically reduce risk/volatility for NOs and incentivize use of smaller market share clients, which ultimately protects rETH and lowers the insurance needs of Pool #1.
How it works: Node operators have an option to stake into a RPL NO insurance pool. There is no maximum or minimum amount. In the event of a slashing event, each affected minipool is responsible for the 1 ETH base penalty (ie, the entirety of isolated slashings). After this, most (75%) of the correlated penalty up to pre-defined maximum is reimbursed in the form of RPL by the RPL insurance pool to the node operator. The maximum is based on whatever client Ethereum market share is desired (I will target 15% for now, 10% for LEB 8, 7.5% for LEB 4). After this pre-defined maximum, the minipool is responsible for 100% of additional penalty.
This RPL is not auctioned or disbursed immediately; rather, it stays in the staking pool and a portion is withdrawable every reward period for the next 12 reward periods. This has several benefits. First, it means the staking pool is immediately ready for another correlated slashing, and generating yield for the new owner. Second, it prevents catastrophic RPL price collapse as only ~8% will be released per month. Lastly, because this RPL is going to NOs, they may use it for running minipools/staking and not even sell it at all.
Reimbursement from this pool will need a social layer component to prevent misuse: specifically, slashings that are part of malicious attack would not be reimbursed; slashings that are due to failure to upgrade client in a reasonable time would not be reimbursed; maybe a few other examples. But the expectation is that most correlated slashings are faultless and will be reimbursed.
How much backing: Maximum payout will be with a 15% slashing: 10.5 ETH/minipool * 15% of 9000 minipools = 14,121. With LEB 8 this will be
Incentive structure: 15% of 660,000 RPL rewards annually. Given a target 14,121 ETH equivalent (1,008,000 RPL), this is 9.8% yield/year. In LEB 8, target 10% correlation, 2X number of minipools = 12,555 ETH equivalent. In LEB 4, target 7.5% correlation, 4x number minipools = 10,732 ETH equivalent. Overall, the security payment may fall with LEB
Nuts and bolts: RPL can be staked at any time, but can only be unstaked at the end of any rewards period. RPL unstaking will be frozen if a correlated slashing event is occurring (ie, during the 2 weeks after) until after payout has been resolved.
Benefits
rETH pool #1 provides much more security against correlated slashing than the current system for 10% the capital
Neither pool has min or max caps as the individual contributing is irrelevant; APR will rise and fall based on market forces
Provides another use case for rETH, since we feel TVL will be rETH bound in the medium term
Incentivizes minority clients by providing ‘free’ 75% slashing insurance, even if we can’t determine who has a minority client
Greatly reduces variance for NOs by decreasing the risk of total loss if their client has a fatal bug
Leaves existing individual RPL staking relatively unchanged and still be useful for MEV theft/abandoned validator
RPL insurance pool #2 keeps RPL in the hands of NOs, which is intended to reduce price impact
Fits in well with other ideas regarding collateral/RPL rewards, like knoshua’s https://dao2.rocketpool.net/t/redesigning-no-rewards or @nonfungibleyokem’s https://dao2.rocketpool.net/t/maximum-collateral-should-be-reduced-from-150-to-100 by allowing unlimited RPL whale staking, while reducing cost so more RPL rewards can be awarded per minipool.
Downsides
10% of current NO RPL rewards go toward rETH holders, who likely will sell them
If the inducements are successful, RPL insurance pool will need higher levels of collateral as Rocketpool minipool client diversity will look very different from Ethereum client diversity.
Back-to-back correlated slashings would bankrupt the rETH pool; a double correlated slashing would cause the initially slashed NOs to lose all their insurance payout. However, I think we have to assume back-to-back correlated slashing events are extremely unlikely, and are not worth preparing against.
RPL Pool #2 has no way to different someone who has an isolated slashing in the middle of a correlated slashing; this could lead to some rare fringe cases (NO has lost withdrawal keys, decides to self slash in the middle of a correlated slashing to get some return on their ETH)
Reply to knoshua
Thank you, those are excellent points. Sadly I know very little solidity to determine the most efficient way to detect correlated slashing. Practically, the isolated slashing penalty is applied immediately and the proportional (correlated) is ~18 days later, so I would assume identifying any validator ejected with that second penalty could trigger rETH burn from the pool; it likely would benefit from some sort of oracle, although since these events are super rare, very public, and since instantaneous recognition (<24 hours) is not necessary, it seems that a contract that could be called by any observer on #trading may suffice.
And I agree, for #1 the most elegant would be to just send rETH to a burn address/reduce supply without plan for reimbursement; I wasn’t sure if the rETH:ETH ratio accurately reflects rETH sent to the burn address without interacting with the burn contract. If you know I’ll update the proposal!
For #2 the social layer is a issue, and it’s definitely not the kind of thing I’d want to send to snapshot (particularly after this week). I was thinking more like oDAO or GMC; if a majority decides the correlated slashing (the entire event, not a per minipool decision) was malicious or through user fault (defined ahead of time), no reimbursement would occur. However, unfortunately I think this pool cannot be automated/permissionless as those decisions have to be made by humans for the time being.
I think encouragement of malicious behavior is essentially negligible as the correlated penalty paid as a percentage of ETH by the minipool remains higher than solo validators, even accounting for reimbursement if the actor somehow went undetected. Also, the pool pays progressively less once correlation is over 15% (or my goal 10% in LEB 8, or 7.5% in LEB 4), so by 30% it pays nothing- and an attack with fewer than 30% validators I think has minimal risk to Ethereum in terms of delayed finality etc.
reply to mao
My little quibble, whether it is relevant or not you can decide, is that RPL was not required for NOs until a relatively recent tokenomics change (see the white paper). So this would be somewhat a return to the prior conception. However, I completely agree that we could use RPL if we could get a good liquidation process. Currently we have liquidity in the realm of 800 ETH (this is on rocket scan, i can’t verify, nor can i tell what it was prior to the most recent RPL downturn); to handle a 15% (moderate) correlated slashing we would need liquidity in the realm of 10,000 ETH where liquidity could not be pulled after a correlated slashing was identified. I can’t think of a way to do this less expensively than my insurance pools, but if you have ideas to inexpensively increase downside liquidity, that’s what this thread is about!
reply to valdorff
You certainly don’t have to take a step back, i’ll bold that part of my original question, cause i tend to write a lot and obscure important parts. Not preparing for black swans is a very reasonable choice- maybe even rational; I am not currently preparing for a nuclear war, although the chance is above 0. However, since RPL collateral is not needed for abandoned validators (they get booted at 16E), and won’t come into play until like the 13th MEV theft for a given minipool (so 2026), saying that we don’t need RPL for black swan events is like (i feel) saying that we don’t need RPL to secure the protocol. And if no one thinks RPL is useful for security, we should consider @knoshua’s proposal to just treat it as a flat access fee/reward to run a minipool. And we should definitely not have it in the Rocket Pool explainer that RPL is “insurance,” or use it as a selling point that RPL provides additional security to rETH, if we know that is false.
Regarding LIDO, the insurance pool is not for black swan events, it would be woefully inadequate. From what i can reconstruct from: Redirecting incoming revenue stream from insurance fund to DAO treasury - Proposals - Lido Governance
it is a fund to reimburse if a single large Lido validator gets 30% of nodes slashed, or a small validator gets 100% slashed (essentially both are isolated slashing). Sort of like if Whatwall migrated and got slashed in the process. They don’t have a plan in place if one of their large validators gets 100% slashed, because the correlation penalty starts to kick in, and they certainly don’t have one for a systemwide client bug. In those cases, stETH takes the loss.
We are better than Lido from LSD security and this is one of many reasons i think rETH is far superior to stETH, but we are also paying a LOT more already (ie about 26% of our TVL is RPL ‘insurance’ compared to their 0.1% bond. And because we are operating on an insurance per minipool basis, on average only 8,000 of that 40,000 ETH would be available for any particular correlated slashing. So 2x more collateral for 30 times less LSD (60x improvement), paying 260x as much; still doesn’t seem like a good deal to me. I am hoping to see some more bang for that buck.
reply to yorickdowne
Love your work on ethstaker. small mancrush. carry on.
reply to cyberhorse
This is how I see rETH- a premium product where its security through decentralization and protection of staker value is the gold standard for the industry. I think this consumer protection is extremely attractive to (particularly) institutional investors. Otherwise, rocket pool is just a LSD that charges higher fees and has fewer DeFi interfaces.
However, currently our entire insurance comes from node operator ETH bond, which is going down in LEB 8 and LEB 4.
reply to jasperthegovghost
If I am understanding correctly (which is a rare occurrence), you suggest two separate rETH pools, where the senior tranche gets higher yield but is first up for slashing, and the junior gets lower yield for lower risk, only being used if the senior tranche is liquidated? This seems like an excellent addition so investors can self-select based on risk tolerance, if with some added complexity.
In terms of cost/reward, my calculation is that for 10% of our NO RPL inflation, we can offer ~13% yield (in addition to rETH appreciation) for a pool large enough to sustain a 20% correlated slashing penalty (single tranche); this reward seems fairly commensurate to higher risk defi applications, and I’m not sure the risk is much greater than the counterparty of a perpetuals exchange; plus currently rETH really has no substantial defi integrations besides what we are paying for.
My take is that we are already paying these emissions to NOs (ourselves) for insurance/collateral, but we are not actually getting any benefit; and if we are expected to be rETH bound, then finding ways to drive rETH demand, even at the cost of NO demand (lower emissions) will help the protocol.
Could you explain the statement: “introducing RPL rewards would broaden but not strengthen the insurance.”? Is there another way that rocket pool can incentivize the junior/senior tranche?
RPL is not touched in correlated slashings <16.1%, and even if LPs don’t pull assets we won’t have liquidity to handle a correlated slashing of >16.7% without taking a short trip to 0. But maybe the numbers on rocket scan (~800ETH of downside liquidity) or my understanding of the auction process are wildly off.