Gauntlet Recommendation: CRV Deprecation Schedule

[Gauntlet]

Summary

Given that account 0x7a16ff8270133f063aab6c9977183d9e72835428 has been actively repaying its USDT debt since the Vyper hack, Gauntlet recommends a structured, scheduled approach to further lower CRV LT on v2 Ethereum and derisk v2 exposure to CRV. As a heads-up, @ChaosLabs is intending to repost the previously canceled AIP that plans to reduce CRV LT from 0.55 to 0.49. We are aligned with reposting this AIP.

Below, Gauntlet provides a structured approach for LT reductions moving forward. Our approach aims to

• Minimize a similar risky scenario as the one experienced in the days after the Vyper exploit.
• Provide visibility in the DAOs intentions and roadmap with respect to CRV on v2.

We present two schedules to the community with different levels of restrictiveness to proactively derisk the position.

Considerations

While liquidations are the critical component to reducing potentially unhealthy loans, they do increase sell pressure of the collateral and reduce the buffer towards liquidation, which may drive the possibilities for bad debt during times of low liquidity. We highlight the three main pillars for the safety of a position. Ideally, each pillar should strengthen against bad debt accrual for the next phase of LT reduction to commence.

Size - this is the potential severity of magnitude for bad debt.
Price - this is the buffer towards bad debt accruing.
Liquidity - this is the mitigating factor that can reduce bad debt, if the buffer is shrinking.

Schedules

To account for the tradeoffs described above, that occur with LT reductions, Schedule 1 requires more conditions surrounding the debt size, market price, and liquidity to be satisfied before commencing the next LT reduction, as compared to Schedule 2. As a result, Schedule 1 necessarily assumes stronger market conditions and safer user positioning before further derisking.

• In each schedule, we aim to put up AIP for next LT reduction on Wednesday, in order to be executed the following Monday, to avoid weekend changes.
• We aim to end the scheduled LT reductions when total borrows for the account drop below the maximal debt able to be borrowed against CRV on v3 Ethereum, which is the debt ceiling of $5m.

We refer the community to the below appendix for additional color on these schedules.

Schedule 1

Each week, put up AIP on Wednesday to reduce LT by 5% if the following conditions are met

• (size) amount of remaining debt has been cut by 10%
• (price) new HF is greater than 1.6 (historical maintained HF without derisk measures) + 17% buffer (representing a 3 standard deviation daily CRV price move)
• (liquidity) rolling averaged DEX liquidity (proxied by 2pct depth) > 90% DEX liquidity from previous week

Schedule 2

Each week, put up AIP on Wednesday to reduce LT by 5% if

• (price) new HF is greater than 1.6 (historical maintained HF without derisk measures) + 17% buffer (representing a 3 standard deviation daily CRV price move)

and one of the following conditions are met.

• (size) amount of remaining debt has been cut by 10%
• (liquidity) rolling + snapshotted DEX liquidity has stabilized > 90% average liquidity compared to previous week

For additional color, here are the necessary HF the account should have to commence the next phase of LT reduction, pertaining to both Schedule 1 and Schedule 2.

LT	LT_reduction	pct_buffer	min_maintain_HF	new_HF	HF_needed
0.49	0.06	0.17	1.6	1.93	2.16
0.44	0.05	0.17	1.6	1.93	2.15
0.39	0.05	0.17	1.6	1.93	2.17
0.34	0.05	0.17	1.6	1.93	2.21
0.29	0.05	0.17	1.6	1.93	2.26
0.24	0.05	0.17	1.6	1.93	2.33
0.19	0.05	0.17	1.6	1.93	2.44
0.14	0.05	0.17	1.6	1.93	2.62

Next steps

We welcome community feedback and aim to proceed to Snapshot on August 9th, 2023.

Appendix

Why do we recommend a buffer to the user’s HF after an LT reduction?

