[ARFC] Manual Risk Agents (manual AGRS migration)

[bgdlabs]

Simple summary

Introducing a new Risk Agents architectural setup to replace the previous manual AGRS (Aave Generalised Risk Stewards), making the different involved roles more explicit, and adding extra protection layers.

Motivation

The manual AGRS has been instrumental in executing risk parameter updates on the Aave protocol, handling in a constrained environment adjustments to supply/borrow caps, interest rates, and other risk-oriented configurations.

While successfully operational, there have been different improvements to be made on the current setup:

• Roles are defined, but not totally explicit on the smart contracts layer. The system has three separate roles:

  • The growth party, identifying when certain updates could be done (ACI);
  • The risk party generating and executing the recommendation (Chaos Labs);
  • And finally, a technical/security party (BGD) verifies the consistency of the recommendation compared with what is disclosed publicly to the community.

  But in the current setup, these roles are not explicit in the smart contracts, with ACI being a proposer on the risk stewards Safe, Chaos Labs as recommendations-maker being a signer on that 2-of-2 Safe, and BGD is the other signer for verification.

• Extra time-based constraints: timelock. Similar to any other steward contract, there are smart contract enforced limitation on all parameters to be applied, both quantitative (e.g., no more than x % increase/decrease of a parameter from the current value) and time-based (only updates every X days for a specific parameter). However, we think that complementary to the delay constraint, a timelock can give value for extra pre-execution visibility, and better protective mechanisms.

• Different architecture compared with Risk Agents. Given the complexity of a global migration, only the automated Risk Stewards were migrated to the Risk Agents framework, while manual ones weren’t. However, there is no limitation for this, and having both types sharing the same infrastructure makes the overall mechanism simpler.

• Lack of harmony with the set of risk providers. With the community having 2 risk providers engaged (and other bodies like the Aave Protocol Guardian), it is possible to have an architecture better adapted to it, involving better Chaos Labs and Llamarisk. On the newly proposed system, this can be achieved with the Risk Pilot and Risk Guardian explicit roles.

The new architecture and operational flow seek to apply all previous improvements.

Specification

Architecture & roles

On the new system, there are three roles defined, two mandatory and one optional:

• Risk Pilot. The entity doing the recommendation, in technical terms, who controls the Risk Oracle component and pushes updates to it. To be assigned to Chaos Labs, to mirror the previous setup.
• Risk Guardian. The entity that monitors updates submitted by the Risk Pilot. checks consistency with what was disclosed publicly, and can unilaterally cancel those updates during the timelock period, if they contain any issues. To be assigned to Llamarisk, and additionally, to the Aave Protocol Guardian as an extra layer of defence.
• Growth Support (Optional, not on smart contracts). Party more from the growth side of the ecosystem, whose role is to notify the Risk Pilot about the appetite to initiate parameter updates. To be assigned to ACI, but given that it is not a smart contract role, multiple entities could assume this role depending on the parameters and needs.

In terms of operational flow, it will work the following way:

1. (Optional) The Growth Support identifies the need to update a parameter (e.g., supply caps for asset X) and notifies the Risk Pilot to initiate update procedures on the Risk Oracle side.
2. The Risk Pilot informs the community about the planned update via manual agents, produces the recommendation off-chain, and pushes it to the Risk Oracle. Additionally, the Risk Pilot must notify the main Risk Guardian about the intention to submit a recommendation before doing so.
3. The Risk Agents automatically read the update from the Risk Oracle, validate it against configured constraints, and create a payload in the Permissioned Payload Controller contract to apply it to the Aave smart contracts. Timelock starts.
4. During timelock, the main Risk Guardian validates the correctness and appropriateness of the recommendation.
5. Finally, after the timelock is completed, the payload automatically executes, applying the risk parameter update to the Aave protocol. And the Risk Pilot informs the community about the application in production.

---

Technical components

Risk Oracle

The Risk Oracle serves as the data source for risk recommendations: the Risk Pilot registers them there, for Risk Agents to consume. Unlike the automated Risk Agent system, where updates are algorithmically generated and pushed, the manual system relies on Chaos to push updates manually to the Risk Oracle. The same Risk Oracle contract infrastructure is used, though, to mirror the same architecture and simplify both off-chain and on-chain flows.

Risk Agent

