eIP 41 LDO RAI MIM FRAX COMP AAVE SNX BAL BUSD CRV 1INCH YFI

Author: Seraphim
Submission date: 20 Dec, 2022

Simple summary
Increase the borrow factors to 0.70 for the following assets: LDO RAI MIM FRAX COMP AAVE SNX BAL BUSD CRV 1INCH YFI. Also change the IRM model to Major (same as UNI, LINK).

Motivation
While highest tier assets on Euler have risk factors reflecting their risk profile, longer-tailed assets have extremely restrictive risk factors. This makes borrowing them unviable. This proposal is intended to increase capital efficiency for borrowers and shorts.

Now that Euler implemented Chainlink oracles, the prospect of oracle manipulation has decreased significantly. This is why I think this proposal won’t significantly alter Euler’s risk profile.

Let’s discuss if this list is exhaustive or some items should be dropped.

  • Yes, in favour
  • No, against
  • Let’s modify the proposal

0 voters

4 Likes

Maybe LUSD as well? Probably it would contribute to the process initiated in
[RFC] Promote LUSD to Cross Tier

Yeh, I haven’t included that as it’s already being discussed in that thread.

1 Like

I am in favor of this.

What do you think of BUSD having 0.9 according as of this RFC

2 Likes

We’re in favour of increasing borrow factors for high-quality assets. We think this update appropriate given that borrow caps will be enforced for these assets in the near future.

We will submit a proposal with tailored borrow caps for each asset in the upcoming weeks.

3 Likes

Thanks for the suggestion. Is there any risk simulation which you can link to for assessing the implications of this BF?

Title eIP41: increase-borrow-factors-for-ldo-rai-mim-frax-comp-aave-snx-bal-busd-crv-1inch-yfi-snx
Author: Seraphim
Submission date: 02 Jan, 2023

Simple summary
Increase the borrow factors to 0.70 for the following assets: LDO RAI MIM FRAX COMP AAVE SNX BAL BUSD CRV 1INCH YFI SNX. Also change the IRM model to Major (same as UNI, LINK).

Motivation
While highest tier assets on Euler have risk factors reflecting their risk profile, longer-tailed assets have extremely restrictive risk factors. This makes borrowing them unviable. This proposal is intended to increase capital efficiency for borrowers and shorts.

Now that Euler implemented Chainlink oracles, the prospect of oracle manipulation has decreased significantly. This is why I think this proposal won’t significantly alter Euler’s risk profile.

Snaphot
https://snapshot.org/#/eulerdao.eth/proposal/0xe7c406fdab1921b489ea3435d295204adb66597a750141ce540c5bca3185167e

Sorry to not have caught this sooner, but SNX is listed twice; was it just an accidental repeat, or was one of these intended to be a different asset (SUSHI comes to mind)? Would appreciate clarification on this before voting, thanks!

1 Like

Oups I’ve merely double-counted SNX. Sushi is a good idea but requires an oracle update. Will likely be implemented separately.

1 Like

Unless there’re no borrow caps, it seems that not all assets have enough liquidity for BF increasing. I think we shouldn’t sacrifice security for capital efficiency
To accept this eIP, Euler Protocol have to implement borrow caps => raising BF.

I strongly oppose this proposal. Yes, these markets have switched to Chainlink oracles, decreasing manipulation risk (this assumption may even be incorrect), but not by much for all of these assets.

The more capital backing a price, the stronger that price is, right? This proposal assumes that Chainlink has a stronger oracle for all of these assets because it encompasses prices across the entire market rather than just on Ethereum.

But here’s the thing; for some (or possibly all) of these coins, most of the liquidity is on Ethereum already.

I have good insights into the COMP market, so let’s look at it, for example. Binance.com is the CEX with the most volume and liquidity, with Coinbase in 2nd place. On Binance, about $475k of support (buy orders) is currently visible on the books. DefiLlama’s aggregator shows there’s about $1.8M of support on Ethereum. The majority of liquidity for COMP is on Ethereum.

Here’s how to attack Chainlink’s COMP/ETH price feeds. Sell (or buy) a substantial amount of COMP via DefiLlama’s aggregator to move the price a significant amount. Trading bots will respond in a matter of seconds by selling (or buying) significant amounts of COMP on CEXs and buying (or selling) cheap COMP on Ethereum to perform arbitrage. Since Chainlink’s oracles are volume-weighted (iirc), the attacker can make a lot of trades at a low (or high) price to further manipulate the oracles. There are several ways to attack Euler subsequently.

With unlimited supply and borrow caps, extending so much credit to such illiquid markets is dangerous.

1 Like

We agree that borrow factors should only be updated given the implementation of appropriate borrow caps.

it’s only borrow factor and those assets are not being used as collateral so i believe the risk might be lower(?)

Those assets are already available in most borrow lending platform as collateral, enable more borrow factor is worth to try imo

I agree that the risk is lower with an increase in borrow factor rather than an increase in collateral factor. I still think this eIP significantly increases risk.

If we look at the attack performed on Aave in late November, it was done by borrowing CRV, and even with Aave using Chainlink oracles. That attack serves as a blueprint for borrow-based attacks.

Following the Aave-CRV attack, lending protocols began large-scale restrictions on depositing and borrowing activity. To this day, many markets on Aave are frozen: see here. Compound, on the other hand, began managing strict supply and borrow caps that are updated regularly as activity and the markets change.

I think this proposal is too risky.

i think it’s different type of case. You can use CRV as collateral on AAVE which drive the deposit number up from people want to borrow some stable, notably one of the curve founders. Without being able to use asset as collateral, the upside for deposit is only coming from demand of short position or yield farming eul emission which will naturally capped the supply.

Altho i think the list needs to be trimmed lol. We can start by qualifying those asset based on the liquidity and then decide. Maybe we can start from stable first then move into long tail asset.

saying “no” to long tail asset cus it’s risky i think would be bad business decision in the long run. This is why there’s tier level, to see whether there’s enough demand and reasonable risk for that particular asset.

Let’s modify the proposal but overall still in favor

1 Like

I generally agree.

Risk is lower as borrow usage with respect to overall market liquidity is low, which can warrant a higher borrow factor. This is something we’ll have to monitor. Hopefully Euler doesn’t grow faster than the speed at which governance can notice changes and adjust risk factors.

I think it’s important to also look at volatility, both historical and implied. Doing so would warrant stablecoins higher borrow factors than volatile coins.

dynamic adjustment of risk factor is something that is impossible to be done using shared pool model like now. i personally believe there wont significant increase on risk since it’s short only asset here.

Still in favor but im starting to see potential problem here just like the rest of other lending platform. it’s not really feasible to keep doing manual changes to the collateral factor/borrow factor for each asset in the future.

1 Like

Why do you say dynamic adjustment of risk factors is impossible?

I’ve heard many lending protocol leaders say this, so maybe you’re saying this for the same reasons as them. Common reasoning for this belief is that using dynamic risk factors can lead to liquidations. If a collateral or borrow factor were to change by 50%, yeah, that would be a problem. The solution would be to limit how much a risk factor can change in a day. A risk factor changing without notice could also cause problems, even if the change were small. The solution would be to have a delay before changes are implemented. If it can be possible to notify users of upcoming changes affecting them, even better!

I’d love to see more discussion on this topic.