LlamaRisk: Ensuring Continuity of Aave's Risk Management

LlamaRisk: Ensuring Continuity of Aave’s Risk Management

A Statement to the Aave Community — April 7th, 2026

We want to address the community directly following @ChaosLabs’s announcement. We respect the work they have done over the past three years and the standard they set. Their departure is a significant moment for Aave, and it deserves a thoughtful response, not a rushed one.

The community should know that Aave’s risk management has never rested on a single point of responsibility. The dual-provider model existed precisely for moments like this. LlamaRisk is ready, prepared, and positioned to ensure uninterrupted risk coverage. We will absorb Chaos Labs’ departing functions and expand coverage to ensure there are no operational gaps.

Where We Stand

LlamaRisk is a team of 16 full-time professionals with an unwavering commitment to the Aave ecosystem, entirely self-governed and free from external investor mandates. We have served the Aave DAO as a risk service provider since 2024. During that time, we have rigorously reviewed every major risk decision, asset onboarding, and parameter change that went through governance. Our role was specifically designed to ensure that no single team’s judgment goes unchecked. That function does not disappear today. It becomes more important.

LlamaRisk delivers risk frameworks, parametrization, and quantitative models underpinning all Aave deployments. We jointly operate Horizon as a mission-critical partner. We build protocol-owned risk infrastructure on Chainlink’s Runtime Environment (CRE). We serve as the only independent legal and regulatory research capability. Here is what we already operate or have proposed:

  • LlamaGuard NAV, live on Aave Horizon, pricing tokenized RWAs through Chainlink CRE with dynamic risk bounds and automated safeguards.
  • Fully verifiable risk-managed price feeds and risk parameter automations built on neutral, trusted Chainlink infrastructure, including a risk-managed price feed for USDe and the methodology for PT token pricing.
  • Quantitative research spanning stress testing, Value at Risk (VaR) modeling, liquidation cascades, cross-spoke contagion modeling, credit line utilization dynamics, and RWA settlement friction simulations.
  • The ratified Umbrella methodology that anchors coverage targets to external market risk factors.
  • Ongoing risk assessments, parameter recommendations, and reviews across all Aave V3 markets.
  • Automated alerting systems monitoring oracle deviations, utilization spikes, liquidation cascades, and parameter update anomalies across all markets, a capability we proved during the CAPO oracle failure when we identified pricing divergences in real time.
  • Continuous communication channels with stakeholders and asset issuers to ensure full situation awareness and inter-team coordination.

Our Thesis is Self-evident

In order to scale while maintaining resilience, Aave’s risk management must evolve from a delegated service into core, protocol-owned infrastructure.

Chaos Labs’ model centralized critical responsibility in a single external provider operating as a closed-source black box, with no protocol ownership of the code, limited visibility into the methodology, and no ability to independently verify or override parameter updates. Delegation without ownership creates structural dependency risk and vendor lock-in.

The system we propose will serve as a drop-in upgrade for risk oracles built on neutral Chainlink infrastructure. All off-chain logic is accessible to Aave Labs and trusted partners, and full control of that logic is granted to the Aave DAO. This design represents a fundamental shift in how DeFi protocols can access and act upon risk signals, effectively expanding core protocol capabilities to off-chain computation.

Scope We Will Absorb

We are prepared to absorb Chaos Labs’ departing functions in full. Critically, we will do so through infrastructure the protocol owns, not rents.

The case for this shift is not hypothetical. Two material incidents in recent months illustrate the structural vulnerability of the previous model. On March 10, the wstETH CAPO oracle malfunctioned, resulting in approximately $1.03M in borrower damages, 47 wrongful liquidations, and over 4 hours of depressed pricing. Due to the black-box nature of the Risk Oracle, LlamaRisk lacked a mechanism to simulate, detect, flag, or block failures under the existing architecture. Weeks earlier, our February analysis documented significant divergence in the Slope2 risk oracle’s behavior during a utilization spike, revealing gaps in methodology that had not been disclosed to Aave Labs or other service providers. These are not grievances. They are evidence of a structural gap: concentrated operational authority with no independent oversight.

Over the next period, our proposed model will gradually replace the single-provider black box with a transparent, dual-pipeline architecture in which CRE risk oracles, protocol-owned and fully visible to the Aave Protocol, operate alongside a Risk Steward co-signing layer. No update or shutdown can occur without the explicit consent of multiple stakeholders.

