[GIP-96] LRT Composite oracles and other updates

Overview

This proposal is to implement several minor improvements to the current mainnet deployment, in order to improve user experience and risk management.

The proposed updates are:

• Changing weETH, ezETH, osETH price feeds to asset/ETH x ETH/USD composite feeds, which will prevent unnecessary liquidation due to asynchronous price feed updates;
• Setting reserve price feeds for weETH, ezETH and osETH to enable partial withdrawals and improve security;
• Setting a new ControllerTimelockV3 policy that would allow the technical multisig to re-enable paused borrowing without delay;
• Increasing USDC Tier 1 Credit Manager borrowing limits;

Important note: this proposal is in the “optimistic format” previously used for GIP-95. I.e. the technical multisig will queue transactions in the Timelock simultaneously with the voting start, with the delay ETA set to at least 4 hours after scheduled voting end. Should the proposal be voted down, the veto multisig will cancel the transactions.

Composite Oracles

Currently weETH, ezETH and osETH use Redstone oracles weETH/USD, ezETH/USD, osETH/USD accordingly. However, this creates potential risks for holders of leveraged positions due to the different update times of the X/USD and ETH/USD oracles. Accordingly, during periods of high price volatility, this can lead to the difference between the values of X/USD and ETH/USD exceeding 1-2%, which can lead to liquidations. At the same time, the price of X/ETH will remain stable. To solve this problem it is proposed to use a composite oracle similar to the stETH/ETH oracle (see GIP-28). Accordingly, the price oracle for X will take the weEXTH/ETH price from Redstone, determined based on the X price on DEXs. Note. Prices of weETH/ETH, ezETH/ETH, osETH/ETH are determined based on the on-chain liquidity in the pool, and not based on the amount of ETH staked. This means that in case of high sell pressure on DEXes, the price may deviate from the peg because of 7-day withdrawal period. Users should take this into account when using high leverage.

Redstone Composite Oracle should be applied to next assets: weETH ezETH osETH Note. Other eth-correlated assets currently available on Gearbox already uses Chainlink Composite oracles.

LRT Reserve Feeds

To provide additional security against oracle providers being compromised, Gearbox uses a system with a main and reserve price feed. The main price feed is used for most operations, however, when a user attempts a partial withdrawal, a minimum between the main and reserve price feed is used. This ensures that if the main price feed is compromised and its price is inflated, an attacker cannot drain funds using a malicious withdrawal. Additionally, in case of an emergency the reserve price feed can be quickly switched to using a ControllerTimelock policy.

We propose to add the normal ETH/USD Chainlink feed as the reserve feed for weETH, ezETH and osETH. This means that for partial withdrawals these assets will be priced as min(Redstone price, 1 ETH) and in cases of emergency (if the DAO decides to switch to a reserve feed) they will be priced as 1 ETH.

setMaxDebtMultiplier policy

Analogous to the policy set in the Arbitrum deployment, we propose to change the following policy:

ICreditConfiguratorV3.setMaxDebtPerBlockMultiplier(multiplier)

Sets the max debt per block, as a multiple of max Credit Account debt.

admin - RISK_ROLE delay - 0 hours exactValue - Not restricted minValue - Not restricted maxValue - 4 updatePeriod - Not restricted minPctChangeDown - Not restricted minPctChangeUp - Not restricted maxPctChangeDown - Not restricted maxPctChangeUp - Not restricted minChange - Not restricted maxChange - Not restricted

This would allow the technical multisig to enable and disable borrowing without additional delays, which in turn gives the monitoring system more flexibility to pause borrowing if any suspicious activity is detected.

Increasing limits for USDC Credit Managers

We also propose to increase the limit for the USDC Tier 1 Credit Manager to 10 000 000 USDC (the limit is currently 5M USDC and is 90% filled). The technical multisig will also be able to raise limits on other USDC Credit Managers to up to 10M without additional voting, if their borrowing limits are reached.

Voting

Simple Approve/Reject voting