[ARFC] Gauntlet E-Mode Methodology: Aave V3 Liquid Staking Tokens

Governance
1

Simple Summary

On Aave V3, E-mode requires multiple considerations, including mitigating tail risks to protocols, optimizing user experience, and allowing on-chain liquidity to remain robust. E-mode, in particular, unlocks capital efficiency with specific risk tradeoffs that we will discuss below. Here we describe the main factors we consider in calculating E-mode recommendations.

This is an extension and follow-up to our initial E-mode methodology post.

Conditions for Inclusion

Our conditions aim to quantify the following risks:

  • LST-to-Base asset liquidity (and liquidity changes under duress)
  • Protocol-specific risks (e.g., withdraw queue considerations)
  • LST-to-Base asset short-term and long-term correlation (and correlation changes under duress)
  • Arbitraguer profitability calculations

Given the LST E-mode pool LT (Liquidation Threshold) and pool LB (Liquidation Bonus), a potential candidate X should satisfy the following conditions.

  • Divergences between the market rate and smart contract conversion rate of LST / BASE must be upper-bounded by 1 - LT.
    • For Ethereum, we consider divergences in the spread between market rate and smart contract conversion rate.
  • Have a buffer between historically realized divergences with potential future divergences.
  • Have 30-day historical pairwise liquidity condition, which is as follows:
    • Take 10% of the supply cap of the smaller/less liquid asset
    • Ensure that slippage of the trading volume above will result in less than the LB (Liquidation Bonus) of the pool.

Supply Cap Summary
We consider the following factors to compute hypothetical “e-mode only supply caps.” The supply cap should consider liquidity in both abnormal dislocations and normal price variance.

  • (abnormal) maximum amount able to be liquidated within a 1-LT drop over a time range if the current liquidity is halved, with no additional liquidity inflow
  • (normal) 20x corresponding to a 1% price drop, bounded by 50% of the onchain circulating supply.

Gauntlet is exploring the relationship between insolvencies in LST-BASE dislocation events and increased revenue from higher capital efficiency. Because of this, we design our conservative caps to be 90% abnormal cap + 10% normal cap and our aggressive caps to be 50% abnormal cap + 50% normal cap.

We discuss in greater detail in our Methodology section.

chain asset abnormal normal conservative aggressive LT LTV LB Optional Buffer
ethereum WSTETH 191000 101000 373900 1105500 93 90 2 2
ethereum CBETH 6000 4500 14400 48000 93 90 2 2
ethereum RETH 10900 5000 19810 55450 93 90 2 2
arbitrum WSTETH 3300 1900 4620 9900 91 88 2 2
optimism WSTETH 2800 1600 4020 8900 91 88 2 2
polygon STMATIC 8500000 6000000 10150000 16750000 95 92.5 1 2
polygon MATICX 2000000 1400000 3600000 10000000 95 92.5 1 2
avalanche SAVAX 200000 135000 450000 1450000 93 90 1 2

Parameter Commentary
Our buffer represents a potential guard against max historical dislocation to account for unknown future dislocations. If the community wishes to implement this guard, the LT/LTV would be reduced by the buffer.
These supply caps theoretically are emode specific and do not cover non emode use cases. The two use cases have inherently different risks, which is why Gauntlet recommends considering emode specific caps to fully capture the increased capital efficiency of emode while maintaining appropriate levels of risk. One potential way to enable this increased capital efficiency would be to set LTV and LT for an LST at 0 in the standard reserve and have aggressive parameters in emode. We do not strongly recommend this approach at this time, but we wanted to start a conversation about this possibility.

LST pools are, in a sense, simpler than stablecoin pools since the main use case is to collateralize the LST and borrow the BASE. If the LST pool were analogous to stablecoin pools, we would only have LST and not the BASE in the pool. As such, we focus the analysis on LST-ETH positions. We will comment on LST collateralizing LST positions afterwards. Gauntlet’s recommendations assume the Shanghai upgrade occurs without abnormal, unforeseen events, based on our analysis here. In the event tail events occur, we will revise accordingly.