The Risk Agent contract (AgentHub and each Risk Agent contract, more info here) consumes updates from the Risk Oracle, validates them against configured constraints (stored in the RangeValidationModule), and automatically creates payloads for the Permissioned Payload Controller (PPC).
The Agent performs the same validation functions as in the automated system, but routes approved updates through the PPC rather than executing them directly on the Aave protocol.

Permissioned Payload Controller (PPC)

The PPC is the critical architectural difference from the automated system. It implements a timelock mechanism on top of risk updates, creating a mandatory waiting period during which:

• Service providers can validate the proposed changes
• The cancellation guardian can intervene if issues are identified
• The community has visibility into pending updates

Once a payload is created in the PPC, it enters a 1-day timelock before becoming executable.

This is the same contract already in use in production, for example, for the Aave Ink (Tydro) white-label instance.

This is also the only smart contract in the setup holding RISK_ADMIN role to apply updates.

Granular Access Control PPC

GranularAccessControlPPC sits between the Risk Agent system and the Permissioned Payload Controller. The main role of GranularAccessControlPPC is to give granular roles on the PPC, thus allowing multiple Risk Agent contracts to independently hold PAYLOADS_MANAGER_ROLE and multiple security actors to independently hold CANCELLATION_ROLE, without requiring changes to the PPC itself.

• Each Risk Agent contract is granted PAYLOADS_MANAGER_ROLE, allowing it to submit payloads on the PPC through GranularAccessControlPPC.
• Llama Risk / Protocol Guardian is granted CANCELLATION_ROLE, allowing it to cancel any pending payload during the timelock period.

---

Agents constraints

The migrated manual Risk Steward system will maintain all existing risk parameter constraints and minimum time delays from the current manual AGRS system, ensuring no reduction in safety guarantees. The only change will be to adapt to the extra timelock, reducing the delay by the equivalent amount (e.g., instead of a 3-day delay, a 2-day delay plus 1 day of timelock).

Risk Param	Max Change Allowed	Minimum Delay
Supply / Borrow Cap	100% (relative change)	3 days (2 delay + 1 timelock)
Base Interest Rate	1% (absolute change)	3 days (2 delay + 1 timelock)
Slope1 Interest Rate	1% (absolute change)	3 days (2 delay + 1 timelock)
Slope2 Interest Rate	20% (absolute change)	3 days (2 delay + 1 timelock)
UOptimal Interest Rate	3% (absolute change)	3 days (2 delay + 1 timelock)
LTV	0.5% (absolute change)	3 days (2 delay + 1 timelock)
LT	0.5% (absolute change)	3 days (2 delay + 1 timelock)
LB	0.5% (absolute change)	3 days (2 delay + 1 timelock)
Debt Ceiling	20% (relative change)	3 days (2 delay + 1 timelock)
LTV (for eModes)	0.5% (absolute change)	3 days (2 delay + 1 timelock)
LT (for eModes)	0.1% (absolute change)	3 days (2 delay + 1 timelock)
LB (for eModes)	0.5% (absolute change)	3 days (2 delay + 1 timelock)
Stable price cap	0.5% (relative change)	3 days (2 delay + 1 timelock)
LST Cap adapter params	5% (relative change)	3 days (2 delay + 1 timelock)
Pendle Discount Rate	2.5% (absolute change)	2 days (1 delay + 1 timelock)

*All previous constraints are submitted to changes before AIP, if so recommended by the Risk Pilot (Chaos Labs)

---

Additional SupplyBorrowFreezeSteward

One allowed flow previously by stewards was to, in emergency scenarios, set borrow and/or supply caps to the minimum (1), reducing the exposure without any damage to positions.

With the introduction of the new timelock, this flow would be submitted to a 1-day timelock, which in those scenarios is not ideal. So we will introduce a SupplyBorrowFreezeSteward for the Aave Protocol Guardian to be able to execute the same procedure, after the re-architecturing of stewards.

---

Optional application to all Risk Agents

A follow-up step on this proposal is to apply the same architecture to all types of Risk Agents, including the automated ones.
However, given that speeds consideration on those should probably be more granular (e.g., different timelocks), our proposal focuses first on the migration of the manual side. Making all types homogeneous will be straightforward, given that the architecture and flows will be pretty much the same.

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.