Introduction

Introducing Chaos Risk Agents, a new governance-aligned orchestration and validation middleware between Risk Oracles and the Aave protocol, designed to consume risk updates while preserving full control under DAO ownership.

Developed jointly by Chaos Labs and BGD Labs.

The Risk Agents framework enables:

• Same strict on-chain validations for injecting Risk Oracle values into Aave’s production protocol.
• Support for both generic validations (e.g., delays) and custom logic (e.g., numeric threshold constraints).
• Simplified setup and management of Risk Oracle data consumption. A single Agent Hub smart contract per network governs small self-contained smart contract adapters (Agents) for each type of risk recommendation update.
• Better isolation of permissions, with each Agent receiving only the permissions required to execute its task.
• Full Aave DAO ownership and control, with the ability to accept or reject Risk Oracle updates.

Context

Over the last two years, Aave has progressively integrated Risk Stewards—an infrastructure layer comprised of smart contracts capable of making limited adjustments to parameter configurations. The goal of Risk Stewards is to streamline well-defined parameter updates without requiring governance proposals, while maintaining strict operational and security boundaries.

Presently, Risk Stewards are responsible for processing risk recommendations for a range of parameters including supply and borrow caps, interest rates (e.g., slope2 values), and CAPO values across multiple assets and Aave instances.

These updates are executed either manually by risk providers (i.e., “manual” risk stewards), or through Chaos Risk Stewards, which directly plug into Risk Oracles to expose real-time recommendations not limited by operational overhead.

While the existing system has served Aave more than well, several limitations exist:

• Limited generalization: Almost every Risk Stewards activation requires ad-hoc replication of the entire architecture. This results in meaningful overhead for Aave SPs (e.g., ACI, Chaos Labs, BGD Labs).
• Limited infrastructure visibility: Tracking all active Risk Stewards, as well as their covered assets and constraints, can be challenging at times.

Current Risk Stewards Architecture

The Chaos Risk Agents framework generalizes and modularizes the process of ingesting Risk Oracle data within Aave. It eliminates redundant deployments, centralizes validation logic, and improves visibility across all risk automation layers. The result is a cleaner, more maintainable architecture that allows Aave to expand real-time risk management capabilities, ensuring consistent, verifiable execution of parameter updates.

Specification

Architecture

Risk Agent Base Architecture

The architecture involves four components:

• Risk Oracle. This component is technically external to the Risk Agents framework, and provides risk recommendations that validate and apply in the target system.
• Target system. The Aave protocol or any of its internal components. More precisely:
  • The data source for the current protocol’s data. Smart contract exposing the currently applied risk configurations on the target system. E.g., the Pool on Aave v3.
  • Configuration target. Smart contract with logic to apply new risk configurations on the target system. In Aave v3’s case, this would be the Pool Configurator.
  • Access control registry. The smart contract granting roles for each agent, and with full control over whether they can do anything over the protocol. In the case of Aave v3, this would be the ACLManager smart contract.
• Agent Hub. Singleton smart contract to be (optionally) shared by all systems of Aave in one network:
  • Registers/configures independent agents.
  • Validates mandatory/optional global constraints, for example, minimum delays.
  • Entry point for automations.
  • Defines the global lifecycle of validation/injection.
• Agent contracts. Independent smart contracts, designed to be compact. With self-contained, specific logic to execute the programmed risk updates. Agents include mainly ad-hoc validations for the specific type of update, and “interpretation” on how to inject the update into the protocol, once/if validations pass.

Risk Stewards Architecture (with Chaos Risk Agents)

---

In addition to the immediate benefits to the production systems on Aave v3, the Risk Agents middleware provides a generalized framework that can be applied to any other system requiring it on Aave in the future.

For example, any risk parameter configuration on GHO, like some of the existing GHO stewards, can be easily migrated to use the same Aave Agent Hub or a separate instance. The same applies to any risk configuration on the upcoming v4 protocol.

Generic modules

Frequently, certain types of validations are common between different risk parameter updates, for example, those involving numeric constraints like caps. However, these validations are less generic than the ones available on the Hub. For that reason, the Risk Agents middleware also introduces the concept of Generic Modules: smart contracts that can be built and deployed once, allowing different Agents to plug into them for additional validations, removing the need to reimplement/redeploy them from scratch on every instance.

An example of such of a Generic Module is the RangeValidationModule , which allows for an agent to send a reference integer value, a new value, and validate that the latter is within an allowed range.

The module is aware of the optional multi-market nature of each Agent (e.g., caps updates for all assets of a v3 pool), so it also allows both defaults and granular configurations of constraints.

Security

Risk Agents have been independently audited already by Zellic.

Additionally, we encourage security providers of the community (e.g., Certora) to review the final Risk Hub/Agents Aave’s instance, being already familiar with the existing Risk Stewards.

Active Risk Oracles

All existing and future Risk Oracles deployed on Aave will be integrated with and interact with Aave through the Chaos Risk Agents infrastructure. The set of currently active/approved Risk Oracles are as follows:

| Oracle | Function | Parameter(s) Set | Relevant Assets | | --- | --- | --- | --- | | Slope 2 Dynamic Risk Oracle | Adjusts the borrowing cost of yield-bearing assets in the event of sudden liquidity shocks | slope2 | USDC, USDT, USDe, and wETH on Ethereum Core and Linea; Full list here | | CAPO Risk Oracle | Governs price cap on yield-bearing assets relative to base asset | maxYearlyRatioGrowthPercent, snapshotRatio | Yield-bearing assets (e.g., LSTs, LRTs) across all Aave Instances | | Pendle PT Risk Oracle | Determines discount rate for asset pricing and governs liquidation mechanics for PT-assets based on asset maturityKillswitch to halt lending activity in oracle mispricing / liquidity exhaustion scenarios | liquidation threshold, LTV, liquidation bonus , discount rate | PT Assets (PT-sUSDe, PT-USDe) | | Interest Rate Risk Oracle (WETH) | Adjusts the borrowing cost of WETH on Prime | slope1 | WETH (Prime Instance) | | Supply/Borrow Cap Risk Oracles | Adjusts supply and borrow caps based on various factors including market health, utilization, and available liquidity | supplyCap , borrowCap | Various assets across all Aave instances |

Next Steps

1. Publication of a standard ARFC, collect community & service providers’ feedback before escalating proposal to ARFC snapshot stage.
2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.