Borrow Cap Summary

We recommend using the borrow cap methodology outlined here. We will revisit this methodology after the Shanghai upgrade. We will also revisit this methodology if there are changes in market demand and token utility changes.

Methodology

The primary mechanism that ties an LST to its base asset (BASE) is its creation/redemption mechanism. Any abnormal dislocation between market price and redemption price will be arbitraged away if there is confidence in the redemption mechanism. (If LST trades under par, then traders can buy LST on market to redeem, vice versa, if LST trades over par, then traders can buy BASE to create the LST to market sell). Should there be doubts over the viability of the creation/redemption mechanism, then LST liquidity will dry up and begin to trade at a more significant discount.

Therefore, an LST should have a well defined, functioning redemption schedule or structure into BASE. For LSTs where the redemption mechanism is not live yet (such as WSTETH pre Shanghai upgrade), the redemption mechanism, if differing from overall unstaking, must be explicitly detailed. Most importantly, the LST should not have the ability to artificially burn or mint new LST without associated BASE (smart contract based manipulation).

Consider the spread between the smart contract exchange rate and market rate for an LST with a functional redemption system vs. an LST with a non live redemption mechanism.

STMATIC

CBETH

WSTETH

The market accounts for the tail probability of CBETH not being redeemable by trading at such a heavy discount to its exchange rate.

Supply caps methodology

stETH pool size on Curve, stETH price

Recall our conditions from above - The supply cap should consider liquidity in both abnormal dislocations and normal price variance.

  • (abnormal) maximum amount able to be liquidated within a 1-LT drop over a time range if the current liquidity is halved, with no additional liquidity inflow
  • (normal) 20x corresponding to a 1% price drop, bounded by 50% of the onchain circulating supply.

Our supply cap is primarily motivated from analyzing the relationship between liquidity and prices for LSTs. Our abnormal caps consider these relationships during abnormal price dislocations and high volatility; our normal caps consider them in normal price variance.

In sudden, abnormal dislocations, liquidity can dry to roughly 1/3 to 1/2 of the original liquidity, before extreme drops. Consider stETH during May 2022, in particular the “icepick” price dislocation on May 13. We’ve seen that these dislocations occur over the course of a couple hours, in which neither liquidity does not recover over the timeframe. This is also supported by the loss in 3pool liquidity during the USDC depeg events in March 2023. Again, these dislocations occur if there is loss of belief in the redemption mechanism, and are unlikely to manifest themselves in normal trading, given the arbitrage opportunities.

stETH - ETH liquidity on Curve and price, May 2022

stETH - ETH liquidity on Curveand price, June 2022

We compute our abnormal caps by

  • proxying a stableswap pool that is composed of half global liquidity for this LST - BASE pair
  • simulating successive market swaps that correspond to incremental price changes ~ 0.3%, until the LST simulated price has dropped by 1- LT

Our normal caps rely on the health of the arbitrage presented by belief in the functional redemption mechanism, which drives the quick reversion back to the smart contract exchange rate. Sufficient liquidity exists in these conditions to suggest a normal cap of 20x a 1% drop swap amount.

Application notes and Assumptions

The lower bound for the LTV and LT of assets in any E-mode category should be the asset’s LTV and LT outside of E-mode.

Gauntlet suggests launching a unique E-mode pool for each LST-base asset pair in the future to maximize capital efficiency through optimized supply caps, borrow caps, and other risk parameterizations.

The current implementation of LST E-modes would contain multiple LST assets in the same pool. This could lead to an LST collateral and LST borrow scenario within an E-mode pool. Although the current borrow caps for these assets provide a buffer for price deviations between these LST assets, this could pose a risk to the system in the future. These low borrow caps have not been fully utilized, suggesting that users are not putting on this positions with high frequency, though this may change in the future.

Additional Risks