We propose a two-phase transition. First, immediate migration of Manual Risk Steward controls, with co-ownership alongside Aave Labs, ensuring that no parameter update proceeds without independent review. Second, a progressive transition of the Automated Risk Steward toward protocol-owned architecture based on CRE, moving from the current closed-source dependency to a transparent, verifiable system where the Aave Protocol retains full control. As an additional safeguard, we will deploy an independent observation layer that tracks every parameter update across all markets, with full transparency to the community.

The table below maps each departing function to our readiness:

Function LlamaRisk Readiness
Supply / Borrow cap automation Methodology-based via manual AGRS; then transitioning to CRE automation
Interest rate parameter management Full IRM coverage (Slope1, Slope2, Base, Uopt) via manual AGRS, then transitioning to CRE automation
Liquidation parameter calibration LT, LTV, LB, LP across all markets; dynamic models for RWAs
E-Mode configuration Active coverage, including Liquid E-Mode mechanics research
Oracle design & sanity checks CAPO, adaptive feeds (USDe, sUSDai, PT tokens), CRE-native risk oracles
Risk oracle infrastructure Protocol-owned CRE stack replaces closed-source dependency
New asset/chain evaluation Full technical + risk + legal evaluation
Risk Steward operations Proposing co-ownership
V4 risk architecture Hub & Spoke, credit lines, Reinvestment Controller, Umbrella
Umbrella coverage methodology Ratified methodology anchored to external market risk factors
Monitoring & alerting Real-time deviation tracking, oracle anomaly detection

On Aave V4

Chaos Labs raised valid concerns about V4’s expanded scope and the operational burden of running V3 and V4 simultaneously. We take those concerns seriously.

We have been allocating significant resources and contributing to V4’s architecture since its design phase. We have already published analyses of its Hub & Spoke model, credit line structure, and liquidation engine. V4 introduces new parameter categories that need active management: credit line and draw caps, per-user risk premiums, reinvestment controller limits, dynamic liquidation parameters, and others. We are prepared to scale and to undertake the active risk management role as Aave V4 enters the bootstrapping phase.

Our approach to V4 risk management is grounded in the same rigorous quantitative and qualitative research that underpins our V3 coverage, ensuring continuity of Aave’s risk management standard across both instances. The automated risk management capabilities will be built on the same infrastructure that powers LlamaGuard NAV: transparent, verifiable, and with no privileged access controls. Key parameters used in off-chain computation are made publicly auditable through on-chain registries. With these design principles, scalable risk management becomes an extension of Aave’s core capabilities rather than a delegation to a third party.

Our Renewed Commitment

Aave did not become the largest lending protocol in DeFi by relying on any single contributor. It did so by building redundancy into its governance and risk architecture. LlamaRisk’s commitment to Aave is unconditional and long-term. We are fully capable of covering all responsibilities previously handled by Chaos Labs, and we are confident we can surpass the value they delivered. We intend to support Aave in all its risk management needs fully.

We want to be straightforward with the community: absorbing the full scope of a departing risk provider while simultaneously scaling protocol-owned infrastructure for V4 and Horizon is a significant undertaking. It is not something that can happen at current resource levels. The scope of work outlined above, CRE risk oracle development and deployment, Automated Risk Steward migration, V4 parametrization, expanded monitoring, and full operational coverage across every Aave market, requires a substantially larger budget than our current engagement. We will need to scale the team with domain-specific and technical hires, invest in infrastructure, and retain the talent already dedicated to maintaining and improving Aave’s risk architecture day in and day out. We are already underway with this process, and will present a detailed renewal proposal with the specific resource requirements in the coming days.

We fully align with @AaveLabs’ leadership role and are committed to close coordination with the other service providers, @TokenLogic, and @Certora, to ensure seamless coverage across risk, governance, and security. We also commit to private coordination on all sensitive matters, improving operational efficiency through joint tooling, clear role boundaries, and standardized asset onboarding playbooks. We will continue to present a unified front to external parties. The model is already working on Horizon, which we intend to replicate across V3 and V4. We welcome the shift toward a leaner, more focused group of service providers sharing a common vision. The previous model, in which providers were siloed from one another, created friction and fragmented accountability. Aave’s next chapter benefits from tighter coordination, clearer ownership, and a unified sense of direction.

