Modelling how ETHplus would react to a deep and sustained stETH depeg and what actions we can take via governance to mitigate loss
Summary
ETHplus currently holds 50% (~$180m) of its collateral basket in stETH as it is considered a safe and liquid asset that dominates the LST category. However, over the last month the withdrawal queue has increased from less than a day to where it sits now at 18 days as the levered stETH trade unwinds. The unwinding and subsequent lengthening of the withdrawal queue has led to a sustained 25-50bps depeg of stETH against ETH.
Current Risk: The sustained 25-50bps depeg of stETH has raised concerns about a possible default which if flagged and sold-off by the protocol would leave ETHplus holders and RSR stakers with significant losses.
Protocol Mechanics: Currently, the protocol will programmatically sell off stETH if a 2.5% or greater depeg persists for 24 hours. The protocol will auction of the stETH to bidders but itâs likely the majority will be sold through on-chain liquidity. A worse case scenario model, which sells stETH entirely through a DEX, leaves ETHplus with $48m in losses. Leading to an complete seizure of the $7m RSR backing to re-collateralise the basket but this will still leave ETHplus holders with a 11% loss.
Likely Exit Dynamics: The worst case scenario modeled above is not likely to happen in practice as many ETHplus holders will exit their ETHplus positions and choose illiquidity via the withdrawal queue rather than choosing liquidity with the protocol seen as though this option allows for 1:1 redemption. The actions of these ETHplus holders reduces the amount of stETH that has to be sold via DEX liquidity, reducing loss first for the remaining ETHplus holders and then RSR stakers seen as though the dollar value of over-collateralisation remains constant.
Mitigation Options: A number of options exist; accept current parameters as safe and do nothing, increase the default detection threshold, increase the default delay, a combination of both or turning off default detection on ETHplus collateral entirely.
Proposal: Extend the default delay up to one week to allow for stETH/ETH arbitrage and holder exits reducing the degree of loss to the remaining ETHplus holders and RSR stakers. Alternatively, considerations should be made for disabling default detection entirely to enable further ETHplus growth unconstrained by LST liquidity.
Problem Statement
Over the last few months we have seen stETH experience a sustained depeg of 25-50bps. Given stETH enjoys a 50% allocation, roughly $180m at the time of writing, in the ETHplus collateral basket this has raised concerns and triggered discussions on how the ETHplus would fare if the depeg was to deepen, get flagged as defaulting and sell off its allocation.
As RToken champion this is my attempt to centralise the discussion regarding the stETH depeg and educate all stakeholders on why and when the protocol would take actions against a stETH default so we can make appropriate and data-backed decisions on the future of ETHplus together.
We have seen a weak correlation between the stETH depeg and withdrawal queue since it started lengthening on the 16th June. The withdrawal queue has extended from 0.3 days to exit to an all time high today, August 29th, of 18.2 days while the stETH depeg has remained in the 25-50bps range. The depeg has however fallen as low as 82bps once and tapped 50bps 3 other times in the last month, these were however short-lived lasting ~1 hour each time.
*Queue data from validatorqueue.com.
The most eloquent explanation that Iâve found on the depeg stETH is experiencing is from @robdogeth (twitter), founder of Cork protocol and I suggest you familiarise yourself with his introduction and follow-up articles to get a good grounding on the topic before continuing here.
Current Parameters
Currently the Yield Protocol will programmatically sell off ETHplusâ stETH portion of the collateral basket if a depeg is detected and the default delay expires. ETHplus currently sets the default detection flag at 2.5% and the delayUntilDefault at 24 hours, with both of these parameters modifiable via governance.
In practical terms this means that if the stETH/ETH peg drops below 2.5% and stays there for over 24 hours the protocol will trigger an auction, ETHplus will sell off stETH and flee into its safe heaven asset, ETH.
The plug-in default tolerances and default delay can be quickly checked here, though this isnât automatically updated and best confirmed via the smart contract on etherscan.
Scenario - stETH depeg and protocol auction under current protocol parameters
As previously explained under the current protocol parameters the protocol will sell off itâs stETH allocation if the protocol detects a 2.5% or greater depeg and that depeg severity persists until the end of the 24 hours default delay but what does this mean for our two core groups; RSR stakers and ETHplus holders?
Letâs first look at the auction mechanics, when stETH fits the criteria for an auction (depeg detected and still lower than the default threshold after the 24 hour default delay) it needs to be sold off. Itâs important to note here that the protocol during a sell off always has to choose liquidity and a mark to market loss over illiquidity as it canât enter the withdrawal queue like an independent holder of stETH can.
The auction starts and bidders, likely bots, enter bids to buy the defaulting stETH. The protocol has no concept of what itâs trading against or how the bidder sources their inventory but itâs likely that the majority of the stETH sold during an auction will be sold into DEX pools, which is why onchain liquidity analysis is so important during collateral basket rebalances. Right now there is $362m of available AMM liquidity and whilst this seems like a lot, we have to consider the token has roughly $40b of TVL and only a fraction of this can be tapped at a 1:1 price with ETH. If the protocol was to sell off ETHplus entire $180m stETH allocation it would likely incur significant losses.
Using Llamaswap to model a worst-case scenario, swapping a $180m wstETH position would return $132m in ETH, a $48m loss.
In this case the backing buffer would be depleted, staked RSR would be completely seized and sold-off to re-collateralise the basket. However, there is currently only $1m in the backing buffer and $7m RSR is currently staked on ETHplus meaning ETHplus holders would also incur a loss totalling $40m, a 11% loss. While these figures are scary they are modeled on a worst case scenario where no ETHplus holders exit their positions and chose liquidity with the protocol and 100% of the auction occurs through DEX liquidity.
What I actually imagine happening during a deep and sustained stETH depeg is a large number of ETHplus holders will exit their positions and in order to join the withdrawal queue, favouring illiquidity and a 1:1 exit over chosing liquidity with the protocol well before the stETH collateral is flagged as defaulting. An âearlyâ ETHplus exit is logical seen as though large losses are likely to be incurred if ETHplus is held through the protocol auction and recapitalisation process. What this means in practice is ETHplus TVL shrinks but the dollar value of staked RSR remains constant given the 2 week unstaking delay on staked RSR, increasing the over-collateralisation ratio and limiting losses.
If 50% of the TVL was to exit ETHplus prior to the auction the protocol would now only have to sell off $90m stETH which if sold entirely into DEX pools would now incur minimal slippage which can be entirely absorbed by the backing buffer meaning zero losses incurred by ETHplus holders and RSR stakers.
Of course all of these calculations are based on liquidity being constant now and during a deep and sustained depeg. During a bonafide emergency, which I believe a depeg of 2.5% to be, liquidity is likely to be depleted as stETH holders head for the exit. If ETHplus TVL and stETH liquidity decrease at a constant rate RSR stakers are likely to be left with a significant if not total loss.
Cohort Outcomes During a Deep and Sustained stETH Depeg
To understand the real-world impact of a stETH default event on ETHplus, it is important to break down how different stakeholders would likely fare under current protocol mechanics. The following table groups participants into four broad cohorts â from stETH holders who opt for the withdrawal queue, to ETHplus holders and RSR stakers â and highlights their likely outcomes, along with the positives and negatives associated with each path. This helps illustrate the distribution of risks and trade-offs across the ecosystem.
| Cohort | Outcome | Positives | Negatives |
|---|---|---|---|
| Group 1 - stETH holders choosing illiquidity | Provided the depeg isnât caused by loss of stETH backing, this cohort is made whole after waiting in the withdrawal queue. | Zero loss on capital provided stETH backing remains intact. | Based on arbitrage APY staying constant at 10% during a 2.5% depeg the withdrawal queue will be 3 months long. A long time to be illiquid. |
| Group 2 - stETH holders choosing liquidity | Provided this cohort exits before the protocol starts its auction they will likely perform better than EThplus holders who hold through the depeg given the over-collateralisation ratio is only 2% on ETHplus. This cohort is likely selling into more liquidity with a size much less than the protocol meaning a more favourable trade. A stETH holder that holds during the protocol auction and sells after will fare much worse. | Performs better than ETHplus holders that hold through the protocol auction provided they sell prior to the protocol auction commencing. Despite taking a loss this cohort remains liquid. | This cohort locks in a loss, however this may be more palatable for some as they value liquidity over a long period of illiquidity. |
| Group 3 - ETHplus holders who hold through the auction | Providing the backing for stETH is sound this group performs worse than Group 1 and Group 2, with two caveats; the market cap of ETHplus declines during the depeg at roughly the same rate the liquidity for stETH is depleted and they sell before the protocol completes its auction. | If the depeg is attributed to a loss of stETH backing and redemptions are no longer 1:1 this cohort could fare better than Group 1. However more people would then join Group 2 and sell into liquidity, likely before the default delay has been completed meaning they would still fare better than the remaining ETHplus holders. | If over a long enough time horizon stETH repegs this cohort fares the worst, they choose liquidity and lock in a worse loss than both Groups 1 and 2. |
| Group 4 - RSR Stakers | Due to the 2 week withdrawal delay on Staked RSR, a large amount of foresight is required to withdraw ahead of time and get out unscathed. Staked RSR is first-loss capital and given the default threshold is greater than the OC ratio (2.5% Vs 2%) is likely to be seized entirely meaning a 100% loss even before factoring in auction slippage. | Risk / Reward profiles are personal and currently $7m is happy that the rewards for staking RSR out-weigh the risks probably deeming a sustained 2.5% depeg of stETH to be an extremely unlikely scenario. | However unlikely in the case of a deep and sustained depeg of stETH below the 2.5% threshold likely means a complete seizure of their stake. |
What changes can we implement to mitigate these losses while still supporting ETHplus as the leading ETH LST index?
We have 5 actions to consider;
-
Accept current parameters as safe
-
Increase the default detection threshold
-
Extend the default delay parameter
-
A combination of actions 2 and 3
-
Turn off default detection on ETHplus collateral entirely
Increase the default detection threshold
Currently the default detection parameter is set at 2.5%. In my mind this is already adequate and shouldnât be extended. @0xJMG has kindly looked into previous depegs and found that the top 3 stETH depegs were during the Celcius / 3AC Crash, the Ethereum Merge and the FTX Collapse which occurred in June, September and November 2022 respectively. As you can see from the graph below this led to a deep and sustained depeg of stETH off itâs peg of roughly 6 months with a long period below 2% and an all time low of 7.7%.
However, all three of these depegs occurred prior to withdrawals being enabled in May 2023. Turning on withdrawals has proven to be an effective price stabilisation mechanism and has held the peg extremely tight, typically within a fraction of a percent and around a 0.3-0.5% discount during high-stress periods. I agree with ABC labs decision to set the threshold at 2.5% seen as though this would certainly be a bonafide emergency and if it sustained stETH should be sold off. For this reason Iâve ruled out actions 2 and 4.
Extending the defaultDelay parameter
The current defaultDelay parameter is set at 24 hours. I feel this is insufficient for two reasons; 24 hours does not give sufficient time for arbitrageurs to arbitrage the peg back up after a sudden depeg down below the 2.5% threshold. Currently if this sudden depeg lasted over 24 hours the protocol would flag and execute a stETH auction which could have been prevented if more time was given for the peg to bounce back. A very similar scenario played out on USDC collateral in the eUSD basket during the Silicon Valley Bank collapse in March 9, 2023, if there was a slightly longer defaultDelay USDC would have repegged, an auction wouldnât have been run and RSR stakers wouldnât have been left with a small haircut.
Secondly, it doesnât give enough time for ETHplus holders to consider their options and decide if they want to choose liquidity with the protocol or exit ETHplus and choose illiquidity by entering the withdrawal queue. Adequate time should be given for ETHplus holders to exit their ETHplus positions and join the withdrawal queue, this consideration has the added benefit of reducing the market cap of ETHplus and ultimately protecting stakers, 24 hours will likely only be enough time for the most diligent ETHplus holders to do so.
On the flip side of this, lengthening the defaultDelay does add additional duration risk. By setting this at 1 week we give the peg plenty of time to continue on any downward trajectory, meaning the auction may occur at a much greater deviation from the stETH/ETH peg then with a 24 hour defaultDelay. In practice I believe this risk to be minimal as if the peg continues to worsen over the defaultDelay period more and more ETHplus holders will choose illiquidity with only those that have to choose liquidity with the protocol remaining in ETHplus, ultimately protecting RSR stakers.
Turning off default detection of ETHplus entirely
The final action that must be discussed when deliberating on this topic is turning off default detection for ETHplus collateral entirely. While this flies against core principles of the Yield Protocol there are compelling arguments for doing so.
As of the last few months the ETHplus collateral basket is pushing up against the safe upper limit of its market cap as we are bottlenecked by onchain liquidity for each of its collateral basket assets. For example ETHplus now holds 15% of all frxETH and its stETH allocation is equal to 50% of stETHâs onchain liquidity. Seen as though the protocol has to chose liquidity if any of the collateral basket assets were to depeg we would see sizeable slippage and significant losses. With any meaningful increase in ETHplus market cap this would become even more apparent.
The choice of turning off default detection isnât one governors should take lightly but without default detection, no auction would be run meaning ETHplus isnât constrained by liquidity in the same way and safe growth can continue safely. It should also be noted here that by turning off default detection RSR stakers are no longer servicing ETHplus with over-collateralisation protection and as such I believe the revenue share to stakers should be scaled down. However, the scaling down of revenue share needs to be balanced with the fact that if scaled down too low ETHplus may be left open to governance attacks.
Steelman
To ensure this discussion is well-rounded, Iâve prepared a steelman comparison of the three main parameter options: keeping detection as-is, extending the delay, or turning off detection entirely. The aim here is not to endorse one path outright but to clearly lay out the trade-offs across risk, growth, governance, and reputation so governors can weigh them transparently.
| Criterion | Keep Detection (2.5% / 24h) | Extend Delay (e.g. 1 week) | Turn Off Detection |
|---|---|---|---|
| Risk discipline | Provides hard-coded guardrails and instant clarity for stakers and holders. | Maintains discipline but avoids premature triggers by giving arbitrage and holders more time. | Removes forced-loss events; relies on holder vigilance and market repair instead. |
| Loss crystallisation | High in stress events (up to $48m modeled loss). Short-lived depegs (e.g. USDC depeg in eUSD) would still trigger an auction. | Lower, as arbitrage and exits can shrink auction size. | None if peg restores; latent risk grows if drift persists. |
| Reflexivity / run dynamics | Default can create exit stampede; auctions worsen fear. | Less reflexive; holders can weigh exit vs. queue during delay. | Avoids trigger-induced runs; exits spread more gradually. |
| TVL growth potential | Severely constrained â ETHplus is already pushing against on-chain liquidity ceilings (e.g. 15% of frxETH supply, 50% of stETH liquidity). | Moderately constrained; growth still capped by liquidity but stress events are less frequent. | Largely unconstrained, since no liquidity-triggered auctions. Growth can continue safely. |
| RSR staker role | Clear protection mandate; earns yield credibly. | Still protective, but with fewer seizures. | Diluted protection â RSR no longer first-loss backstop. Revenue share should be reduced proportionally. |
| Governance overhead | Frequent depeg monitoring and parameter tuning. Continuous monitoring of collateral asset liquidity and governance led basket rebalances required. | Frequent depeg monitoring and parameter tuning. Continuous monitoring of collateral asset liquidity and governance led basket rebalances required. | No depeg or parameter tuning required. Monitoring of collateral asset liquidity and basket rebalances still required but less critical to the health of ETHplus. |
| Market optics | Seen as disciplined, risk-aware, âinstitutional grade.â | Seen as pragmatic and adaptive, balancing risk and growth. | Seen as permissive; âgrowth-firstâ posture could invite skepticism from risk-averse partners. |
| Contagion exposure | Increased contagion as ETHplus holders can front-run the protocol auction.Withdrawals and sells into DEX liquidity prior to the protocol auction reduces the auctions efficiency. | Contagion present as ETHplus withdrawals prior to auction can weaken the LST pegs. With a longer default delay a protocol auction is less likely. Will ETHplus holders be more likely not front-run the auction, sit in ETHplus and âweather the stormâ? | No contagion over what is already present in the system as there is no protocol auction to front-run. |
| Reputation narrative | Reserveâs reputation as the leader in on-chain indexes is damaged if itâs largest index, accounting for 73% of itâs TVL, incurs substantial losses for itâs holders. | Reserveâs reputation as the leader in on-chain indexes is damaged if itâs largest index, accounting for 73% of itâs TVL, incurs substantial losses for itâs holders. | ETHplus seen to prioritise growth and flexibility. Critics may see this as permissive or misaligned with Yield Protocolâs safety-first ethos. No contagion risk for Reserve as no protocol auctions and further losses of ETHplus holders above those experienced by other stETH holders. |
Proposal
In Robdogethâs post he commented that the arbitrageurâs annualised yield for this strategy was 25%. While that may have been true at the time of his post, I find the yield for this arbitrage to have sat longer in the 5-10% range, this is collaborated by a current 0.3% deviation from peg and a 18 day withdrawal queue and the fact that Originâs stETH ARM to have a 30d trailing APY of 5.64%. Using the 10% APY upper bound of this range weâd have to see a withdrawal queue spanning roughly 91 days before we saw a sustained depeg of 2.5%.
An inspectable table and the corresponding graph for this data can be found here.
My proposal is for an extension in defaultDelay. The primary reason for this being that it gives ETHplus holders adequate time to exit their ETHplus positions and join the withdrawal queue, I believe this allowance far outweighs the additional duration risk a defaultDelay extension incurs.
Alternatively I would also be keen to explore turning off default detection for ETHplus shifting closer in principle to Index Protocol DTFs since allowing ETHPlus to continue to grow safely is a compelling argument for doing so.
Iâve chosen not to add a poll to this RFC at this stage, in favour of hearing from other ETHplus governors and key stakeholders and finding a rough consensus before moving to an off chain poll.