We do want to be transparent that this approach necessarily assumes price correlations among the assets. When we are simulating depegging events for one asset, we assume price correlations still hold in the normal condition for the rest of the assets, which may not be valid under some extreme market conditions. For example, there could be a smart contract issue breaking the peg for multiple assets at the same time. In these scenarios, the protocol may face outsized risk that cannot be easily protected by risk parameters prior to the event occurring.

Recommendation Options

While we explore many options and potential community preferences above, we aim to move forward with actionable next steps. Below are several options which we will start a Snapshot vote for.

Poll 1: Emode and Borrow/Supply Cap settings

  • Option 1: (Gauntlet conservative) - Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above. This is our current recommendation
  • Option 2: (Gauntlet aggressive) - Include all LST-BASE assets in the same pool with aggressive risk preference outlined in table above.
  • Option 3: (Gauntlet conservative, confined assets) - Include a single LST-BASE pair pools with conservative risk preference outlined in table above. This is not possible with the current pool configurator.
  • Option 4: (Gauntlet aggressive, confined assets) - Include a single LST-BASE pair pools with aggressive risk preference outlined in table above. This is Gauntlet’s second preference This is not possible with the current pool configurator.
  • Option 5: (Gauntlet conservative, emode only) - Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also no borrowing power outside of emode (LT/LTV zero outside of emode).
  • Option 6: (Gauntlet aggressive, emode only) - Include all LST-BASE assets in the same pool with aggressive risk preference outlined in table above and also no borrowing power outside of emode (LT/LTV zero outside of emode).
  • Option 7: Remove LST emode settings Not recommended, we are adding for completeness

We note the tradeoffs below to help inform a community decision:

  • Options 1/2 likely has less user experience impact than the other options
  • Options 5/6 has potentially less use case than Options 1/2, because in Options 5/6, those assets do not have borrowing power outside of e-mode
  • Options 5/6 is potentially more straightforward from a risk perspective than Options 1/2 because the risks of the assets in non-emode are inherently different from the risks when they are used in e-mode
  • Options 3/4 is potentially more straightforward than Options 1/2 from a risk perspective because each e-mode pool only contains 1 LST and the base token (which better isolates the risk of each respective LST)
    • Practically, the implementation of Options 3 and 4 may be to freeze the current pools, and this would dictate how new e-mode pools are opened.
    • This requires changes to the pool configurator code.

We will follow up with more data (e.g., liquidations) but would value community feedback in the meantime.

Poll 2: Optional LT Buffer

  • Option 1: Include a buffer between the max depeg value and LT e-mode parameter
  • Option 2: Do not include a buffer between the max depeg value and LT e-mode parameter This is our current recommendation

Next Steps:

  • Welcome feedback and questions from the community.
  • Move to Snapshot vote with recommendations Options.
  • Of course, we will wait until after the Shanghai upgrade to publish the AIP related to this proposal.
5 Likes
2

Thanks Paul

Our current preference is:

Similar to the behaviour of LST holders where they allocate their capital according to their risk preference of a particular LST, given each LST carries different risks, yield, decentralization, liquidity, etc. I think it makes sense for Aave to be able to make the same decision for individual LST risk parameters in e-mode.

Having this functionality will also allow Aave to onboard newer LSTs to e-mode with isolated risk and allow for more capital-efficient risk parameters across individual LSTs.

2 Likes
3

Thanks for the post @Pauljlei and company.

I enjoyed how you outline the benefits and tradeoffs of each potential option:

This better informs users and lets them compare one to another. We’re supportive of seeing more language like this in risk discussions.

Our preference is to maximize UX and revenue opportunities. For this reason, we support Option 2.

We also note the value in confined assets, isolating the risk of each LST. Option 4, as outlined by @WintermuteGovernance, seems palatable as well.

This route may however cause some disruption on current borrowers.

2 Likes
4

Thanks Gauntlet (@Pauljlei) for the thoughtful analysis on a quite important aspect of Aave v3 like it is e-mode, being one of the current growth engines.

