[ARFC] Optimize ETH-correlated asset parameters


Title: [ARFC] Optimize ETH-correlated asset parameters

Author: ACI (Aave Chan Initiative)

Date: 2024-06-05


Summary

This proposal seeks to update parameters on ETH-correlated assets and coordinate caps management to improve Aave efficiency.

Motivation

ETH and ETH-correlated assets are the largest reserves in the Aave protocol, leading to their usage as collateral and being one of the protocol’s largest revenue drivers.

ETH is mainly used for two use cases:

  1. Collateral to borrow stablecoins
  2. Borrowed using ETH-correlated assets to leverage loop a staking/restaking yield.

This second use case is very sensible to the borrowing cost of wETH and, if kept unchecked, can lead to a negative yield experience for some long-term users having significant leverage positions.

To mitigate this, we propose to optimize the ETH-correlated assets parameters on all markets, and we seek governance greenlight on a cap management policy by risk stewards.

Specification

WETH:

  • Slope 1 is optimized to 2.7% on all Aave instances, ensuring LST/wETH loops profitability

Caps & rate management policy:

  • Maintain a minimum 25 bps discount between stETH 30-day avg APR and Slope 1 wETH borrow cost with monthly AIPs to enforce this policy
  • Support research and development to create new InterestRateStrategy contracts for wETH implementing this policy algorithmically.
  • Keep wETH borrow cap increases ceiling at 90% of currently supplied wETH on all networks

Disclaimer:

The Aave Chan Initiative did not receive compensation for creating this proposal.

Next Steps

  1. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.
  2. If the Snapshot outcome is YAE, this proposal will be escalated to the AIP stage, and the cap management new policy will be considered canon.

Copyright:

Copyright and related rights waived under CC0

5 Likes

Hey. Good timing with this proposal, as I was just about to make a new post about this topic as well.The recent weETH snapshot vote suggested raising weETH caps to 1 Mil weETH. It’s currently at 450k weETH (ETH mainnet+ Arbitrum), but if @ChaosLabs increase the caps one more time, that would very likely push the ETH utilization above u-opt/kink and lead to chaos and essentially force out every ETH borrower other than current weETH airdrop farmers. I think this would be unfair to them, as they have been the main revenue generators for Aave for years now. Limiting the ETH borrow caps to 90% of the supplied ETH would mitigate this issue to a large extent (still susceptible to larger ETH withdrawals) and make sure those users aren’t punished. At the same time this would allow Aave to keep growing with users depositing weETH as collateral to borrow stablecoins and other tokens without punishing other long term ETH borrowers. Keeping the long term ETH borrowers on Aave instead of losing them to competitors would also be a healthy precaution against a sudden DAO revenue drop-off in case there would be a larger exit of weETH users after the end of the airdrops.

One question I have regarding the enforcement of the cap management: On other networks, for example Arbitrum, managing this shouldn’t be too hard as the caps are set very tightly and borrow caps are set to be at 90% ratios of the supplied assets currently already more or less. But on the Aave Ethereum mainnet market, the borrow caps are currently set far higher than 90% of the supplied ETH. Currently 778k ETH are supplied here while the borrow cap is set to 1.4 Mil ETH, so almost 200% ceiling compared to the current supply. Would risk stewards like ChaosLabs be able to “decrease” this amount on Aave Ethereum and set a lower borrow cap ceiling here in this case?

If that’s possible, I think this proposal is a very good solution overall.

2 Likes

The current proposal has been escalated to ARFC Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

Sorry for delay in my answer it was in draft for some reason

Hello @PDRML you’re pinpoint accurate in your analysis.

Unfortunately, that’s not an option for the current CapsPlusStewards (risk steward). That’s why several service providers are coordinating to update this old steward with more capabilities and will present a governance proposal shortly to request governance approval.

1 Like