[TEMP CHECK] Automated Supply Cap Updater – Restricting Short-Term Supply Increases in Aave V3

Governance General
1

Author: @gnarvaja

Date: 2026-04-21

Simple Summary

I propose an external Automated Supply Cap Updater contract (with the RISK_ADMIN role) that automatically keeps supply caps tight by allowing only small short-term increases (e.g. ~3% headroom). It gradually raises the on-chain cap when utilization is high, while never exceeding the absolute governance-set cap. This can be implemented immediately with no changes to the Aave V3 core contracts. The aim is to reduce the impact of hacks like the rsETH incident, with minimal effect on normal usage. Parameters are fully governed and a Security Council can pause it if needed.

Introduction

The rsETH incident on April 18th highlighted a weakness in how supply caps currently operate in Aave V3. Even with reasonable caps set by governance and Risk Stewards, a large gap between the on-chain total supply and the supply cap allowed an attacker to deposit a significant amount of newly-minted tokens as collateral in a short time window and borrow against them.

To address this, I propose an external Automated Supply Cap Updater contract that holds the RISK_ADMIN role. This solution can be applied immediately without any changes to the Aave V3 core contracts. The contract would keep the effective supply cap very close to the current supply by automatically increasing it in small, controlled steps when supply rises, while never exceeding the absolute maximum cap defined by governance or Risk Stewards. The goal is to strictly limit how much supply can increase in a short period (e.g., ~3% headroom), making it much harder for similar exploits to have a large impact.

How the Cap-Updater would work (high-level)

The contract would monitor each reserve and, when the supply ratio exceeds a configurable threshold (for example, 97%), automatically increase the on-chain supply cap enough to restore a small headroom (e.g., 3%). Increases would be limited to a configurable frequency (default: once per hour). The updater would always respect the absolute governance-set cap as a hard upper bound.

Key benefits:

  • Significantly reduces the impact of hacks or malicious minting exploits by restricting short-term supply surges.

  • Almost no friction for legitimate users — normal organic growth is easily accommodated with hourly small increases.

  • Fully automatic under normal conditions, with no need for manual intervention.

  • Zero changes required to the Aave V3 core protocol.

A Security Council (using a 1/N multisig setup) could pause the updater immediately if needed. Reactivation would require a higher threshold, but can be delegated to the same council. The same entities currently responsible for risk parameters (Risk Stewards + Governance) would control all updater settings.

Proposed per-reserve parameters (all configurable via governance)

  • Absolute Supply Cap — the current governance/Risk Steward value (hard upper bound the updater can never exceed).

  • Target Supply Ratio — e.g. 97% (the ratio the updater aims to maintain).

  • Max Supply Ratio — e.g. 98%. Threshold above which the updater increases the cap, to match the target supply ratio.

  • Min Supply Ratio — e.g. 95%, threshold below which the updater decreases the cap to keep headroom tight.

  • Update Period — default 1 hour (minimum time between updates for the same reserve).

This can be implemented quickly as a standalone external contract granted the RISK_ADMIN role. It is fully reversible and can start with a limited set of reserves.

I’m open to all feedback, suggestions, and improvements from the community. I’m also available to draft a reference implementation of the contract if that helps clarify the design.

Looking forward to your thoughts!

1 Like
2

Hello,

if you want to create a proposal please follow the official guidelines and in this case start with a TEMP CHECK. There are plenty examples you can look at and copy, of checked the pinned messages here Categories - Aave
Thank you

1 Like
3

Just to illustrate with numbers what would have happened with the rsETH incident if this had been in place with 3% of headroom:

  • Core: 15K rsETH supplied instead of 53.8K
  • Arbitrum: 715 rsETH supplied instead of 36K
4

This is a strong proposal to post-rsETH incident, and it addresses a fundamental gap in how lending protocols manage risk.

The core issue that I’m seeing is that supply caps are set by governance (slow, discrete), but risk accumulates continuously (fast, fluid). Static caps calibrated for steady-state conditions leave a gap between current supply and the cap ceiling — and that gap is what attackers exploit. They don’t need steady-state access; they need burst access. The supply cap updater closes that gap by making the effective cap dynamic — always tight to current supply, expanding only as fast as legitimate growth requires.

3% headroom would have reduced Core exposure from 53.8K to 15K ETH and Arbitrum from 36K to 715 ETH. That’s a 72% and 98% reduction in concentrated collateral risk, respectively. That’s effectively the difference between a manageable bad debt event and the $290M+ liquidation cascade that actually happened.

What I particularly like is that the design preserves governance sovereignty. The contract can only tighten caps or raise them within bounds — it can never exceed the governance-set maximum. The Security Council retains a kill switch. This is the right separation of concerns: governance sets policy, automation executes within policy bounds.

Two design considerations worth stress-testing:

1. Reserve-specific parameterization. A 3% headroom on WETH (deep liquidity, battle-tested oracle) is a different risk proposition than 3% on any newer LST/LRT with thinner liquidity and more infrastructure dependencies. Higher-risk collateral types should have tighter headroom — possibly 1–2%.

2. Adversarial feedback loops. What happens when the automated tightener interacts with other automated systems? If bots deposit to fill caps that auto-expand, you get a feedback loop. The hourly cadence limits this, but simulation data on adversarial deposit patterns would be valuable before moving to AIP.

Strong support. Aave’s risk management moving from reactive governance votes to proactive automated bounds is a maturity milestone for the protocol.

-– Robby Greenfield | tokedex.org

1 Like