Thanks for sharing these, @Pauljlei; we wanted to point out a few questions and concerns around both process and risk appetite. We’ll start with the process, highlight some of our work in this area and raise some technical concerns.
Contributor Collaboration
Since the attempted exploit of Aave using CRV, Chaos has been working with several contributors to align on the v3 launch strategy and parameters, as was mentioned in BGD’s update post earlier this week:
This work has been shared privately for initial review and feedback and was sent to Gauntlet privately earlier this week. We’ve been iterating on this from the ground up with the hope of aligning on methodology (Supply Cap, Borrow Cap) and strategy/parameters (posted here) to minimize confusion for DAO stakeholders.
Since being onboarded to the DAO, we have attempted to build a professional working relationship with all community members, including delegates, technical contributors, and anyone interested in our work. We had hoped that sharing our methodology and working with Gauntlet before posting would be good-faith actions in this manner. Unfortunately, this post surprised us as the community has pushed all contributors towards collaboration to protect the protocol better and facilitate more efficient decision-making. For the betterment of the DAO, its service providers must be aligned on work and priorities.
This was a key tenant in recent discussions around both Choas’ onboarding and Gauntlet’s renewal, most specifically this response two weeks ago:
With the bustling innovation within the Aave community and challenging macro environment, there is a requirement for a lot of risk coverage. With two risk managers, we can drive tremendous impact to Aave, enabling the community to move fast without compromising quality or economic security. However, this requires a willingness to collaborate, coordinate, and communicate. Without that collaboration, multiple isolated proposals confuse all active community members and directly oppose the recent promise of working collaboratively.
We will continue sharing our methodologies and results for feedback with Gauntlet and other contributors before public release. We hope this allows for more communication between our teams before engaging the community to ensure the highest level of service to the DAO.
Ethereum v3 Work & Questions
As mentioned above, we’ve been working on the topic with other Aave contributors over the past few weeks. We want to share our work and research, culminating in a different set of initial v3 Risk Parameters recommendations, which has been posted here. We welcome the community’s feedback on our methodology and strategies to align on the best path forward.
For ease of reading for community members, we’ll list the guiding priorities that we considered for our recommendations and would like to raise several questions so that we can better understand the Gauntlet proposal.
Guiding principles:
- Optimizing for GHO: Prioritizing High-Quality Collateral
- Risk-Off, Guarded Launch
- Methodology Transparency
Optimizing for GHO: Prioritizing High-Quality Collateral
The main driver and urgency for the v3 launch, as communicated by key community members such as Aave Companies and BGD, was:
- Migrating existing and new users to a safer, improved version of the Aave protocol, post the CRV attack and as market liquidity has dried up
- Unblock the anticipated GHO stablecoin launch. GHO will initially be launched on Ethereum, leveraging v3 to enable $GHO minting and burning
Accordingly, the initial listing of v3 parameters is paramount. It is a significant milestone for the Aave community but also lays the infrastructure for a strategically essential and impactful stablecoin expansion for Aave. As such, we have been working on a two-phased approach to launch:
- Phase 1: Launch v3 with a subset of markets focused on high-quality, widely used assets which can serve as reliable, safe collateral for the initial GHO launch
- Phase 2: As market conditions allow (with a focus on liquidity & volatility), and with the successful scaling of GHO-specific liquidity and market cap, begin incrementally adding more markets
Risk-Off, Guarded Launch
One of the main takeaways in the aftermath of the CRV attack is that risk parameters across v2 do not reflect the current deteriorated market conditions,as was highlighted in the conversation in reaction to the attempted exploit (snippet below, but further color in that thread)
Chaos Labs has initiated a set of AIPs to reduce LTs across v2 to better protect against future bad debt and begin transitioning to v3 with reduced capital efficiency. The community firmly understands how tedious and time-consuming this process will be, as the continued decrease in risk parameters (namely liquidation thresholds) will likely trigger user liquidations. Since the CRV attack, we have seen firsthand the implications of high-risk parameters having real consequences for the protocol that creates “risk debt.” This impact, if not accurate, cannot easily be reversed and can take weeks to months to correct.
Chaos Labs believes that a more conservative, risk-off, and guarded launch is the more prudent path forward. With more user data and market stability, we can iteratively loosen risk controls instead of the other way around. We understand that increased capital efficiency in v3 will be an excellent motivator to accelerate adoption and migration. However, that shouldn’t justify adding excessive risk exposure at launch.
The migration will need to be an iterative process over the coming months where the community can:
- Responsibly decrement v2 risk via parameter updates
- Consider freezing v2 markets as they launch on v3, shifting net new usage to v3 while not hurting user optionality or experience.
- Consider alternative methodologies such as rewards programs to incentivize capital migration.
We can always increase LTs, LTVs, and other risk parameters as the market deems fit, but we recommend a more conservative launch in the current environment.
Methodology Transparency
The computed numbers between both proposals are encouraging. We’ve publicly posted our borrow and supply cap methodology - and shared it previously via other channels. Is Gauntlet willing to share more insights into calculating these numbers and how your methodology differs?
Generally speaking, we hope the community can converge on a single guideline to inform these processes. As the protocol scales and expands to new ecosystems and markets, we can have clear procedures that create a standard for projects as they look to understand what levers underly parameter decision-making. They can work towards building a stronger case for increased Aave usage & higher caps. We’re happy to collaborate on that as it will benefit the greater Aave community.
Specific metrics
An average of LTs of Ethereum V2 and Avalanche V3 by their current supply is leaning heavily towards V2 values, which are too high. For a bit of context, the v2 market size is ~4.5 Billion USD, while the Avalanche V3 deployment is ~425M USD. So v2’s weight is 10x more significant here and skews all the recommendations towards the v2 values, which, as discussed in previous threads, is quite risky with current market conditions. Moreover, if set too high, reducing the LTs at a later stage is problematic as it triggers users’ liquidations.
While reviewing the inclusion of stETH as a borrowable asset, we ran into concerns of liquidity concentration entirely on Curve. We are continuing to run more analyses to stress test the sensitivity. Still, we would appreciate more color on how you came to the conclusion of activating borrows and a $500m+ borrow cap.
Thank you, we look forward to getting your feedback and iterating on these parameters for a swift launch of v3 on Ethereum.