Chaos Labs - Risk & Simulation Platform Proposal

[omergoldberg]

Chaos Labs - Risk & Simulation Platform Proposal

Summary

Chaos Labs is proposing to onboard the AAVE core team and the community into its risk and simulation platform to better test new protocol upgrades, parameters, and the GHO stablecoin in various market structures and scenarios. This platform will include ways to help the community onboard new collateral types and assets and bespoke protocol research with publicly available analysis and results.

Who is Chaos Labs?

Company background

Chaos Labs is a software company building a unified simulation platform that allows teams to test protocols efficiently while understanding how they will react to adversarial market environments. The backbone of our technology is a cloud-based, agent- and scenario-based simulation engine that allows users to create specific market environments to test new features & assets to understand risk parameters better. Our team comprises top engineers from companies such as Apple, Facebook, Instagram, Amazon, Microsoft, Google, and more with years of experience in infrastructure, security, and platform “chaos” testing.
The Chaos Labs simulation platform and environment is built to be as close to mainnet as possible. Each simulation run forks from a specified block height (default block height is the most recent) so that your inputs include up-to-date account balances and the latest smart contracts and code deployed across DeFi. While testing volatile environments, it is imperative to look at your protocol holistically. The Chaos Simulation platform helps understand how external factors (cascading liquidations, oracle failure, gas fees, liquidity crises, etc.) will impact a protocol in various situations.

Company values

Our mission is to secure and optimize protocols through verifiable agent- and scenario-based simulations.

• The best simulation testing is as close to production as possible. The Chaos Labs’ cloud platform will spin up an EVM-compatible forked environment for every simulation. Since all simulations are executed on a fork, all code deployed to Chaos can immediately be transferred on-chain and/or used for production. An additional benefit is that the fork gives us a snapshot of mainnet out-of-the-box. This allows us to run simulations with minimal assumptions and deviations from mainnet conditions.
• Trust, but verify. We can build a test environment and convince you that it is correct, but that trust only goes so far. Our tooling allows core team members (i.e., simulation creators) and anyone they permit (up to the entire community) to dig into the test environment and push back against assumptions, agent creation, scenario environments, optimization trade-offs, and more. Open source agents and scenarios allow the community to understand precisely how answers came to be determined. We have built a suite of tools and libraries for rich data visualizations, auto-generated analytics reports, and internal block explorer so that users can verify the simulation results down to each block and transaction.
• Community engagement. We know that we can build the best tools to help test and optimize DeFi protocols, but we can only scale with lasting change if the relevant core team and community members are on board and actively engaged. Each protocol differs from the code to community risk tolerance, and we do not want to be the only voice translating that into proposed changes. We are a software company building tools to understand and mitigate DeFi protocols’ risks, ideally powered by the communities who care most about them. Thus, we want to engage the said community in each proposal, from simulation creation to testing review to proposed change enforcement.

Why economic security and testing are important & how Chaos protects against it

Security audits and penetration testing are crucial parts of the security stack, but they alone are not all-encompassing to limit the surface areas of vulnerability. Their primary function is to ensure that your code does what you want your code to do and that there are no major flaws, assumptions, or errors in what you wrote as you wrote it. We view Economic security as the next piece of cheese in the security stack (ref: Swiss Cheese Model), building upon the correctness of their reviews and manipulating the environment around the protocol to ensure the intended behavior plays out as intended in different scenarios ranging from business as usual to black swan events.

Since the rise of “DeFi summer,” we’ve seen nefarious actors managing to manipulate core protocols in increasingly creative manners. They are no longer looking for flaws in code, but they are manipulating the market around the target protocol to gain entrance and exploit it. This roundabout attack vector heightens the need for complex parameter setting procedures; knowing how different values for certain assets react in different environments will allow for more confident governance and usage of the protocol.

Proposal

We propose to build custom tooling for the Aave team and community to understand the protocol, including:

• testing of major upgrades
• parameter setting
• new asset listing
• comprehensive VaR calculation
• GHO launch
• and more.

Over this engagement, we will deliver a suite of new products for team use and community analysis to open the tooling up to a broader community group to run it in the future. As we embark on product development with Aave, we anticipate managing simulation creation, feedback integration, and reporting until the platform is ready for community control. In the future, we can create a new AIP proposal creating an Aave-dedicated simulation creation and analytics team (similar to the Risk DAO proposal), which can provide another voice in risk-mitigation conversations powered by data.

To continue to enhance risk coverage of the Aave protocol and transparency to the community, we’d propose tooling to cover a few major areas:

1. Risk Parameter setting
2. Asset listing
3. GHO stablecoin launch
4. E-Mode and Borrowing Power for similar assets
5. Isolation Mode and Debt Ceiling for new assets
6. v3 Portals

Simulation engine platform & unified infrastructure

From a risk and infrastructure standpoint, we see a number of tools that need to be developed and maintained for Aave to increase its security coverage on top of that provided by teams like BGD, Certora, Gauntlet, & Sigma Prime. The current risk coverage covers Aave v2 (well) and asset onboarding (less so) but can be enhanced to analyze and optimize a number of areas with specific simulation and dashboard tooling to be delivered to either the community or the relevant Aave team.

Chaos Labs has developed a novel, cloud-based, agent- and scenario-based simulation platform. Our product is built on the ethos that a valuable testing environment is as close to a production environment as possible. Therefore, we utilize a hybrid approach of on-chain and off-chain simulations.

On-Chain Simulations

On-Chain Simulations fork the blockchain from a specified block height and deploy a catalog of agents, scenarios, and observations within the Chaos Cloud environment.

Agents emulate user behavior and allow us to emulate different risk behavior for protocol users. The Chaos Scenario Catalog lets us control macro variables and conditions such as gas fees, DEX and protocol liquidity, oracle return values, Black Thursday Level market events, and more. Observers allow for deep protocol analysis and better simulation insights.

Through this robust software, users can control and test a host of different factors that can impact protocol security and user funds, including

• Oracle prices
• Gas fees
• Account balances & liquidation prices
• Transaction latency
• Flash loans

Economic security testing and simulations via the Chaos Labs platform allow you to test your protocol in different scenarios and custom environments to understand where your risks lie before a malicious actor can exploit them.

In this manner, we will integrate directly with the Aave protocol and provide transparent simulation insights.

Off-Chain Simulations

Chaos Labs also deploys off-chain simulations, utilizing machine learning and statistical models that ingest data sets from various off-chain data sources to test economic structures prior to any solidity or on-chain code being written. As part of the off-chain simulations, Chaos Labs will run a massive number of Monte Carlo simulations to assess the protocol’s VaR per Market (Chain) and across markets.

A combination of On-Chain and Off-Chain simulations allows us to control and test a host of different factors that can impact protocol security and user funds including:

• Oracle behavior
• Gas fees
• Account balances & liquidation prices
• Transaction latency
• Flash loans
• volatile markets impact on protocol reserves
• asset correlations and liquidations
• drastic price drops impact on liquidations and liquidity
• high gas fees impact the efficiency of the liquidation process
• new asset borrow demand, revenue, and liquidation processes

Product screenshots

The underlying tooling will have two main user access types:

Group 1 - Create/write: This access will be available for the relevant core teams of Aave (protocol engineering, Aave Risk, BGD, etc.) so that they can create agents, scenarios, simulations, and interact with the simulation engine via all available methods (hosted interface, CI, API, etc.). As the Aave simulation integration is developed, they will have access to creating these test environments to suit their needs and analysis. There will be no limit on the number of users that have access, but they must be whitelisted by one of these groups.

The simulations they run and their related outputs will be private by default and opened up to the community once related to a public discussion, parameter change, or otherwise related governance vote.

Group 2- Read-only: The community will have a dedicated read-only access interface to audit and analyze the work done by Group 1 as well as Aave-specific dashboards to facilitate community decision-making. This access will not be gated and will allow for full transparency to the community in how risk decisions are being made, especially regarding optimization trade-offs in different scenarios thus pushing towards more data-driven decision-making within the community on robust analytical toolsets.

There are two reasons why we cannot open “create/write” access to the whole community:

1. Black Hats: This tool is meant to understand how the protocol, both features in development and those already deployed to mainnet, react to volatile and adversarial market conditions. If someone unrelated to the Aave community could access this platform for their own usage or peer into private failed tests, they would be able to subsequently exploit them prior to the developers and community correcting them.
2. Compute usage: These simulations will cover a multitude of transactions across various wallets and protocols over the duration of thousands of blocks. Running and maintaining this is not easy or inexpensive, thus we must make sure we have the appropriate guardrails in place to minimize its abuse over the duration of the engagement and, thus, minimize the cost to the community.

We will be public with product development, testing, and roadmaps to maximize transparency with the community and maintain alignment on the most pressing needs.

Protocol coverage

Risk and testing is a broad-ranging category. We will not cover security auditing or formal verification as those are covered elsewhere by protocol vendors, but we plan to maintain a flexible mandate to focus on what Aave deems most pressing in terms of feature deployment, risk analysis, and simulation development.

We will break the coverage into two distinct areas:

