[AIP-55] Set rETH and stETH Deposit Caps to Zero

ov3rkoalafied

Summary

This proposal aims to set deposit caps for stETH and rETH vaults to zero, due to issues surrounding the stETH and rETH pegs to ETH. The proposal also offers an option for rETH vaults harvest functionality to be updated to enable harvests to occur prior to Ethereum allowing withdrawals of staked ETH.

stETH:ETH

Recent market volatility has reduced the willingness of people to hold stETH vs ETH. This has led to a consistent, significant de-pegging of stETH against ETH in the market, which currently sits at 0.970:1 .

A note on Alchemix vault losses

Alchemix Version 2 was built to gracefully handle vault losses. The Alchemix debt systems will operate nominally when a loss of 1-25 bps (actual value set by governance) occurs. Losses larger than this trigger the “check loss” circuit breaker, which exists to prevent users from realizing too much slippage when calling the withdrawUnderlying or liquidate functions. When _checkLoss is called, it calculates the current-value of yX, or “how much of underlying token uX is currently represented by the amount of the yield token yX that the Alchemist holds”. The current-value of yX is compared to the expected-value of yX (a number calculated every time yX is deposited, withdrawn, or liquidated from the Alchemist). If the current-value is less than expected-value by more than the governance-configured maximumLoss bps, the transaction will fail.

The following functions use the _checkLoss circuit breaker:

deposit
depositUnderlying
withdrawUnderlying
withdrawUnderlyingFrom
liquidate

If a sustained loss is realized by a vault, governance can vote to call the snap function, which resets expectedValue to currentValue, assuming the losses and allowing the vault to continue normal operation.

How does this affect the stETH vault?

In short, none of this currently affects the stETH vault. Even though a discount of stETH relative to ETH exists, the price oracle for the wstETH vault gives the stETH:wstETH price, for which there is currently no discount. Because this price oracle is reporting the correct, “on-peg” value, any call to _checkLoss passes without issue, because the currentValue is at or above the expectedValue.

How does this affect the rETH vault?

Again, it doesn’t, but for a slightly different reason. Unwrapping rETH to ETH is done by using the buffer of ETH that rETH normally keeps on standby. Due to recent market conditions, this buffer is depleted, and so unwrapping rETH is currently not possible.

Then why are you telling me all this?

Unwrapping wstETH to ETH is a 2-step process. First, the wstETH is redeemed for the underlying stETH. Next, the stETH is sold on Curve for ETH. Due to the current discount of stETH vs ETH, each unwrap (each call to withdrawUnderlying, withdrawUnderlyingFrom, liquidate, or harvest) realizes a loss equal to the market discount (currently ₆.5% at time of writing). Consequently, vault APR is reduced from 4.0% to 3.74%.

As mentioned above, unwrapping rETH is currently impossible. For this reason all attempts to withdrawUnderlying, liquidate, or harvest rETH will fail.

This is a risk that was assumed when these vaults were initially launched, and one of the reasons that they were launched as “beta vaults” with low deposit caps.

Another risk produced by the current situation is that of stETH/alETH and rETH/alETH arbitrage that would push the price of alETH down to the stETH/ETH and/or rETH/ETH price. Users could buy stETH and deposit it, take an alETH loan, use it to buy stETH, and loop that as much as they want (or at least until stETH = alETH). In order to prevent this from getting worse, the deposit limits should be set to 0.

Moving forward

To be clear:

All Alchemist functionality is currently operational for the wstETH vault, but users will realize the market discount when using the withdrawUnderlying and liquidate functions, and every harvest realizes the same.
The withdrawUnderlying, liquidate, and harvest functions are not currently operational for the rETH vault. No user will actively see their debt reduced due to their rETH yield until harvest becomes functional again.
This proposal has been created to set deposit limits for the stETH and rETH vaults to 0, in order to prevent any future deposits.

Once the ETH1-ETH2 merge is complete and staked-ETH withdrawals are activated, both stETH and rETH should be redeemable for ETH at a 1:1 rate. At that time, new TokenAdapter contracts will need to be written, deployed, and activated by governance in order to take advantage of the new functionality in the Lido and Rocket Pool protocols.

In the meantime, there is the option (should the DAO decide) to deploy a rETH TokenAdapter that uses a DEX to unwrap rETH for ETH. This would allow harvests to continue for the rETH vault, but with the market discount applied (as it currently is for the wstETH harvests). The community should indicate if this is a desired use of dev resources.

VOTING

FOR vote indicates that stETH and rETh deposit caps should be set to zero in order to minimize reduced yield and arbitrage when alETH > stETH/rETH
AGAINST indicates the desire to leave the deposit caps as is and let arbitrage/reduced yield play out (this effectively means alETH will trend towards stETH/rETH pegs)

The intent of this proposal is also that the rETh vault adapter is updated to harvest rETH through DEX liquidity.

rduubs

This was very helpful and useful for understanding why alETH has been off-peg as well.

To clarify, here are some questions:

Users only realize loss when they repay with alETH and then withdraw in the underlying (ETH)?

How does this proposed change and the situation with stETH harvests interact with the proposal for the changes to the alETH transmuter?

ov3rkoalafied

rduubs

Users only realize loss when they repay with alETH and then withdraw in the underlying (ETH)?
Repaying with alETH or stETH would actually be better than repaying with wETH, due to the discount. The loss is realized first when yield is harvested, and then secondly when withdrawing underlying. This is because harvest convert everything back to the underlying to send to the transmuter/AMO (and then give an equivalent amount of alETH available credit)

The overall vault is realizing a loss in yield by selling stETH in to ETH and redepositing as vanilla stETH (vs buying off market) as part of each harvest? This harvest system seems counterproductive if so because of the discount.
This is the only way we could launch these vaults prior to the merge and subsequent ability to unlock ETH.

The arbitrage you described for stETH, is there any data on how often this has been performed? It looks like the vaults are full now, so is there any risk of this arb continuing even if deposit cap isn't set to 0?
I don't believe many people have taken advantage of it. This is somewhat proven by the fact the alETH peg has generally remained above stETH. alETH peg is right around stETH now, meaning that there isn't an arb to be had. However, AIP 54 proposes restoring the alETH peg - if we did that prior to resolving this proposal, we'd see the arb loop play out. If we set the deposit cap to zero, then at most only the current depositors could claim the arb (which would be a pretty small arb given stETH is only at 0.97 rather than the much lower values it was at in the previous weeks). Additionally, the fact alETH is approx = to stETH right now is why we could publicly launch this proposal without worrying about bringing attention to an arb opportunity.

How does this proposed change and the situation with stETH harvests interact with the proposal for the changes to the alETH transmuter?
See above, primarily if we left the deposit caps > 0 then in an efficient market alETH peg would never really be able to go above the lesser of rETH and stETH.