Given that some of the proposed options touch on potential technical improvements to the protocol and important design decisions of it, we would like to comment on the following points:

  • First and most important, Aave is a multi-collateral and multi-borrowing protocol in nature. Even if features like e-mode, isolated collateral or siloed borrowing factually create “sub-groups” of assets within a pool, creating deeper isolation by having multiple pools with the same assets but different risk configurations should be out of the picture, as it goes really against design decisions of the protocol and its unique selling proposition. We are firmly against any option of creating single LST-BASE pair pools, like Option 3 and 4.
  • Even if not possible at the moment, it is technically possible to include supply/borrow caps exclusive to a specific e-mode, different from the caps of the same assets in non-e-mode. From BGD, we are glad to implement this.
  • Currently, one limitation of the protocol is that 1 asset can only belong to 1 e-mode. This is problematic, especially because we agree that could be important too, for example, to have an e-mode for WETH and wstETH, together with a different e-mode for let’s say WETH, cbETH, and rETH.
    Similar to the previous point, even being a current limitation, this can be implemented, and we are glad to do it.
1 Like
5

Thanks for the response and insight @bgdlabs. We appreciate the feedback about Options 3 and 4. We wanted to provide a potential solution for increasing capital efficiency, but we understand your position.

In response to your feedback, we would like to provide these two additional options:

  • Option 8: (Gauntlet conservative, emode specific caps): Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also have lower LT/LTV outside of emode (current standard LT/LTV), with separate supply and borrow caps (These will be initialized as 100% abnormal criteria, so slightly less than the conservative values, and 70% of the total calculated cap will go to emode caps).

  • Option 9: (Gauntlet aggressive, emode specific caps): Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also have lower LT/LTV outside of emode (current standard LT/LTV), with separate supply and borrow caps (These will be initialized as 60% abnormal criteria, so slightly less than the aggressive values, and 70% of the total calculated cap will go to emode caps).

Please let us know any additional feedback and questions you may have.

3 Likes
6

Following the discussion on LSD price feeds and redeemability, we published the Chaos Labs LSD Methodology Update, which we will consider in future E-Mode and risk parameter recommendations.

In response to @bgdlabs comments above, we endorse the following two proposed enhancements:

  1. Establish separate supply caps for E-Mode.
  2. Allow an asset to be part of multiple E-Mode categories.

These improvements are expected to increase utilization and risk controls for LSDs significantly.

In the short term and for the purpose of the upcoming vote, we support the current configuration of the emode categories across all networks and support the following:

  1. Creating an ETH-correlated E-Mode on Optimism
  2. Adding rETH to the E-Mode on Ethereum.
  3. We do not recommend any immediate changes to the supply caps of the assets, as can be seen in our methodology post
  4. For stMATIC and MaticX, if the community decides on a higher risk appetite regarding counter-party risk, we will recommend increasing the supply caps according to the outcome of the snapshot vote.
7

LST E-Mode Next Steps

Thanks all for the feedback on this community initiative.

Next Steps:

  • Publish 2 Snapshot votes (described below) on 5/3/2023, with ample time for voting.
    • Poll 1 is Emode and Borrow/Supply Cap settings
    • Poll 2 is Optional LT Buffer