• Core Aave risk product and simulation development needs
• GHO launch and maintenance product and simulation development needs

With that, we’ve adapted BGD’s task framework to outline where we think the focus should be as we see it today.

On the following list, we present the ones that we believe Chaos Labs can help with. We divide them into these 2 classes:

• SURE. Chaos Labs will tackle the task, and uncertainties apart (community not approving, model not really defined, etc), will compromise to complete it.
• PENDING PRIORITIZATION. Chaos Labs will begin work on the task as it is prioritized by either one of the Core teams or the community at large, pending capacity.
• BEST EFFORT. Chaos Labs will participate in the task, potentially completing it too, but usually, the scope is too broad or undefined at the moment to compromise to a level of completion at the moment.

Task	Type	Coverage Area	Notes
AAVE v3 Collateral factors	Sure	Parameters	Use simulations to provide community tooling and recommendations for parameter optimization. Users will have the ability to interact with each simulation on a block-by-block level to understand transaction differences and outcomes.
Aave v3 Risk Parameters	Sure	Parameters	Use simulations to provide community tooling and recommendations for parameter optimization. Users will have the ability to interact with each simulation on a block-by-block level to understand transaction differences and outcomes.
Asset Listing Portal	Sure	New Assets	More information is below.
Asset Listing Risk Assessment	Sure	New Assets	More information is below.
Borrow and Mint Cap Recommendations	Sure	Parameters	More information is below.
Community Agent Access	Sure	CL Products	Allow the Aave community to access agent modules for feedback and discussion around the most relevant user types to better test protocol.
Community simulation access	Sure	CL Products	Allow the Aave community to access simulation results and observable dashboards to further discussion around optimal protocol changes
Open-source agent code base	Sure	CL Products	Community engagement via public open-source agents
Aave Portal features	Pending Prioritization	AAVE Features	Determining the appropriate mint cap based on bridge throughput and native DEX liquidity + relevant risk factors.
Aave Seatbelt Enhancements	Pending Prioritization	AAVE Features	Enhance the existing governance tool with forward-looking simulations for impact and accuracy
CI Access	Pending Prioritization	AAVE Features	Integrate automated simulations as part of the code push process to detect regressions introduced.
Efficiency mode optimization	Pending Prioritization	Parameters	Simulate and optimize E-mode modules for the protocol.
Interest Rate Modeling	Pending Prioritization	Parameters	Iterate on interest rate curves in different market environments to measure impact and efficiency.
Isolation Mode	Pending Prioritization	Parameters	Simulate and optimize Isolation Mode
modules for the protocol.
Other protocol markets (Avalanche, Polygon, etc.)	Pending Prioritization	Parameters	Explore duplication of simulation engine and parameter setting simulations to other EVM chains for protocol optimization.
Aave v1 & v2 Risk factors	Best Efforts	Parameters	Duplicate v3 simulation tooling for older versions as is needed
Bridge risk analysis	Best Efforts	AAVE Features	Research and simulate bridge interactions to understand and report on potential risk factors for protocol consideration. Determine impact on user funds for ongoing monitoring.
Credit limit setting	Best Efforts	Parameters	Use simulations to provide community tooling for parameter optimization. Users will have the ability to interact with each simulation on a block-by-block level to understand transaction differences and outcomes.
Oracle Failure	Best Efforts	AAVE Features	Simulate and test the impact of oracle failure on the protocol and liquidations to ensure appropriate measures are in place to protect user funds.

Asset Listing Portal

One of the key focuses of this engagement would be building an Asset Listing Portal to help streamline new collateral onboarding to the Aave protocol similar to what we have built for dYdX, found here. This tool will help streamline community decision-making by automating the collection and analysis of key markets data around assets such as:

• Market beta & volatility
• Exchange liquidity and slippage
• Market cap
• On-chain activity
• Third-party lending integrations (i.e. compound, maker, etc.)
• Security & demand scoring
• Revenue estimation
• Initial parameter recommendations

This tool will help streamline the addition of new assets to the Aave platform, thus increasing platform fees to the treasury and token suppliers while balancing the overall protocol health.

GHO Simulations

Launching a stablecoin is hard; maintaining one is 10x so. The path to stability and scale for decentralized stablecoins is littered with best efforts, failed experiments (UST, IRON), and only a few true successes. Most decentralized stablecoins fail because of the depth and breadth of the unknown-unknowns: how do their stability mechanics react to uncertain and volatile environments? Does each new change and development expand the surface area of that potential vulnerability?

The thread announcing GHO is full of questions that could (and should) be answered with in-depth simulations to understand the mechanical reaction of the GHO implementation.

