On Nov. 11, LlamaRisk proposed a borrowing speed limit for lending protocol Aave V3, aiming to slow large borrowing bursts and give its emergency guardian more time to respond to suspected attacks.
The risk adviser’s governance proposal, named LlamaGuard Caps, would maintain a limited buffer of borrowing capacity above each reserve’s outstanding debt and replenish it after a delay. The proposal is an ARFC at the discussion stage, not an approved or live change.
A reserve is a token pool within an Aave market. Aave’s existing borrow caps limit how much of a token can be borrowed from a reserve in total. LlamaRisk’s proposal addresses a different risk: unused capacity under a static cap can be taken up immediately, including by an attacker borrowing against compromised collateral. The limiter would restrict the pace of borrowing without determining whether individual borrowers are legitimate.
The indicative settings call for a buffer equal to 10% of a reserve’s debt, with a floor of $1 million and a ceiling of $25 million. These are calibration assumptions, not final settings. LlamaRisk said values would be tailored to each market and reserve before deployment.
A Raise agent would replenish the buffer after available room falls to 20% or less of the buffer and a 30-minute delay has elapsed. Under the indicative settings, top-ups could happen no more often than once per interval. A borrower seeking more than the available room would have to wait, split the loan or use a dedicated route for large borrowers.
A Cut agent would remove excess room restored by repayments or liquidations. Under the indicative settings, headroom above 110% of the buffer would prompt a cut within one or two blocks. Smaller repayments would leave the room available to borrow again.
Cap increases would be calculated through Chainlink’s Runtime Environment, a system for running workflows across an oracle network. Onchain checks would enforce the buffer, hard maximum and timing limits. Cuts would be calculated directly from live Aave state. Governance and Risk Stewards would keep control of the hard maximum, while automation would manage the room below it.
A Separate Route for Large Borrowers
The trade-off is that legitimate large borrowers could also face delays. LlamaRisk proposes a batch executed by stewards for known large borrowers, including integrated institutional clients: the cap would increase by the exact loan amount, and the borrower would use that room in the same transaction. This would avoid leaving the added capacity open to everyone.
A Risk Council Safe made up of Aave Labs and LlamaRisk would run batches for large borrowers. The proposal does not specify formal eligibility criteria for this route. Stewards could also temporarily maintain a higher cap for onboarding or sustained demand, but during that period the added room would be available to any borrower.
At this stage, flash loans repaid in the same transaction and supply-cap settings would remain unchanged. The proposal also says Aave’s core contracts would not be changed.
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 but would not prevent or fully contain exploits.
LlamaRisk said the first-stage code had entered audits. Next comes community feedback, followed by a Snapshot vote if consensus emerges, and then an onchain governance vote if the Snapshot vote passes.
Add A Comment
Comments are closed.