Poll 1: Emode and Borrow/Supply Cap settings

  • Option 1: CONSERVATIVE - Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above.
  • Option 2: AGGRESSIVE - Include all LST-BASE assets in the same pool with aggressive risk preference outlined in table above.
  • Option 2A: AGGRESSIVE, MODIFIED - Include all LST-BASE assets in the same pool with aggressive risk preference outlined in table above, however, do not change supply caps at this time.
  • Option 3: CONSERVATIVE, CONFINED ASSETS - Include a single LST-BASE pair pools with conservative risk preference outlined in table above. This is not possible with the current pool configurator.
  • Option 4: AGGRESSIVE, CONFINED ASSETS - Include a single LST-BASE pair pools with aggressive risk preference outlined in table above. This is not possible with the current pool configurator.
  • Option 5: CONSERVATIVE, EMODE ONLY - Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also no borrowing power outside of emode (LT/LTV zero outside of emode).
  • Option 6: AGGRESSIVE, EMODE ONLY - Include all LST-BASE assets in the same pool with aggressive risk preference outlined in table above and also no borrowing power outside of emode (LT/LTV zero outside of emode).
  • Option 7: REMOVE LST EMODE SETTINGS. Not recommended, we are adding for completeness
  • Option 8: CONSERVATIVE, EMODE SPECIFIC CAPS: Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also have lower LT/LTV outside of emode (current standard LT/LTV), with separate supply and borrow caps (These will be initialized as 100% abnormal criteria, so slightly less than the conservative values, and 70% of the total calculated cap will go to emode caps).
  • Option 9: AGGRESSIVE, EMODE SPECIFIC CAPS: Include all LST-BASE assets in the same pool with conservative risk preference outlined in table above and also have lower LT/LTV outside of emode (current standard LT/LTV), with separate supply and borrow caps (These will be initialized as 60% abnormal criteria, so slightly less than the aggressive values, and 70% of the total calculated cap will go to emode caps).

For Option 2A - Gauntlet’s analysis shows that given key market mechanism changes post Shanghai upgrade, now is a prudent time to unlock capital efficiency around LSTs, but we add this option to the Snapshot for completeness.

We note the tradeoffs below to help inform a community decision:

Tradeoffs:

  • Described above, an Aggressive preference weighs “abnormal” dislocations less than normal price. variance, relative to the Conservative preference.
  • Options 8/9 potentially provide more granular controls for risk and capital efficiency than all other options.
  • Options 1/2 likely has less user experience impact than Options 5/6.
  • Options 5/6 has less use case than Options 1/2, because in Options 5/6, those assets do not have borrowing power outside of e-mode.
  • Options 5/6 may be more straightforward from a risk perspective than Options 1/2 because the risks of the assets in non-emode are inherently different from the risks when they are used in e-mode.
  • Options 3/4 is not possible under the current pool configurator code, and potentially antithetical to the design of the protocol as noted in the feedback above.
  • Option 7 is not recommended if the community wishes to enable greater capital effficiency on LSTs.

A few other notes:

  • On creating an ETH-correlated E-Mode on Optimism - we are interested in exploring this, but to avoid bundling too many actions into a vote, will not include it in this Snapshot vote.
  • We currently support adding rETH to the E-Mode on Ethereum, but again to avoid bundling, will not include it in this Snapshot vote.

Poll 2: Optional LT Buffer

  • Option 1: Include a buffer between the max depeg value and LT e-mode parameter
  • Option 2: Do not include a buffer between the max depeg value and LT e-mode parameter This is our current recommendation
1 Like
8

We appreciate the ongoing discussions around the upcoming vote and the options presented. We would like to emphasize a few points that are important for an effective governance process and informed decision-making:

  1. We believe that the real value in this proposal and community discussion is related to the mechanism and definition of the E-Modes. Therefore, we recommend limiting the options in the upcoming Snapshot to focus on the following questions, without specific supply cap recommendations:

    a. Should we implement separate caps for E-Mode?
    b. Should we have single LSD-BASE pools or include all LSDS in the same pool?
    c. Should there be no borrowing outside of e-mode?

  2. We recommend not incorporating supply cap updates in this proposal. Instead, we propose addressing cap updates on a more granular, asset-by-asset basis, considering individual factors such as Oracle calculation, redeemability mechanisms, asset utilization and more. Examples for these can be found in current governance proposals such as MaticX, stMATIC and Chaos Labs Supply and Borrow Cap Updates.

    • Additionally, if the community opts for options requiring protocol developments, the presented caps will anyways need to be updated to reflect the market conditions at the time of completion.

  3. We have some concerns regarding Gauntlet’s recommended caps:

    a. The “Aggressive” option effectively freezes stMATIC, MaticX, and sAVAX. According to our methodology and recommendations, we do not think this is neccesary. Furthermore, for wstETH and rETH on Ethereum, the current caps are sufficient to handle new supply. Gradual increases while tracking utilization seem to be a better option, as is the current process.

    b. The “Conservative” option effectively freezes all future supply for all assets on the list except wstETH and rETH on Ethereum, which will impede the growth of the protocol. @Pauljlei could you please explain why this is Gauntlet’s current recommendation?