We remain committed to transparency. The community will continue to receive time-sensitive updates, governance analyses, and risk communications without delay. Our existing monitoring, analysis, and governance participation continues without interruption. We will publish a detailed transition plan covering the specific parameter domains we will cover, the infrastructure we will deploy, and the timeline for full operational coverage.

A smooth transition requires coordination. We will engage on the specifics of scope expansion as we formalize our proposal. We also encourage the community to consider what the right risk management structure looks like going forward. Aave’s risk track record is a collective achievement. We intend to protect it.

— The LlamaRisk Team

12 Likes

Update: Risk Council Transition

Following our April 7th statement, we want to update the community on the concrete steps we have taken to ensure the continuity of Aave’s risk management.

Multisig Ownership Transfer

Per our instructions and with the support of Aave Labs, @ChaosLabs, and @bgdlabs have gracefully transitioned ownership of the Risk Council multisigs. The signers are now:

  • @AaveLabs: 0x606dC57cd166643760E049609bfd1D8a698D3bAc
  • @LlamaRisk: 0xbA037E4746ff58c55dc8F27a328C428F258DDACb

With a threshold of 2/2.

The change was executed across Aave instances, as detailed below:

Network Status Transaction Hash
Arbitrum :white_check_mark: Transferred 0x8980…d28b
Avalanche :white_check_mark: Transferred 0x4ec5…35d8
Base :white_check_mark: Transferred 0xa6c2…ba86
BNB Chain :white_check_mark: Transferred 0xf398…3e3e
Celo :white_check_mark: Transferred 0xf4be…8055
Gnosis :white_check_mark: Transferred 0x4e1b…8ed8
Ink Not applicable (whitelabel instance)
Linea :white_check_mark: Transferred 0xd841…b8d8
Mainnet (Core, Prime, EtherFi) :white_check_mark: Transferred 0x24c5…bce2
Mantle :white_check_mark: Transferred 0x5a10…567c
MegaEth :white_check_mark: Transferred 0xa3ba…6bdd
Metis Not applicable (deprecated market)
Optimism :white_check_mark: Transferred 0x60c7…c3ec
Plasma :white_check_mark: Transferred 0x0e9e…a556
Polygon :white_check_mark: Transferred 0xfe8b…4747
Scroll :white_check_mark: Transferred 0x0805…906e
Soneium Not applicable (deprecated market)
Sonic :white_check_mark: Transferred 0x946c…d98c
X Layer :white_check_mark: Transferred 0xe945…4d9b
ZkSync :white_check_mark: Transferred 0x269f…ad70

Risk Oracle Discontinuation

We have confirmed that Chaos Labs has discontinued its Risk Oracles, with no updates published since April 8th. As a precautionary measure, we will prepare an ARFC to discontinue the on-chain access previously granted to their Risk Oracles.

Operational Continuity

We have already begun exercising the Risk Steward function. Our first update was increasing the supply cap for PT-sUSDE-18JUN2026 on the Plasma instance, which was urgently needed. We are preparing additional Risk Steward updates based on the parameter changes we have identified.

Functions previously handled via automated Risk Oracles will be managed manually through our quantitative methodology and monitoring infrastructure, using the established channels: Risk Steward, ARFC, and DAIP. This covers all departing automated functions, including CAPO snapshots and PT oracle parametrization, which we are actively addressing.

We have full monitoring in place, a comprehensive methodology covering all asset parameters, and we will submit parameter changes in a timely manner via the appropriate channel as conditions require.

Next Steps

We will keep the community updated on our progress toward CRE-based Risk Oracles, as outlined in our previous posts.

4 Likes

LlamaRisk’s 2/2 multisig with AaveLabs raises a centralization concern how will conflicts of interest between risk recommendations and protocol incentives be managed? What’s the escalation path if LlamaRisk and AaveLabs disagree on a critical parameter change…? @LlamaRisk

1 Like

Thank you for raising this question. To clarify, this setup does not change the operational assumptions:

  • The manual Risk Stewards control was within the same 2/2 Safe Multisig, with signing rights previously held by BGD Labs and Chaos Labs, as explained in this post by BGD Labs.
  • Aave Labs will serve as a technical & security review party, with LlamaRisk being the recommendations-maker.

We will continue to produce Risk Stewards parameter change reports on the governance forum to ensure full transparency about the decisions being taken.

3 Likes

Thank you @LlamaRisk-Risk-SP for the swift action on Risk Council transition and commitment to the continuity on Aave’s risk management. Your work is self-evident.