As a part of this engagement, our focus will not only be on the core Aave lending protocol, but also on the security and expansion of the GHO stablecoin. Potential simulations and tooling to be built can be found below.

Task	Type	Coverage Area	Notes
Depletion of liquidity	Sure	Simulations	What is the impact on stability if X% of liquidity is withdrawn from a given protocol (Aave, DEXs, etc.)? This is how UST initial began to break
GHO native interest rate modeling	Sure	Simulations	Iterate on interest rate curves in different market environments to measure impact and efficiency.
Collateral diversity	Sure	Simulations	New asset listing, parameter setting, and risk scoring
Facilitator diligence	Pending Prioritization	Simulations	Simulate the impact and volatility of different facilitators to help determine optimal bucket limits for initial GHO supply.
Liquidity incentive optimization	Pending Prioritization	Simulations	How to best spend funds to most efficiently create deep liquidity pools?
Staking module exploit	Best Efforts	Simulations	What would happen if Aave gets exploited in the staking module? If GHO is backed by stkAAVE would the token lose its backing and peg?
GHO oracle set up and manipulation	Best Efforts	Simulations	Testing oracle configuration and potential failures
Stablecoin arbitrage	Best Efforts	Simulations	How do lower borrowing costs on stablecoins impact protocol-level risks, especially around recursive borrowing? What are the key parameters to monitor to protect against this scenario?
GHO supply cap	Best Efforts	Simulations	Monitoring market exposure of GHO as it finds its footing and doesn’t become too large too quickly. What are the appropriate levels/thresholds based on liquidity and other factors?
stAAVE mint discount	Best Efforts	Simulations	Simulate user interactions and ROIs for stAAVE holders to determine the discount rate with the highest value-add to the protocol

For all of the proposed tooling, we will publish technical walk-throughs and repo links to any relevant open-sourced tooling (such as agent and scenario creation) for public review and feedback. We’ll open as many of the interfaces to the community as is applicable and appropriate shortly after deployment.

Community engagement

Community Risk Calls

As part of our commitment and efforts towards community engagement to further drive protocol security, Chaos Labs would organize a monthly risk call for the AAVE community alongside all other protocol security contributors. This call would be focused on any new major protocol or market developments such as:

• New risk tooling and analyses
• Protocol launches and technical proposals (GHO, v3, etc.)
• Asset listing proposals
• The broader market environment
• and anything else the community deems important and relevant for discussion

We would schedule said calls for a recurring hour-long block on a monthly basis in addition to any ad-hoc community risk calls when deemed necessary. A recording and summary of these calls will be provided.

Ongoing updates

Aave’s dedicated relationship manager will be an active participant in organizing the risk conversation and updating the community in the forums. We will commit to a monthly update post focusing on both works complete and ongoing as determined by the community. We will also host monthly office hours to be available for community Q&A.

Proposal services coverage

• Unlimited seats to the Chaos Labs simulation platform for white-listed users
• Simulation capacity up to 50k monthly limit
• Dedicated headcount from Chaos Labs supporting Aave, including:
  • One relationship manager primarily dedicated to Aave.
  • Support of one PM covering Aave’s needs and proactively providing support for new simulations and dashboards
  • Two engineers and two data scientists/analysts building simulations and risk-related dashboards and reports.
  • The balance of the Chaos Labs team will be available on an as-needed basis to support Aave with ad-hoc requests at the time of high concern.
• Chaos Labs will build or facilitate the development of all relevant agents, scenarios, and simulations for the Aave core team and community.

Long-term relationship

As has been stated above, we are a software company at our core. We’re building a robust platform which empowers communities to develop, test, and risk-manage their protocols at a more sophisticated level without needing to rely on any single outside third party. While our focus is to use this engagement period on product development for the AAVE community, our hope is to eventually onboard a consortium of community members to create the relevant testing environments and risk evaluations for the Aave protocol on top of the Chaos Labs platform. We promise to be as transparent as possible during the process while it is centrally managed to build towards this more open and decentralized future.

As a first step toward this future, we anticipate onboarding a small subset of community members by the end of this engagement to be paid bounties for the creation of Aave-specific agents and scenarios within the Chaos Labs environment. We will provide more updates on this as it is closer to launch.

Measures of Success

Security and testing is a tough realm to measure appropriately. The successful completion of the AAVE protocol’s objectives will be measured against KPIs that will be derived from the specific objectives agreed upon between AAVE and Chaos Labs. On top of those, We will also look to measure things such as:

