Thank you all for all the feedback and your candor - we’re genuinely appreciative of all of this to continue to evolve our service offering.
Thanks for the feedback here. It’s worth clarifying that our payment is essentially a fixed price payment given that it’s calculated and paid at the start of the engagement - it doesn’t change throughout. More broadly, we like using a formula based on the two aspects that our work supports (total borrow, active assets) because it allows us to be aligned with the DAO e.g. our payment will now be at least $300k lower given the reduced amount of active v2 assets in the past few weeks.
Completely agree and we’re working on a few things to assist with this. Very open to ideas on what else we can do here.
- First and foremost, to your point, providing a lot more detail (e.g., underlying assumptions, statistics, tradeoffs) on future parameter recommendations to help the community better understand our work and make decisions.
- Secondly, we’re launching an updated dashboard in Q1 that provides more visibility into the data that informs our recommendations including liquidation mechanics, asset listing/delisting, liquidity and slippage, interest rate curves, and depeg risk.
- Lastly, we’re creating more content to explain our methodology, share monthly updates, and talk through key risks via Twitter Spaces AMAs.
For the security budget specifically, this was not initially publicly decided because it would reveal to an attacker how much capital to accumulate. We initially proposed a security budget of $100M based on the safety module size - it was the max slashing value of the safety module (30% of $300M) and hence was theoretically ‘what Aave could pay for’ from what has been dedicated as a fund for insolvencies/coverage. We presented our methodology and confirmed this assumption with various stakeholders.
To your broader point about making decisions publicly, we agree. We need to find better ways to assess the community’s risk appetite - well ahead of market risk situations. Some initial ideas that can start to move the needle here are collaborating with the community and other service providers to create and continuously update a public-facing risk management framework for Aave in order to track community sentiment around risk/reward tradeoffs. We are happy to actively collaborate with a risk council to increase alignment and create a faster response path. Happy to hear additional ideas on this one as well.
You’re absolutely right here - this was due to resource constraints and poor expectation setting. We didn’t specify which markets we would support in our last proposal. For some context, we launched Aave Arc ahead of these two markets based on feedback from Aave Companies. We’re now a team of 50 and starting to make headway on this - we launched v3 Avax in October and are ready to launch v3 Optimism this month. Our simulations currently cover 90% of Aave’s TVL. The full roadmap is here, which we’ve included in the proposal this time around.
Thank you for all the feedback on this one. A few ways we are working on improving here:
- Overhauling our incident response process, which includes internal and external alerting, escalation, and investigation processes. This updated process will provide the community with much more clarity on how market conditions and risk for Aave is evolving and will cover key market risks such as external (e.g., DEX) liquidity changes, asset price volatility, reserve utilization, and whale liquidations. Development in in progress and is supported by a dedicated Gauntlet analytics team for Aave. We look forward to working with the community to align on key aspects related to how alerts are communicated and escalated given the sensitivity of these events.
- Formalizing a v2 asset delisting process to avoid future market risks and streamline governance decisions. It is now apparent to the community that as market conditions evolve, assets that were originally safe on Aave may no longer be so. There are frictions to delisting assets and differing community opinions - as such, proposing an asset delisting process so that the community can align on the risk-tradeoffs will help streamline governance decisions that de-risk the protocol.
- Creating and updating a risk management framework and actively collaborating with a risk council to increase alignment and create a faster response path during market (a few more details above in this reply).
This is a newer challenge for us given the recent addition of Chaos as a risk manager. We’re supportive of collaborating with Chaos and other risk-adjacent service providers on creating risk frameworks and informing the community on key risk decisions. More broadly, we’re also thinking through the best ways to collaborate with all of Aave’s service providers given that our work (market risk) is inherently cross functional.
Choosing a security threshold of $X for Aave means that we expect an attacker to have to deploy more than $X for an oracle manipulation based attack to be profitable. We then estimate the cost of attack for each market (e.g. CRV) based on market parameters and token liquidity. For markets where our estimated cost falls below the chosen security threshold, we would recommend risk-off proposals such as decreasing collateral factors, disabling borrows, or freezing the market entirely if the shortfall is too large. Note that estimating the cost of attack with high precision is extremely difficult as the actual cost will depend heavily on the realized behavior of market-makers and other participants in that scenario.
Historically, our models have assumed actors act rationally. For example, we look at the minimum budget where they are profitable and where the expected value of the attack is positive.