LlamaRisk Proposes Borrowing Speed Limits for Aave V3 Reserves

Risk adviser LlamaRisk filed a governance proposal on Nov. 11 to add borrowing speed limits to lending protocol Aave V3, aiming to slow large borrowing bursts and give Aave's emergency guardian more time to respond to suspected attacks.

The proposal, called LlamaGuard Caps, sits at the ARFC discussion stage — it is not an approved or live change. It would keep a limited buffer of borrowing room above each reserve's outstanding debt and replenish that buffer only after a delay.

The mechanism addresses a gap in Aave's existing defenses. Aave already sets borrow caps that limit how much of a token can be drawn from a reserve, but spare capacity under a static cap can be consumed instantly — including by an attacker borrowing against compromised collateral. LlamaRisk's limiter would constrain the pace of that drawdown without judging whether each individual borrower is legitimate.

What are the indicative settings?

The proposal's calibration assumptions, not final parameters, include:

• A buffer equal to 10% of a reserve's outstanding debt
• A $1 million floor and a $25 million ceiling on that buffer
• Buffer restoration once available room falls to 20% or less of the buffer, after a 30-minute delay
• Top-ups no more frequent than that 30-minute interval

LlamaRisk said values would be tailored to each market and reserve before deployment. A borrower exceeding available room would need to wait, split the loan, or use a dedicated large-borrower route.

A Cut agent would remove excess room reopened by repayments or liquidations. Headroom exceeding 110% of the buffer would trigger a cut within one or two blocks; smaller repayments would leave room open to borrow again.

How would the system run?

Cap increases would be computed through Chainlink's Runtime Environment, a system for running workflows across an oracle network. Onchain checks would enforce the buffer, the hard maximum, and timing limits. Cuts would be computed directly from live Aave state.

Governance and Risk Stewards would keep control of the hard maximum; automation would manage the room below it. The Protocol Guardian could disable either agent, and a freeze or pause would take precedence over cap increases.

LlamaRisk cautioned that rate limits would slow liquidity outflows rather than prevent or fully contain exploits — a throttle, not a firewall.

What happens to legitimate large borrowers?

The trade-off is that honest large borrowers could also face delays. LlamaRisk proposes a steward-executed batch for known large borrowers, including integrated institutional clients: the cap would rise by the exact loan amount, and the borrower would consume that room in the same transaction. That design avoids leaving the extra capacity open to everyone.

A Risk Council Safe comprising Aave Labs and LlamaRisk would run large-borrower batches. The proposal does not define formal eligibility criteria for the route. Stewards could also temporarily hold a higher cap for onboarding or sustained demand, though the extra room would remain available to any borrower during the hold.

Flash loans repaid in the same transaction and supply-cap settings would stay unchanged at this stage. Aave's core contracts would also remain untouched, per the proposal.

LlamaRisk said first-stage code has entered audits. The path forward runs through community feedback, then a Snapshot vote if consensus emerges, then an onchain governance vote if Snapshot passes.