• Product deliverables & task completion
• Usage & users onboarded into the simulation and testing environment
• Community and core team member NPS of our relationship
• Participation in the GHO stablecoin launch
• Communication and transparency to the community on work done and product access

Previous AAVE Work

• AAVE v3 Risk Application
• stETH Depeg Simulation and Analysis
• Diving Deep into AAVE v3 Subgraph Data Validity
• AAVE v3 Risk Bot

Pricing

• 12-month engagement term
• $3,000,000 flat engagement fee
  • $750,000 paid upfront in stablecoins
  • $750,000 paid in stablecoins streamed linearly over the course of the contract
  • $1,500,000 in AAVE tokens vested linearly over the course of the contract
• $300,000 additional stablecoins for community agent and scenario creation
  • This will be distributed at the signing of the engagement and all unused funds returned either to the DAO or to the Grants multisig a the end of the initial term if not renewed

Next steps

We are eager to have a lively discussion with the community in the forum about our proposal and potential engagement. If the initial snapshot vote is successful, we will propose an initial product roadmap in prep for the on-chain vote.

[omergoldberg]

Hi everyone - quick update, we’re excited to announce the v0 launch of the Aave v3 Risk Application!

We support v3 deployments on:

• arbitrum

• avalanche

• polygon

• optimism

• harmony

• fantom

You can learn more on our blog.

Please let us know if you have any questions or ideas for new features!

[imrankhan]

I’d like to express my vote of confidence for this proposal. Aave and its community can benefit from working with the Chaos Labs team - specifically around Chao’s simulation engine and Aave’s new product offerings such as GHO.

[omergoldberg]

Additional update -

Based on conversations with community members this week, we’ve made two additions to the proposal:

1. Breaking out “community engagement” into a new section highlighting a regular risk community call with relevant core contributors (and available to the public) discussing protocol risk + engagement updates.

2. Proposal to be added as protocol admins for Risk and Asset Listings to further streamline our protocol engagement.

[fig]

I am surprised to see fewer comments on this post - especially given the recent interest in Llama’s proposal.

From the basics, Chaos is a strong team and I believe it adds the freedom of choice for more risk tooling to the Aave ecosystem. As we’ve seen, it is best to have multiple organizations servicing the DAO, rather than just one.

As discussed in other threads, we hope to lean more towards stables vs. Aave to limit emissions. Is this something your team would consider?

Would love to have other community members comment on the size.

[benhoneill]

Hi @fig - Ben here from Chaos. We are certainly open to adjusting the distribution of AAVE vs. stablecoins in the funding of the engagement based on community feedback. We drafted the proposed structure to ensure that Chaos’s long-term incentives were aligned with the AAVE community (protocol growth and token success), especially with dedicated resources and headcount (6+ people) focusing on the protocol.

While we believe that a portion of the agreement should be paid in AAVE tokens, which would also seed Chaos’ investment in ongoing governance involvement, we would welcome ideas and proposals on what the appropriate distribution should be for Chaos and other vendors in the future looking to engage with the AAVE DAO.

[eboado]

I don’t think this kind of collaboration makes too much sense for the Aave community at the moment. My reasons are:

• Similar to the initial (now changed) Llama proposal, but way more in this one, there is quite a big overlap with other entities engaged with the Aave DAO, in this case, Gauntlet, that is, of course, being compensated by it.
• The scope is too broad and pricy, and by an entity that (even if I’m aware of https://aave.chaoslabs.xyz/, which is a quite nice dashboard) doesn’t have any history with Aave. From what I see, the projects of Chaos Labs with other protocols/DAOs have a smaller scope, so I think that is the only way to go here.
• This proposal is quite vendor-tying, and even if I know there are already cases in that direction (aforementioned Gauntlet, partially Certora), the community should probably start having a harder stand on that. Especially when we are talking about a really big amount like $3.3m.
• Some items seem to be porting products developed for other entities to Aave, which is fine, but obviously changes a bit the pricing.
• As I also mentioned on the Llama proposal, again, GHO is not live and/or public. The Aave DAO can’t start paying for services on something which is not completely clear and open. The result will be that an entity will be compensated for something that doesn’t even exist yet, and on what there should be a more serious evaluation (for services) once in the market.
• Part of the scope includes “access” features to the certain infrastructure of Chaos Labs. Even if potentially useful, are we sure other entities on the risk side will use this? Because from the technical perspective, even if could help in some cases, it is not something really required.
• No RISK_ADMIN and ASSET_LISTING_ADMIN should be given to anybody that doesn’t have an extensive history with Aave.

In summary, without not more results shown in a smaller scope engagement (continuous if required), I’m against this proposal.

[G-Blockchain]

@eboado

No RISK_ADMIN and ASSET_LISTING_ADMIN should be given to anybody that doesn’t have an extensive history with Aave.

+1 on this statement.

Overall, reviewing the Chaos Labs proposal. I believe that Chaos should contribute more first as a community member in the forum and provide input and research from the risk and simulation platform allowing Chaos to build a relationship with community. With that, I believe that Chaos could have more success with such a proposal.

[omergoldberg]

Thank you for the feedback. Regarding the admin role - while it was not an original consideration, we received requests from AAVE contributors to add the admin roles to our proposal. If the community does not feel that this is appropriate we will gladly remove it and revert the proposal to the original version.

[AndrewA]

@eboado

• Similar to the initial (now changed) Llama proposal , but way more in this one, there is quite a big overlap with other entities engaged with the Aave DAO, in this case, Gauntlet, that is, of course, being compensated by it.

I’d be really curious to understand this exact overlap as well. Would also be great to understand the nuances between the two compensation models (comparing Gauntlet and Chaos Labs).

[A_J]

AAVE treasury is not huge and will run dry in months to come.

Proposals such as this one should look for grant instead of funding. Reference to a word of caution to another proposal by Llama can be found below:

Proposal: Llama <> Aave

Not in favor of such proposals which should look for funding from AAVE Grants instead of Protocol. The numbers asked for are insanely high and will open the flood gates by all AAVE partners/contributors/associates to ride back on similar proposals and run the treasury dry in months to come. This will be disastrous for AAVE and the community while these partners/contributors/associates take their cut and move along to the next protocol.

As an AAVE holder I am concerned, AAVE holders be warned, the VCs are at play and will suck up treasury and move on to next project with such proposals after sucking AAVE treasury dry - the solution is to seek funding from Grants instead of treasury.

[omergoldberg]

Hi @eboado, thank you for the thoughtful feedback. I will address the points below. A majority of the proposal focuses on servicing new product areas and features such as AAVE v3 and the upcoming GHO launch. We’ll begin by elaborating on these areas. Subsequently, we’ll discuss full-time headcount, areas of overlap, and how these will benefit AAVE.

• v3 Risk Management
  • At the time of drafting this proposal, it has been 6+ months since the launch of AAVE v3 across 6 different L2s and side-chains. Since launch, the community has not seen or received any significant tooling or solutions for risk management in v3 despite billions of dollars across supply and borrow markets. v3 was the main motivator behind initial conversations with the AAVE risk team and the reasoning for focusing on building the AAVE v3 Risk application first. v3 introduces a suite of new features and functionality such as e-mode, isolation mode, portals, and multi-chain deployments. While all of these are exciting and innovative they also introduce new risk vectors which require analysis, modeling, tooling, and monitoring. We look forward to collaborating closely with the AAVE community and ensuring that the DeFi Risk Management advancements are on par with protocol development innovation.
• GHO
  • Another pillar of early discussions with the risk team is the upcoming GHO launch. While it’s not live yet there is still a significant amount of work leading up to launch. Our simulations, agents, and scenarios integrate directly with smart contracts. Therefore, the earlier we start instrumenting GHO the earlier we can provide valuable feedback. This feedback includes analysis of economic design, initial launch parameter settings, risk and analytics dashboards, and monitoring. Risk tooling and data analytics should be used during development to ensure that significant architectural decisions aren’t made that introduce technical debt that is hard to revert while introducing protocol risk. GHO is aiming to be a cutting-edge, leading decentralized stablecoin. In our opinion, providing tooling and analysis post-launch behooves the gravity and ambition of this goal. It puts the risk team at a disadvantage where they need to play catch up instead of being at the forefront of analytics, high-quality vetted data, and risk management. For these reasons, it is our opinion that GHO-related analysis and work should start during the testing and development phase. The aim is to avoid a “test in production” approach while giving risk a voice during development and testing. We should have the community and protocol equipped and instrumented with state-of-the-art, customized, risk, analytics, and data tooling to ensure a smooth launch and increase confidence in early investors, institutions, market makers, and liquidity providers.
• Asset Listing Portal
  • The asset listing portal for AAVE will be materially different from dYdX, both in the data provided and the platform integration. dYdX v3 is not fully on-chain, nor does the protocol take custody/liquidation risk of assets on-chain. The interface will be similar, but the underlying infrastructure and tooling (analysis, simulations, data, etc.) will be rebuilt from scratch for AAVE.
• Vendor Dependency
  • Our goal is to engage the community and increasingly become a platform for community engagement with regard to risk vs. a consultant solely providing pointed recommendations.
  • As the AAVE dedicated simulation engine expands and we engage the community in agent and scenario development, all of that code will be open-source for developers to use in their own testing environments
    • Since all on-chain Chaos simulations run on EVM compatible mainnet forks all agent and scenario implementations are in Solidity or Javascript. Therefore, it is not tied to any Chaos-specific language or platform and can be reused in Hardhat, Foundry, etc.
• Dedicated Headcount - Full-Time AAVE Contributors
  • The Chaos team is ready to commit 4-6 full-time Chaos engineers and data scientists to the AAVE community for the course of the engagement. To the extent of my knowledge, we are the first risk vendor to make this commitment. The Chaos technical team is world-class, hailing from companies such as Google, Meta, Instagram, Apple, Amazon, Microsoft, and more. With the amount of innovation happening within AAVE and anticipated product launches, this will be a great boost to the productivity and bandwidth of the AAVE risk team.
    • The dedicated headcount and close collaboration with the AAVE risk team and community of contributors will allow us to tackle this ambitious scope. Additionally, a team of full-time contributors will allow for flexibility as we approach new product launches.
• Broader Scope
  • While the proposal is overall thorough and clearly identifies several areas of focus and responsibility we are purposely leaving a portion of it open to community requests. To be clear - we are viewing this as a partnership and full-time AAVE contributor role. As builders, we understand that priorities are dynamic, especially in a community such as AAVE which is continuously pushing the envelope and level of innovation. We are taking this opportunity to declare - there is no risk-related task that we will be unwilling to contribute to. Community priorities may shift over the next 12 months and this agreement doesn’t “only cover v2 / v3 or GHO”. We’re team players and willing to contribute wherever we are asked to and excited to deliver impact in any way that the community deems valuable. A good example of this is how we began building the v3 Risk application and quickly realized that the data was not valid. We then progressed to research, identify and fix the problem. This is not an obvious reaction for a typical Risk vendor. However, it is part of the Chaos Core Ethos. Nothing is someone else’s problem. We’re staffed, willing, and able to tackle any technical issues. We hope this attitude and view is something that the community will benefit from.
• Areas of Overlap
  • For areas of overlap, our opinion is that multiple risk vendors are a feature, not a bug. AAVE is a best-in-class borrowing protocol, currently managing 10 billion in TVL. The benefits of robust risk management cannot be overstated. The DAO can benefit from multiple vendors conducting independent and collaborative research. Underlying differences in technology will result in analysis drift and varied results and recommendations. This will allow the community to compare results, conduct discussions, and ultimately make informed decisions. We look forward to facilitating and driving these discussions on the forums (async) in conjunction with the monthly community risk calls proposed above (a specific ask from community conversations about this proposal). Additionally, relying on a single vendor creates a clear centralization risk. A single bug or misjudgment in recommendations can have catastrophic consequences. In traditional risk and finance, the best practice is to source multiple vendors with different methodologies and risk assessments. These are then consolidated and referenced to drive discussions and ensure that there is a holistic analysis.
• Access to the Chaos Platform
  • Based on conversations we have had to date, this was something that was of great interest and something we are eager to continue opening up to the Aave team/community on a white-listed basis. The team provided by Chaos will be the primary “Aave contributors” utilizing this capacity at the onset of the engagement, but we wanted to make it clear that this was an option for other teams as necessary.

We’ll be releasing additional AAVE-related deliverables over the coming days. This should give more insight into the quality and speed of execution while serving as a preview of the value that we can drive for the AAVE community. I’ll update and link to those on this thread as they are released.

[omergoldberg]

Post update –

• Removed RISK_ADMIN & ASSET_LISTING_ADMIN proposal
• Added link to newly launched v3 Risk Bot

Will follow up with more deliverables over the coming days and look forward to answering questions the community may have. Thanks!

[devenmatthews]

Blockchain at Berkeley would like to express its support for the Chaos Labs proposal.

We have confidence in the team, and think AAVE community will get a significant ROI by having Chaos Labs as an active contributor. While the mentioned initiatives are important, we think allowing Chaos Labs contributions to not be contained to a specific set of tasks will make this investment far more valuable. Dedicated headcount, taking payment in native currency, and contract renewal align incentives properly for Chaos Labs to make this deal worth the funding they are asking for.

We are excited about the plan to open the Chaos labs platform to whitelisted individuals, as well as the redundancy upon current risk vendor activities. Diversifying risk software, as well as the individuals who create the simulations, minimizes the trust needed in any single risk provider. The stakes are high, we are hopeful about bringing on an active contributor as invested in AAVE’s success as Chaos labs is.

[MatthewGraham]

After much thought I think there is a need for additional actors to play a role in evaluating the risks to the Aave Liquidity Pools. However, I do not support this proposal or this approach in funding.

GHO should be removed which brings it inline with other submissions or vice versa. My personal view here is to remove GHO and come back later with a separate proposal.

@eboado

The Aave DAO can’t start paying for services on something which is not completely clear and open.

It is my own opinion, crude risk analysis is straight forward, better documentation from Aave companies would enable this and the cost of basis risk analysis can somewhat be socialised with rewards for impact. Then anyone can learn and contribute in a similarly way. This points specialists very much towards the specialty risk work.

I am concerned by the overlap with Gauntlet and think this leads to the DAO double paying for the same service. The value add becomes open-source, covering markets Gauntlet is not and going beyond the surface level analysis. That said, a quant models face diminishing returns for effort versus marginal gain in capital efficiency. I think paying such a significant base fee for a service to monitor risk is sub optimal, I would rather see competition emerge that leads to identifying and implement change leading to payment. This makes the data and analysis a cost of doing business and not an outward facing service offering.

I would like to see Chaos be actively submitting AIPs funded by Aave Grants DAO for >6 months before applying for AIP funding. The Grants DAO should bridge the gap and if that is not an ideal route, I would question the intent to contributor. After all looking at the team size, the wages are not what is driving the prices as it is not a bottom up derived pricing model evident by the top line figure.

I am someone who started not getting paid by Aave directly or indirectly and still find myself doing things outside of the Grants program and Llama to help advance Aave. If I can do this and it is normal for businesses to incur costs all the time in the hope of profitability. I would like to see Chaos build a track record of implementing change via AIPs as an eligibility requirement to AIP fundings. Grants make this easy, worse case a grant supplements cost and demonstrate willingness and dedication without instant reward.

On a good note, 10bps on $4.1B is around $4.1M which is what Gauntlet is proposing on Compound just now. This is not something a $19.9M a year revenue generating dApp can support either. Interesting this proposal emerged around the same time on the forum…

Chaos is 8bps relative to Gaunlet’s 10bps.

[PennBlockchain]

Just wanted to chime in here and give our two cents. It’s been great reading all the comments and we enjoyed speaking with the Chaos team last week.

Overall, we think some of the past work the team has put out speaks for itself and the price seems worthy of other comparable approved “work contracts.”

Some points to consider and some questions we asked the team are:

• It’s important to realize that this is the first time Chaos is proposing parameter changes. Not a negative as more of a precaution.
• Whether this product would be best for the DAO as a whole or the devs that are most important for it.

Finally one of the biggest areas of innovation in the next few months is the release of GHO. We would like to see a larger focus on the analysis around GHO and think that Chaos is equipped to do so very well!

[eboado]

Thanks for the answers @omergoldberg , some follow-ups:

@omergoldberg

Another pillar of early discussions with the risk team is the upcoming GHO launch

@omergoldberg

With the amount of innovation happening within AAVE and anticipated product launches, this will be a great boost to the productivity and bandwidth of the AAVE risk team.

I’m not aware of this “the risk team” of the Aave community apart from the collaboration of Gauntlet and ad-hoc risk analysis by Llama, which I thought were not involved in GHO at the moment. And I’m pretty sure I am quite aware of the different Aave DAO collaborations.
Could you clarify?

@omergoldberg

Broader Scope

This is a positive point, no doubt. But there is a reason why more people apart from me raise the same concern: yes, Chaos Labs is probably a really good team, but as with everybody else, there should be some onboarding time on contributions to Aave (via grants or other venues), before any continuous collaboration.
The reality is that Chaos Labs did a project on top of Aave (again, I personally think quite good work), released ~20 days ago, and the next step is to ask for a 12-months engagement with the Aave DAO for value of $3’300’000. It is not a matter of a good team or not, it is a matter of good community practices

@omergoldberg

For areas of overlap, our opinion is that multiple risk vendors are a feature, not a bug.

Well, it is a “bug” until a clear analysis on how Chaos Labs is better/complements Gauntlet is presented, given that both platforms/entities sound pretty similar feature-wise.
I’m not fully sure if covering v3 apart from v2 is a good reason: it should not even be considered by the community from now on to have an entity collaborating on the risk side of the Aave system not covering all Aave deployments. It was a clear mistake in the past; everything is Aave.

[omergoldberg]

Hey everyone – thank you all for your support and valuable feedback. We’ve incorporated all the feedback into a revised proposal here.

Looking forward to your thoughts and feedback.

Thanks!