Aave Reveals Four-Layer Risk Framework After Kelp Exploit

Aave governance is currently weighing a protocol-wide risk framework that would apply to every asset on its platforms: Aave V3, V4, and Aave Horizon. The proposal was posted Tuesday by risk service provider LlamaRisk on the Aave governance forum.

Aave founder Stani Kulechov made it clear that this isn’t just about setting new rules. “Assets that do not qualify for the new standard will be off-boarded from Aave over the coming weeks,” he wrote on X. This is Aave’s first concrete structural governance response to the KelpDAO LayerZero exploit that happened back in April.

What Happened in April

You might recall that attackers drained 116,500 rsETH tokens in April. They then deposited these stolen tokens as collateral across Aave’s Ethereum and Arbitrum markets and borrowed $193 million directly from the protocol. According to LlamaRisk’s incident report from April 20, the total attacker-posted collateral reached $221.39 million. A LayerZero report in May found that the bridge had been downgraded from a more secure 2-of-2 configuration to a vulnerable 1-of-1 multi-signature setup before the exploit happened.

The Four Layers of Protection

The new framework has four distinct layers that will govern asset onboarding, quarterly due diligence refreshes, and every subsequent parameter decision.

Layer 1 covers Asset Risk. This requires audit coverage, active bug bounty programs, sufficient liquidation liquidity, timely timelocks, and operational disclosure from issuers. If a bug bounty program is missing or weak, or if signer composition isn’t disclosed, that’s a hard block. For already-listed assets, it triggers an immediate exposure-tier review.

Layer 2 addresses Bridging Risk specifically. It sets a minimum standard for verifier thresholds on any asset that crosses chains. If an asset’s bridge configuration falls short, it gets a tightened exposure tier with lower loan-to-value ratios and lower supply caps until the issue is fixed. The rsETH exploit ran through exactly this vulnerability: the Unichain-to-Ethereum route was configured as a 1-of-1 multi-signature setup, which let a forged packet release 116,500 rsETH without any corresponding burn on the source side.

Layer 3 makes monitoring and automated risk oracle systems mandatory protocol infrastructure, not optional tools. Layer 4 handles Chain Risk entirely, establishing criteria that will determine whether Aave deploys on a chain at all. It also sets a permanent upper bound on the exposure tier for every asset listed on that chain.

Each recommendation generated by this framework must be implemented within one month. If not, those recommendations automatically convert into hard constraints on the asset’s exposure tier. I think this time pressure could make a real difference in how quickly issues get addressed.

The Pendle PT Oracle Changes

A companion proposal focuses on the Pendel PT risk oracle. The current arrangement has risk managers holding write authority over key oracle parameters with limited on-chain auditability. The new structure would migrate this to protocol-owned infrastructure on the Chainlink Runtime Environment, known as CRE.

Under the proposed system, Aave Governance would own every contract along the path. LlamaRisk would hold only an Updater role on a new on-chain ParameterRegistry, allowing them to adjust methodology parameters without a full CRE redeploy. LlamaRisk has been running the PT oracle manually since Chaos Labs stepped down from risk management in April. The governance post calls that arrangement “a transitional path that was never meant to be permanent.”

Three Chainlink CRE workflows will replace this manual process. They will compute smoothed implied rates, discount rates, and per-E-Mode liquidation parameters for each Pendle PT market. Each workflow publishes signed reports that a new on-chain router validates. Every parameter change will be recorded on-chain and independently verifiable.

Certora audits will cover both the new contracts and the CRE workflow code. Two of the three new contracts were already audited by two security teams as part of an earlier deployment. The router is the only component without prior audit coverage.

What Comes Next

Tuesday’s proposals follow two earlier milestones in Aave’s recovery from the April exploit. In May, Aave restored loan-to-value ratios for certain assets across several networks. Both proposals are now in the community feedback stage. If they reach consensus, each would move to a Snapshot vote before advancing to an on-chain vote.

The timing seems right. Aave needs to show it can react decisively to security incidents, and this framework could set a new standard for how DeFi protocols handle risk management across multiple chains and asset types.

The post Aave Reveals Four-Layer Risk Framework After Kelp Exploit appeared first on TheCryptoUpdates.