• We do not want to create excess risk resulting from LT reductions.
• Because HF = supply * LT / current borrow, the user’s new HF is new_HF = old_HF * (new_LT / old_LT).
  • Given that our targeted LT reduction is -5% each week, the user’s HF is more heavily impacted at each iteration of LT reduction.
  • We target constant LT reduction of -5% each week, rather than a proportional-based LT reduction, to focus on more quickly derisking the position.

This table shows that user HF is more heavily impacted each iteration of LT reduction.

LT	LT_reduction	HF	new_HF
0.49	0.06*	1.9	1.69
0.44	0.05	1.9	1.68
0.39	0.05	1.9	1.66
0.34	0.05	1.9	1.62
0.29	0.05	1.9	1.57
0.24	0.05	1.9	1.50
0.19	0.05	1.9	1.40
0.14	0.05	1.9	1.22

(*) This intended AIP will reduce CRV LT from 0.55 to 0.49

• We set the buffer to be 3 * the daily Garman Klass volatility for CRV to give sufficient room against liquidations.
  • The GK annualized volatility over the past month is ~105%, suggesting a daily volatility of ~5.5%.
• We identify the minimum HF threshold to be the minimum HF sustained by the position before intervention since November 2022, which is ~1.6.

HF trends, position activity since Nov 2022:

[0xkeyrock.eth]

Thanks for the recommendations @Gauntlet.

In our opinion, Schedule 1 could become unrealistic as it is at anyone’s guess if the user will pay off more debt or not. (apart from the OTC deal with the DAO if it passes).

Thus we are supportive of Schedule 2.

[EzR3aL]

+1, supporting schedule 2 as @0xkeyrock.eth already mentioned. Seems more realistic and we definitely need something moving here.

[ChaosLabs]

The effort to unwind the CRV market is complex and should be collaborative. We’ve been advocating for LT reductions for CRV for months (here, here, here) and have already started a series of CRV LT reductions:

1. [ARC] - Risk Parameter Updates for Aave v2 Ethereum - LTs and LTVs for Long Tail Assets (2022.12.04)
2. [ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.06.15
3. [ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.07.10

Additionally, there’s a dedicated thread to discuss this topic, which was shared with Gauntlet and additional community members hours before this post was published, which makes this even more bizarre.

Now let’s get technical. At worst, none of these conditions are met, and this plan affects no change. Adhering to a preset schedule could lead to a situation where if conditions are unmet, no changes are executed. Conversely, the LT reductions proposed could be overly conservative if we’ve set an upper bound that is no longer relevant. So far, we have every indication that the position holder is cooperative and willing to unwind the position, as over $30m debt was repaid last week, with significant CRV redeemed.

Per usual, we communicated our intentions, asking Gauntlet and other DAO contributors to collaborate. Our goal is to share a CRV wind-down plan that could culminate in community alignment, position holder collaboration and minimize community confusion.

Chaos has provided an alternative recommendation for a framework for future LT reductions, which can be found here. We appreciate the community feedback and discussion around this important topic. As suggested in this post, the community needs ample time to consider the alternative plans and advise not to rush to a Snapshot vote tomorrow.

[Gauntlet]

The above post outlines the efforts that the Gauntlet team has been conducting to derisk this position. We have made CRV LT reduction recs as far back as August 2022. The “Chaos Labs - CRV V2 Ethereum Deprecation Plan” has been heavily revised and originally did not include a collaboration schedule or technical assessment of the risk. As mentioned, we have aligned on the first LT recommendation with Chaos and will look to continue to do so.

While we aim to move swiftly, we are happy to delay the Snapshot to allow for more time for community discussion. We are all looking to do what is best for the DAO and look forward to jointly aligning on a path forward.

[ApuMallku]

Aho,
We agree with @ChaosLabs that having two separate proposals that aim the same thing at the same time is not the optimal way of exposing ideas to the community; it creates confusion, especially if these proposals come from two official service providers. Please try to align both of you off-chain, and then come back with a unified vision; the “CRV drama” is/was the most sensitive topic in CT for over six months. It is time to act as a team (service providers, the DAO, etc.), not to show whose vision is most “impactful” for the DAO.

Thanks both @Gauntlet @ChaosLabs

[MarcZeller]

the ACI is puzzled at @Gauntlet posting a proposal very similar of @ChaosLabs Chaos Labs - CRV V2 Ethereum Deprecation Plan

Precedence and good practice for this

:
1- @ChaosLabs should move their post this in Governance section. This is an ARFC.
2- if a second risk service provider has an alternative plan such as @Gauntlet, post it in the thread that has been published first as an alternative for consideration of the community.
3- during ARFC Snapshot stage, allow community to express their preference for a proposal compared to the others in this case something like this:

• YAE (chaos labs)
• YAE (Gauntlet schedule 1)
• YAE (Gauntlet schedule 2)
• NAY
• ABSTAIN

I would like to remind both teams that while competition is always healthy, both have their paychecks signed by this DAO. The DAO expects some form of cooperation between service providers at the benefit of the DAO.

At the ACI we heavily suggest both teams to sync up off-chain, an optimal outcome would be a proposal with several scenarios co-authored by both teams.

[ChaosLabs]

Reading this comment, one could think that Gauntlet has been proactive in derisking the CRV market over the past year. However, revisionist history doesn’t work when all the data is on-chain.

During our engagement with Aave, we haven’t observed any Gauntlet recommendations concerning LT reductions. However, after further investigation, we did identify 2 proposals from August 2022: (AIP-92 and AIP-94). These proposals saw the LT decrease from 65% to 61%.

These were also the LAST recommendations Gauntlet made for CRV LT reductions. At the time, there were already over 150M CRV tokens supplied to the protocol, amounting to over 15% of the total circulating supply, in a market with deteriorating liquidity and market cap.

The community would be better served if Gauntlet invested resources into collaborating on a solution that de-risks Aave versus boasting about the magnificent risk management practices displayed in August 2022. Markets are volatile, and there is an opportunity to fix previous negligence. This should be the focus instead of trying to push false narratives. As always, we’re eager to collaborate to ensure the DAO’s safety and secure growth.

[ChaosLabs]

To follow the ARFC process, we have moved our post to the Governance section.

[inkyamze]

Thanks for the reminder . We’ll move the convo over to the governance section, as requested. Can I ask that the diff on edits is viewable (example below)?

[Michigan_Blockchain]

If the user does not pay back more debt, it seems Schedule 2 would also not be met because new HF factor would decline with every LT reduction, not meeting the necessary HF>1.6+17% criteria.

If a smaller cut in LT would allow the HF condition to be met, could a smaller LT cut be proposed instead of the fixed 5%? @Gauntlet

We are also a bit confused why the HF_needed in table 1 column increases as LT decreases? It seems 1.6 + 17% would be relatively constant? And how exactly is the HF_needed calculated? 2.16 = 1.6+0.17*(???)

Lastly, why is the new_HF constant at 1.93 in table 1? Thought it would be declining like in the table in the Appendix.

[Gauntlet]

Thanks for your questions @Michigan_Blockchain.

@Michigan_Blockchain

If a smaller cut in LT would allow the HF condition to be met, could a smaller LT cut be proposed instead of the fixed 5%?

There are two ways of reducing LT:

• fixed 5% every week
  • less room for flexibility, but faster
• reducing LT by current_LT*0.1 every week
  • more room for flexibility, but slower

@Michigan_Blockchain

We are also a bit confused why the HF_needed in table 1 column increases as LT decreases? It seems 1.6 + 17% would be relatively constant? And how exactly is the HF_needed calculated? 2.16 = 1.6+0.17*(???)

• The buffer is for the price drop needed for the new HF, after the LT reduction, to attain this min_maintain_HF of 1.6.
  • For a new_HF of 1.93, it would take a 17% drop in CRV to attain a HF of 1.6.
  • 2.16 is the HF needed for the HF to be 1.93 after the LT reduction.

@Michigan_Blockchain

Lastly, why is the new_HF constant at 1.93 in table 1? Thought it would be declining like in the table in the Appendix.

• New_HF is constant because HF_needed is increasing. As LT goes down, 5% reduction has more impact each time.