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

Governance
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