this is contrary to the comment here:

To summarize, we stand firm with our previous comments and recommendations.

10

Next Steps

We appreciate the community’s interest and feedback on Gauntlet’s methodology for LST Emode. We hope that the analysis above helps organize and systemize the discussion around managing risk for LST Emode - on factors such as short-term and long-term correlation, arbitraguer profitability, abnormal vs. normal price variances, and how to implicitly model risks on the redemption mechanism.

The discussion has brought forward important design decisions for the community. To simplify the governance process, our Snapshot vote will include the below options, which are essentially our original Options but without a CONSERVATIVE and AGGRESSIVE delineation:

  • Option 1: Include all LST-BASE assets in the same pool
  • Option 2: Include single LST-BASE pools
  • Option 3: Add Emode-specific caps
  • Option 4: NO - do not add Emode-specific caps
  • Option 5: YES borrowing power outside Emode
  • Option 6: NO borrowing power outside Emode
  • Option 7: Remove LST Emode

The Snapshot will be “multi-select” (voters can select multiple options), as it may be possible for voters to want to select Option 1 and Option 3, as they are not mutually exclusive.

As mentioned above, we target a Snapshot vote on Wednesday, 5/3/2023.

2 Likes
11

Snapshot vote is below:

https://snapshot.org/#/aave.eth/proposal/0x66cba3dba93a22df655346a59453c9d041ebaabc59c64353e6955948db0a9113

12

Hello, friends. As said before, Keep it simple.

The ACI has no interest in participating in 7 options votes. if as “professional delegates/service providers” we can take the time to refine a proposal and reach a consensus on a forum, these kinds of votes are simply unreadable to the larger community.

We’re voting NAY on this, we expect more community consensus in this thread and another snapshot vote trimmed out of options considered unfit via feedback here.

Nay
Nay782Ă—884 390 KB

1 Like
13

We provided multiple options in order to be comprehensive and collaborative, because in the past we received pushback for not adding enough options. But, we understand the need to simplify the discussion.

One important topic above is whether the protocol should add E-mode specific caps:

What this means is that, for example, Asset X may have a Supply Cap of 10,000 in non-emode, and a separate Supply Cap of 6,000 in E-mode (for example, ETH correlated E-mode). The reason for this is that the risk profile of Asset X in non-E-mode is different than that of its risk profile in E-mode (the LTs are different, the asset correlations are different, etc), so by separating caps between E-mode and non-E-mode, we are able to more granularly tune risk parameters, with more precision to capital efficiency.

We have published the vote below, with only 2 options. Voting begins next week - we appreciate the community’s participation.

https://snapshot.org/#/aave.eth/proposal/0x602046cab7a8a9abc178fbe2c4e869c55bcea35567235e3174e0409e9c39db7b

1 Like
14

Hi guys -

This is a meaty thread. I will mirror @MarcZeller’s urge to keep it simple.

While trying to discern the best option for Aave, delegates are getting lost or would rather not bother.
I’ll remind that many of the community are neither risk experts nor understand the differences.

Let’s try to make it an easier discussion for more folks to get involved.

With the updated two options, how will it impact the borrower experience?

2 Likes
15

Thanks for the feedback @fig. The goal is to improve user experience by setting more specific caps that balance capital efficiency needs more effectively. This means that if we analyze the total borrows and total supplies of users who supply stMATIC and MaticX to Aave V3 Polygon, we can observe that many suppliers of MaticX and stMATIC (not using e-mode) are less aggressive in borrowing compared to users in the Matic Correlated E-mode. By allowing the adjustment of borrow and supply cap parameters, as well as future parameter growth, we can promote maximum growth with the protocol. In summary, fine-tuning caps and adjusting parameters can enhance load-balancing and promote the protocol’s growth.

image

2 Likes