LlamaRisk published an Aave Request for Comments on 11 November 2026 proposing an automated rate limiter for borrowing across Aave V3 markets. Called LlamaGuard Caps, the first stage would keep each reserve’s borrow cap close to current debt and release additional capacity in timed increments rather than leaving large amounts of headroom continuously available.

The proposal is not an approved or deployed change. Its next steps are community feedback, a Snapshot vote if consensus forms, and then an Aave Improvement Proposal if Snapshot passes. The four new contracts and the Chainlink Compute Runtime Environment raise workflow have entered audits, according to the proposal; audit results and deployment details have not yet been published.

What the proposed rate limiter would do

Aave currently uses static borrow caps that governance or Risk Stewards revise. Those caps limit total debt but can leave unused borrowing room available at once. The proposed system would instead target a cap equal to current debt plus a reserve-specific buffer, while still respecting the existing hard maximum and supply cap.

Two agents would act on that cap. A Raise agent would restore borrowing room after most of the buffer has been used and a delay has elapsed. A Cut agent would remove excess room after repayments or liquidations create more headroom than the reserve needs. The proposal says raises would be computed through Chainlink CRE and checked onchain, while cuts would be calculated from live Aave state.

Under the indicative example, the buffer equals 10% of debt, subject to a $1 million floor and a $25 million ceiling. A top-up would become due when free headroom falls to 20% of the buffer, with a 30-minute minimum interval between raises. A 10% band would allow small repayments without triggering an immediate cap cut. These values are illustrations, not final market settings; the proposer says each reserve would be calibrated separately before deployment.

Large borrowers would have separate pathways

A timed refill can slow legitimate institutional borrowing as well as a malicious draw. LlamaRisk therefore proposes three pathways for transactions larger than the normal buffer. A borrower could split demand across scheduled top-ups; known large borrowers could use an atomic batch in which Risk Stewards raise the cap by the exact amount consumed in the same transaction; or the Risk Stewards could place a limited-duration hold on cuts during a genuine period of sustained demand.

Those exceptions are material governance controls. The proposed Risk Council Safe, held by Aave Labs and LlamaRisk, would tune parameters within governance-set limits, schedule holds and run large-borrower batches. The Protocol Guardian would administer the agents and could disable them. Governance would retain the ability to set hard maximums and retire an asset from the automated system.

Flash loans repaid within the same transaction would not count against the borrow cap. Supply caps and deposits would remain unchanged in the first stage. Later stages could extend the design to supply caps, Aave V4 and cross-market modules, but those additions are future proposals rather than part of the initial deployment.

Historical replay shows protection and friction

The proposal reports a minute-by-minute replay of Aave V3 activity from 15 October 2025 through 15 October 2026. Under its indicative parameters, it says Core WETH, USDT and USDC would have operated with average open headroom below 1% of debt, compared with reported averages of 41.1%, 75.3% and 76.7% under current static caps.

That reduction comes with borrower delays. The replay estimates at least one Core USDT borrower would have waited during 217 hours of the year, with 162 hours for Core WETH and 137 for Core USDC. The proposer argues that dedicated large-borrower pathways could absorb part of this friction, but the simulation does not establish how those pathways would behave under live operational demand.

For selected malicious draws, the same model would have slowed rather than stopped borrowing. A reported $123 million Core WETH draw associated with rsETH would have admitted $25 million within 30 minutes and $50 million within an hour, according to the proposal’s replay. A $44.6 million Core WETH draw linked by the proposer to the October Binance incident would have admitted $25 million within 30 minutes and the full amount after one top-up. These are retrospective model results, not evidence that the proposed contracts would have prevented either incident.

Limits remain before any deployment

The proposal adds four contracts, a CRE workflow and a keeper around Aave’s existing Risk Agents stack. It says Aave core contracts, AgentHub, RiskOracle and Router code would remain unchanged. Raises would still have to remain within one buffer above live debt, below the governance-set hard maximum and below the supply cap. A freeze or pause would take precedence over a raise, while cuts could continue during a freeze or pause.

The design cannot identify whether a borrower is malicious and does not prevent an exploit, oracle failure, depeg or governance attack. It limits the pace at which debt can grow. The proposal also notes that an automated raise could undo a manual cap decrease unless the hard maximum is lowered too, while a cut could reverse a manual increase unless a hold is active. Those interactions make audit findings, parameter authority and operational procedures central to the eventual risk assessment.

NetNapz assessment: separate the design from approval and performance

NetNapz assessment: LlamaGuard Caps is a material attempt to turn borrow caps from a static exposure ceiling into a speed limit on liquidity outflows. Its potential value lies in buying response time without requiring an automated system to diagnose an attack. Its trade-off is measurable friction for ordinary large borrowers and more operational authority for designated risk actors.

The next evidence points are clear: published audit results, final reserve-level parameters, a successful Snapshot, an AIP payload, execution records and live performance after deployment. Until those exist, the proposal should be treated as a governance design under review. It does not show that Aave V3 borrowing has already changed, that any incident would be fully contained, or that AAVE token holders receive a new ownership or income right.

Verification scope: this report uses the dated Aave governance post, its disclosed replay methodology and Aave’s official brand guidance. NetNapz did not independently reproduce the proposer’s simulations or verify unreported audit findings.