[ARFC] Increase Supply Caps for LSTs on AAVE V3

Governance
1

Proposal updated to include @ChaosLabs feedback

title: [ARFC] Increase Supply Caps for LSTs on AAVE V3
author: @marczeller - Aave Chan Initiative
created: 2023-05-29

Summary

This ARFC proposes a increase in the supply caps for several Liquid Staking Tokens (LSTs) across multiple networks, including stETH, rETH, and sAVAX. The proposed changes are within the limits of the Risk Stewards and are requested for enforcement by them.

Abstract

The supply caps for several LSTs have reached or are nearing their current limits. To ensure the continued smooth operation of the protocol and to accommodate growing demand, this ARFC proposes to increase these caps. The proposed increases range from 50% to 100%, depending on the asset and network.

Motivation

The motivation behind these changes is to accommodate the growing demand for these LSTs in the Aave protocol. By increasing the supply caps, we can ensure that the protocol can continue to serve its users effectively. Furthermore, LSTs in L2 pools are essential for users who can’t afford the transaction fees on L1. DeFi should be inclusive and is meant for everyone, and L2s are important to reach this goal.

Specification

The proposed changes are as follows:

Asset Network Current Cap Current Supplied Liquidity Utilization Proposed Cap Increase New Cap New Utilization
stETH Ethereum L1 200.00K 200.00K 100% 50% 300.00K 67%
rETH Ethereum L1 20K 20K 100% 100% 40K 50%
stETH Arbitrum 9.30K 9.30K 100% 61% 15K 62%
stETH Optimism 12K 12K 100% 100% 18K 67%
stETH Polygon 2.4K 2.4K 100% 68% 4.05K 60%
sAVAX Avalanche 2M 1.77M 88% 50% 3M 60%

We request the Risk Stewards to enforce these changes. This proposal is compliant with the Aave V3 Caps Update Framework, and since the AIP-234 vote, the Risk Council via the Risk Steward can enforce this framework.

Next Steps

Collect feedback from the community & Risk service providers. If the feedback is positive, the Risk Stewards will enforce the proposed changes. We encourage all Aave users to participate in this discussion and provide their feedback.

Disclaimer

The Aave Chan Initiative (ACI) is not associated with or compensated by Lido, Rocket Pool, Avalanche, BenQI, or any other third party for publishing this ARFC.

Copyright

Copyright and related rights waived via CC0.

note: please consider that StETH & rETH L1 update and StETH OP update reflect @Llamaxyz work on it and already reached consensus, it has been cited here for easier understanding of upcoming supply caps changes.

2 Likes
2

This proposal is necessary for Aave to continue leveraging the demand for LSTs to create value for its users and the protocol in general.

3

Thanks for putting this forward @MarcZeller.

  1. For wstETH and rETH on Ethereum and wstETH on Optimism, we support the updates above, as we recommended here and here

  2. For wstETH on Polygon and Arbitrum, we’ve provided our analysis here and recommend a more modest increase:

Network Asset Current Supply Cap Recommendation
Arbitrum wstETH 9,300 15,000
Polygon wstETH 2,400 4,050
  1. For sAVAX, following our analyses here, we support increasing the supply cap to 3M.
    The updated data regarding on-chain liquidity and the composition of position (e-mode vs non e-mode) can be found below:

349219332_164952413003507_4238894627219339487_n

Untitled - 2023-05-29T145216.451

1 Like
4

thanks @ChaosLabs for your feedback, we updated the proposal to include it,

5

We’ve prepared the payloads to be executed via the Risk Steward process for this proposal.
Upon receiving approval from @Gauntlet for the above recommendations, we will be able to move forward to implement these updates.

3 Likes
6

Per the current implementation of LST pricing and our existing LST supply cap methodology, Gauntlet supports the cap increases for

  • wstETH on Ethereum (300k), Arbitrum (15k), and Optimism (18k)
  • rETH on Ethereum (40k)

Regarding wstETH on Polygon and sAVAX on Avalanche -

  • Raising the cap to 4000 will be premature. 4000 supply cap of wstETH is 75% of the supply cap. To reiterate, our LST supply cap thresholds supply caps to 50% of the circulating supply. wstETH pricing must first move to the synchronized price adapter solution, and the community align on potential “killswitches” in the event of wstETH depeg, for this cap increase to not add excess market risk.

    • We support a more modest increase in supply cap to 2700.

  • sAVAX must first move to the synchronized price adapter solution. As a result, our methodology supports a more modest increase to 2.2m. Again, sAVAX must move to the synchronized price adapter solution and the community align on potential “killswitches” in the event of sAVAX depeg, for this cap increase to not add excess market risk.

1 Like
7

We thanks Gauntlet for their Reply,

We invite the Risk council to execute payloads that reached consensus from both risk service providers

wsETH on polygon will revert to next governance process via an AIP vote. or be implemented via steward with supply cap to 2700 as it’s the common denominator between risk providers

sAVAX is postponed for oracle upgrade and killswitch decision.

1 Like
8

@Gauntlet @ChaosLabs

9

Great to see the Risk Steward process in action! I’m a big fan of the extra speed and efficiency this brings.

I’m curious about the best way to follow the executions of the payloads:

  • Is there a Risk Council multisig we can monitor to see the pending signatures and queued transactions in real-time?

  • Should we be monitoring the respective CapsPlusRiskStewards contracts?

I’m asking these questions because I believe in the importance of transparency and the ability for all community members to monitor the actions of the Risk Council. Having real-time visibility not only increases trust, but also promotes active involvement in the Aave community. Particularly in this case, I believe this information could be of great interest to fellow governance and LST enthusiasts (enjoyoooors) who are eagerly waiting to deposit more collateral.

UPDATE: After a little digging I found that the relevant Gnosis Safes can be found by reading the RISK_COUNCIL function on the respective CapsPlusRiskStewards contracts (which are listed here).

Example for Optimism: Risk Council Gnosis Safe tx Queue

The transaction has been queued but still requires a second confirmation before it can be executed. Prior to execution, someone will also need to top up these accounts with some ETH since nonce of the signers have funds to pay for gas on Optimism.

10

The following updates were executed via the Risk Steward process:

Asset Network Old Cap New Cap
stETH Ethereum L1 200.00K 300.00K
rETH Ethereum L1 20K 40K
stETH Arbitrum 9.30K 15K
stETH Optimism 12K 18K
11

You can also find the addresses here: aave-address-book/src at main · bgd-labs/aave-address-book · GitHub if you don’t want to dig trough proposals.

For cases like on wstETH on polygon were risk providers opinions on the cap diverge I think it would be reasonable to implement the more conservative suggestion instead of waiting for an aip.

Also it’s important to note that on arbitrum the dynamics are now a bit scewed as weth borrow cap on arbitrum is 100% utilized at a 3.5% apy.

image
image2132Ă—355 31.1 KB

1 Like
12

Is there a panel that can openly and transparently display the progress of these cap updates ？
In particular these updates are not shown in the polling area.

13

You can monitor execution here:
mainnet: Safe{Wallet} – Transaction queue
polygon: Safe{Wallet} – Transaction queue
avalanche: Safe{Wallet} – Transaction queue
arbitrum: Safe{Wallet} – Transaction queue
optimism: Safe{Wallet} – Transaction queue
metis: 0x0f547846920C34E70FBE4F3d87E46452a3FeAFfa

1 Like
14

Following up on this proposal, as there is consensus on increasing the supply cap for sAVAX, We’ve prepared the payload to increase the supply cap from 2M to 2.2M, to be executed via the Risk Steward process.

15

The update to sAVAX on Avalanche has been executed via Risk Steward.

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.