Chaos Labs Risk Oracles

[ChaosLabs]

Summary

In the fast-paced and volatile environment of DeFi, managing risk parameters across Aave’s extensive network—spanning over ten deployments, hundreds of markets, and thousands of variables such as Supply and Borrow Caps, Liquidation Thresholds, Loan-to-Value ratios, Liquidation Bonuses, Interest Rates, and Debt Ceilings—has evolved into a critical, yet resource-intensive, full-time endeavor. Chaos Labs aims to streamline this paradigm by integrating Risk Oracles to automate and optimize the risk management process, achieving scalability and near-real-time risk adjustment capabilities.

Motivation

Today, updating on-chain risk parameters involves manually creating payloads before being presented for voting by the Aave community. Given the abundance of networks and assets on the Aave protocol, this manual and cumbersome process significantly burdens teams across Chaos Labs, ACI, BGD Labs, and more. Our solution, grounded in guarded automation, alleviates these operational inefficiencies by seamlessly translating governance-approved risk parameters into actionable, on-chain updates.

Introduction to Risk Oracles

Risk Oracles represent an advancement designed to automate the laborious process of updating risk parameters. The conventional approach to monitoring blockchain risk is challenging and marred by significant delays from risk signal detection to implementing protective measures by risk managers and the DAO. This latency is untenable, especially considering the billions in TVL and the inherent market volatility. Risk Oracles serve as the crucial linkage between the analytical prowess of the Chaos Labs Cloud and the practical application of governance-validated recommendations on the blockchain, extending the capabilities of the existing Risk Steward System developed by BGD Labs.

CapsPlusRiskSteward Contract, developed by BGD Labs.

Operational Mechanics of Risk Oracles

The Risk Oracle introduces a bifurcated operational framework, encompassing both off-chain and on-chain workflows to ensure dynamic and secure risk parameter updates.

Offchain Workflow

Situated within the Chaos Cloud, this segment is the analytical engine where various risk indicators are continuously monitored. These include but are not limited to, utilization of supply and borrowing caps, debt ceiling thresholds, market volatility, and patterns indicative of anomalous user behaviors. A simulation is triggered upon exceeding specific, pre-established thresholds, computing the newly optimized parameter settings. Following rigorous internal validation, these recommendations are prepared for on-chain submission.

Onchain Workflow

Recommendations validated off-chain are funneled to the Aave Risk Stewards Contract, embodying sophisticated business logic to authenticate the proposed parameter adjustments. Each parameter update is bounded by governance-established limits to facilitate “optimistic updates”—that is, updates enacted without necessitating an entire governance cycle. The updates are enacted upon successful validation, dynamically refining the Aave Market’s operational parameters.

Pilot Implementation: Version 0

For the pilot phase, we focus on low-risk and high-adjustment frequency parameters. We will utilize the current Risk Steward framework, which is functionally limited to increasing supply and borrowing caps up to 2x their current configuration.

Leveraging the existing infrastructure developed and deployed by BGD Labs, alongside the new off-chain systems to be engineered by Chaos Labs, this pilot represents a controlled, scalable approach to validating the Risk Oracle’s efficacy and operational integrity.

This adjustment optimizes the existing process and does not necessitate any community vote or changes to current mechanisms or community structures.

Next Steps

In the upcoming weeks and months, Chaos Labs will concentrate on extending support for additional risk parameters through Chaos Risk Oracles. This initiative aims to refine and streamline the risk parameter update process. By enhancing our Risk Oracle capabilities, we aspire to automate further and optimize risk management, ensuring dynamic, near-real-time adjustments to Aave’s complex ecosystem. This focus aligns with our commitment to streamlining operations, reducing manual intervention, and elevating the protocol’s efficiency and security in the volatile DeFi landscape.

Resources

• BGD Risk Steward Phase 2

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this forum post.

Copyright

Copyright and related rights waived via CC0

[EzR3aL]

Hello Chaos Labs,

Im impressed by what you are presenting here. I have said this many times before, we need automation where it is possible and not potentially harming user.
Starting with the functionality of increasing supply and borrow caps makes sense, as there isn’t much risk associated with it (only with long tail assets maybe).

Will there be a test phase with a few assets of different classes like stablecoins, ETH/ETH-correlated assets and others?

Will there be someone checking the Risk oracles in the beginning, just to see how they behave?

[ChaosLabs]

Thanks for the feedback @EzR3al.

We completely agree on the importance of implementing automation cautiously to enhance efficiency without compromising user safety.

We plan to initiate a pilot phase where we’ll experiment with a diverse set of assets, including stablecoins, ETH/ETH-correlated assets, and others to ensure a comprehensive analysis. During this phase, our focus will be on monitoring the performance and reliability of different asset classes under automated conditions. All recommendations will continue to be confirmed manually before executing them on-chain via risk stewards.

Additionally, the Chaos Labs team will closely monitor the Risk Oracles from the start. This will allow us to evaluate their performance precisely and ensure any required adjustments are made before we broaden the scope of implementation.

We’re excited to see where this leads and will keep you updated on our progress.

[bgdlabs]

Fully support on the initiative, going in a similar direction as other past developments on the Aave DAO.

To give some extra overview to the community on our support, we would like to present a more elaborated overview of our understanding of a dual steward/oracle architecture:

• One of the natures of Aave is being a decentralised settlement layer. The Aave governance decides on a predictable smart contracts technical framework of settlement, and all entities around it play their role. It is key to understand that this doesn’t mean all entities involved are decentralised, but the rules coordinating it are decentralised: from the governance itself based on AAVE, to the limitations imposed to changes (e.g. Risk Steward contracts, or roles in the Aave v3 system), passing by other components like the consensus-based a.DI for cross-chain communication, or even contractual-wise with the DAO having independent service providers. Each component has a scope of work and limitations, and the system itself has a “super-constraint” in the shape of decentralised governance proposals.

• The initial Risk Steward (to increase caps on Aave v3 instances) was a really productive first experimentation. The first angle to analyse its success tends to be the operational one: before having the CapsPlusRiskSteward, increase of caps was a more burdensome procedure and caps were not updated so timely.
  This improved, but the organisational implications are even more important. When two entities were involved into the CapsPlusSteward (Chaos Labs and Gauntlet), in part of the proposals there was disagreement on the update of caps. In some cases the led to skipping the risk steward and creating governance proposals, in others, it led to no action. What it looks like non-optimal at first sight, it can be seen as a reflection of a core aspect in a system like Aave and similars: there are qualitative aspects on which even risk experts disagree, and it is close to impossible to reproduce this qualitative aspects on-chain, without any type of oracle; oracle like this Chaos Labs Risk Oracle.
  The strong point of a blockchain-based system like Aave is that no matter the external inputs, it is possible to constraint them with on-chain logic.

• Oracles like the one proposed include dynamism into Aave, whenever constraint by on-chain stewards to not sacrifice predictability. Apart from reducing operations overhead, the system becomes more reactive (with more frequent updates), but if correctly constraint still fully predictable for entities. E.g. for a user supplying WETH as collateral on Aave, LT reductions or increases via an oracle/steward should not affect meaningfully his position if having it in a healthy stage.

• This approach also works as a self-protection mechanism for the Aave DAO. Even in unprofessional cases like a service provider abruptly deciding to cut its own engagement (e.g. Gauntlet), the system doesn’t really suffer, as last case scenario, speed of updates with be lower, but no fundamental negative consequence will arise.

Excited to see this system from @ChaosLabs connected to the Risk Stewards layer, not only for caps, but for multiple other Aave parameters.