[GIP-126] Reassesment of risk parameters for LRTs

Author

apeir99n

Summary

Note: this proposal is in an optimistic format. This means that transactions to change parameters will be queued before voting ends. If the vote succeeds, transactions will be executed immediately after; if it fails, pending transactions will be canceled.

This proposal aims to gradually ramp non-withdrawable LRT’s LT to a lower value more aligned with the asset’s actual risk as well as set fundamental oracle for LRTs with enabled withdrawal.

Ramping LTs for non-withdrawable LRTs

The April 24th depeg of ezETH has demonstrated that the current LT of 91.5% is too aggressive - at the lowest point of the depeg, some lossy liquidations occurred. Even though they were fully covered programmatically by the Reserve Fund, this must not happen with correct risk parameters, and thus ezETH’s LT needs to be reassessed. The same logic is applicable for other LRTs not having enabled withdrawals: pufETH, rswETH.

Given that consecutive price deviation for ezETH during depeg was ~9%, safe LT should be set to 87% (here we take into account 3% liquidation premium and 1% liquidation fee for Restaking Credit Manager). At the same time, reducing the LT immediately will likely make a lot of existing accounts unhealthy, and hence we propose to use the `rampLiquidationThreshold` in Credit Configurator to reduce the LT linearly over the duration of 7 days. This will give existing holders sufficient time to reduce their leverage in line with the new LT.

Similarly I suggest to set LT for pufETH and rswETH equal to 87% as these LRTs don’t have enabled withdrawals as well.

For weETH, rsETH it is suggested to keep current LT as weETH already has withdrawals, while rsETH will launch it on 3 May.

Fundamental oracles for weETH / ezETH / rsETH / pufETH / rswETH

There are various designs of oracles for lending markets:

- market ones, which aggregate prices on various exchanges

- fundamental ones, which calculate the value of locked assets

- fixed ones (for example, in some lending markets USDe price is hardcoded as 1).

We at Gearbox have always preferred to use market oracles, which allow us to be the first to liquidate risky positions in the event of various events, thereby protecting the passive side. However, as we can see in the ezETH case, such a design can, on the contrary, create potential problems for LPs: with a sharp drop in price and liquidity crunch, liquidators will close positions fixing losses for the passive side and creating bad debt. Fortunately this scenario did not materialize, but nevertheless it requires to switch approaches. We propose to remove such risks by using a fundamental oracle. In this case, the oracle will broadcast the price of the actually locked funds, and even if a short-term depeg occurs, fundamentally arbitrageurs will be able to back the peg in the worst case in 7 days. At the same time, the fundamental oracle will reflect the price change, for example, which may occur in the event of a future slashing events in EigenLayer.

Fundamental oracles will be prepared by Redstone in 1-2 weeks, and we propose to implement the change once they are ready without additional voting.

We also propose to move market-based price feeds to reserve (LRT withdrawals will then be based on `p = min(P_fundamental, P_market)`) and decrease ControllerTimelockV3 delay from 8 hours to 1 hour for `setReservePriceFeed` policy.

These changes essentially allow the 4/12 technical multisig to switch the price feed from Main to reserve in 1 hour. Proposal suggests give permission to Technical multisig to apply this switch in case of unrecoverable depeg event.

Voting

Simple Approve / Reject