FeedProjects
Developers
Settings
🎉 A new chapter begins: Boardroom has joined Agora
Learn more
protocol logo
Explore / Projects
Gearbox DAO

Proposals

Members

Information

Create Proposal

Gearbox DAO

ProposalsMembersInformation
Proposal
Back to Proposals
closedEnded 2 years ago · Snapshot (Offchain)

[GIP-126] Reassesment of risk parameters for LRTs

By 0x031D...D5a2AA

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

Continue Reading
Connect Wallet to Add Note
0
Votes 42
VoterCast PowerVote & Rationale
0xC4CA...43153B
71.795M

Approve

0x6D52...ceA2d7
60.101M

Approve

0xa564...E70103
55.304M

Approve

0xAa16...056c17
40M

Approve

0xf3D4...49d89E
34.36M

Approve

SHOW MORE
VOTE POWER
0
Connect Wallet
Proposal Status
  • Sat April 27 2024, 03:39 pmVoting Period Starts
  • Tue April 30 2024, 03:39 pmEnd Voting Period
Current Results

1-Approve

374.752M

Quorum 374.752M/200M
DocumentationBrandingContact Us
Home
This Project is Currently Disabled

If you would like to enable it, please checkout below.

Boardroom Subscription

Sign up for an individual subscription (access all projects on the platform)

Subscribe
Enable Project

Enable the entire project for every user

Enable Project
Contact Us