Proposal
Option 1. Execute the following changes to stETH:
- Increase the stETH deposit cap on mainnet Alchemix to 3,000 ETH with multisig discretion to decrease to 0 again if necessary.
- Modify the stETH adapter to utilize the ChainLink price oracle to report the price of stETH, capped at a maximum of 1 ETH per stETH.
- Update the maxloss() parameter to check stETH vs ETH and increase to 10% (1000 bps).
- Keep rETH deposit caps at 0 (due to lack of rETH oracle).
- A raise of 2,000 additional stETH is recommended 1 month after the initial cap raise, at the discretion of the multisig, provided stETH price exceeds 0.99 ETH.
Option 2. Keep rETH and stETH caps at 0 ETH on mainnet Alchemix
Summary of Risk and Reward
Option 1
rETH and stETH are likely to be the most popular of the current strategy offerings. Increasing deposit caps will allow users to take advantage of these strategies, and allow Alchemix to increase TVL and fee revenue. Incorporating an oracle would eliminate the potential alETH peg reducing arbitrage loop from and stETH depeg, and a loss of backing from an stETH depeg could be restored so long as stETH eventually repegs.
Option 2
Keeping caps at zero maintains the current lack of exposure of alETH to stETH and rETH peg risk. It also eliminates the rewards for users and the protocol of what would be the highest yielding ETH strategy on Alchemix. Ie, no risk and no reward.
Context
AIP-55 Background
rETH and stETH deposit caps were set to zero in AIP-55 as a reaction to stETH and rETH being off of their previously tightly held 1:1 price with the staked ETH they are entitled to, with concerns that they could drift significantly lower. The first concern is that all harvests of stETH would result in reduced yield for depositors. This is because staked ETH is not yet withdrawable, so harvests must sell directly to the reduced price liquidity pools in order to obtain ETH. Related to this concern was that rETH harvests were not possible due to the lack of ETH in the buffer (That previously allowed 1:1 redemptions of rETH for ETH equivalent to the ETH staked in the position). With the AIP-55 vote, the DAO determined that a reduced harvest was more desirable than waiting until unlocks were possible for a full-price harvest, and thus the current stETH harvest method (selling to liquidity pools) was kept the same and the rETH harvest method was updated to match.
The second concern is that of the risk that alETH takes on with reduced stETH or rETH prices. The risk can be explained with the following series of events:
- Assume alETH price is 0.99 (all prices relative to ETH). Assume stETH price is 0.95.
- Fred has 95 ETH. He sees the new alETH and stETH prices. He purchases 100 stETh and deposits it to the ETH alchemist, and takes a 50 alETH loan. He sells that 50 alETh for 50x0.99 = 49.5 ETH.
- Fred liquidates his Alchemix position, which leaves him with 50 stETH. Fred sells the stETh for 47.5 ETH. The end result is Fred now has 49.5+47.5 ETH = 97 ETH, for a total profit of 2 ETH.
- After this process, Fred notices the stETH price is still 0.95, and the alETH price is now 0.98. Fred then repeats the process again.
- Eventually Fred and others have repeated the process enough times that the constant selling of alETH for stETH has driven the price of alETH down to 0.95, matching stETH. At this point no more arbitrage can occur, resulting in alETH price that will, in theory, at most be equivalent to the stETH price.
The process shows how the price of alETH will be driven down to the price of stETH, so long as users are able to deposit to the stETH or rETH strategies.
With the deposit cap set to zero, only a user already deposited in the Alchemist has access to this arbitrage opportunity. They can mint alETH and liquidate once, but in doing so they give up their position. Additionally, most users already are minted near max debt so the potential damage from current depositors is significantly lower than from new depositors.
stETH / rETH Depeg effect on alETH backing
Note that in the process above, 50 alETH was minted and 50 stETH was sent to the transmuter/elixir from the self-liquidation, which would be converted to 47.5 ETH (at 0.95 peg). This means this 50 circulating alETH is only 95% backed by ETH in the elixir/transmuter.
One option to avoid this loss of backing would be to delay the conversion of the stETH to ETH until unlocks are feasible. This would mean that there would be less ETH available for alETH transmutation and AMO operations. This solution is not being proposed.
The proposed solution is to adopt a Chainlink Oracle to determine actual collateral value at time of loan origination and update parameters to account for this new adapter.
Proposed Solution
The Oracle will account for the price of stETH in real time. This means that when a user originates a loan, it will be based on the ETH value of the stETH they have deposited (rather than assuming a 1:1 ratio between stETH and ETH). This adjustment eliminates the arbitrage loop explained above. The table below explains how each function in the alchemist will function at present and after the oracle is integrated:
https://imgur.com/a/5g3HIeI
[image uploads are currently borked so here's a direct link, will add image or table later]
Note that with the oracle solution, maxloss() and snap() are now usable again. One purpose of maxloss() is so that users do not accidentally deposit at a time where an asset has a flash or short-term crash, thus eating significant slippage. This is an extremely unlikely event for something as liquid as stETH, and also takes away some amount of choice from the user. The other purpose of maxloss() is to determine when a vault is acting in an unexpected way (ie, losing money) and functions need to be automatically paused for evaluation.
With stETH, any depeg is expected to be temporary. Therefore, it would be counterproductive to pause the strategy for a minor depegging event. Conversely, a large depeg could consider a more permanent issue with stETH. This would require a strategy pause and evaluation. Note that if maxloss() is triggered, the strategy can only be re-enabled by calling snap() or waiting for a repeg. This means a small maxloss() value could result in the vaults being paused quickly after relaunch with no recourse but to wait for eth unlocks. Therefore, a maxloss() of 10% is proposed - large enough to capture historical stETH depegs, small enough that anything in excess of historical precedent would pause the strategies for evaluation.
Note that an oracle attack could push the price of stETH over 1 ETH, which could lead to alETH minted at a LTV ratio > 50%. Additionally, if stETH price is pushed > 2 ETH, then unbacked alETH could be minted. With the depth of liquidity that stETH has It is not economically efficient to push the price this high simply to mint from Alchemix, but it could potentially be worthwhile to push the price that high in order to exploit a conglomerate of DeFi protocols (though still extremely unlikely). Regardless, both of the concerns above will be mitigated by capping the stETH oracle price at 1 ETH.
Procedure in event of another stETH depeg
If stETH were to depeg <10%, depositors would realize the market discount when using withdrawUnderlying and Liquidate functions.Harvests would also realize the discounts. No functions would need to be paused. If the depeg was >10%, then the strategies would be paused as outlined in the second paragraph of pause control.
Note that introducing an Oracle doesn’t completely eliminate the risk. The remaining risk is that users will take full 50% LTV loans when stETH equivalent to ETH. Then, stETH could depeg, thus increasing the effective LTV of the system. A depeg to > 0.5 ETH/stETH would result in an LTV > 100%, meaning the protocol would have bad debt that users would not be incentivized to repay. At the time, this would mean a loss of backing for alETH. For example, if there were 3000 stETH in the vault, used to mint 1500 alETH, and then stETH depegs 0.4, then there would be 1500 circulating alETH that does not have a matching depositor to redeem it. As long as stETH eventually repegs, the loss of backing would be temporary. During the depeg, the effective yield rate is lower, which increases the time it takes for alETH to convert to ETH in the transmuter.
For this reason, the maxloss is set to 10%. This pauses the strategies and gives the DAO time to determine if a depeg to < 0.5 is a real risk requiring further action.
Deposit Cap Justification
When increasing deposit caps, we can evaluate the effect on the alETH price should all new deposit caps be immediately utilized to take maximum loans, in order to ensure LPers do not face a sharp price drop. If LPers expect a big price drop (due to a lot of expected loan demand in a short period of time), they may remove liquidity to front run in then redeposit after the loans have been taken. With an stETH deposit cap of 3,000 and then subtracting current deposits, at most 2,000 new alETH can be minted (assuming new deposits are max looped with other vaults, which is unlikely). 2,000 alETH sold into the curve pool would result in an alETH price drop of to 0.993 to 0.991, or 0.2% - an impermanent loss of at most a week of yield for an LPer.
Evaluating Future Cap Raises
After the initial re-launch, the vault demand, the stETH peg, the expected time until ETH unlocks are possible, the alETH price, as well as transmuter and elixir price restoring mechanisms can be evaluated to determine if a larger raise is acceptable. A raise of 1,000 additional stETH is recommended 1 month after the initial cap raise, at the discretion of the multisig, provided stETH oruce > 0.99 ETH.
a Note on Optimism
This proposal could be used as justification to launch stETH on Optimism in a separate proposal. The separate proposal would need to consider global effective stETH deposit caps when justifying the deposit caps of the Optimism stETH alchemist.