Aave risk stewards published a new set of supply and borrow cap adjustments on April 24, 2026, across multiple V3 markets. The timing is notable because it lands in the same post-rsETH stress window that already has the lending ecosystem reassessing what counts as durable collateral and usable inventory.
Radar reads this as protocol-ops news. Cap changes do not just tweak risk parameters in the background. They reshape where liquidity can still expand, where borrowing effectively stops, and which assets move onto a clear deprecation track.
What Happened
In the official governance thread, Aave risk stewards proposed broad cap reductions and explicitly listed some assets moving to borrow caps of 1 where proven borrow usage was missing. The same post also showed supply caps set to 1 for several deprecation-track reserves.
The table is wide, covering multiple chains and asset types rather than a single isolated market. Stablecoin reserves were cut more selectively, while several higher-risk or lower-conviction exposures were tightened far more aggressively.
Why It Matters
For protocol discovery, that matters because cap policy changes where demand can still gather. A market with a borrow cap at 1 is no longer just less attractive. It is effectively telling users and integrators that the route is being frozen out as a meaningful liquidity surface. A reserve with a supply cap at 1 sends an even louder message about future relevance.
That is useful context for anyone comparing lending ecosystems, collateral routes, or chain-level depth. Post-stress recovery is not only about which protocols survive. It is about where usable distribution and borrowable inventory still exist after the cleanup starts.
What To Watch Next
Watch which chains and assets still retain room after the cap reductions settle. The survivors often become the real liquidity map, not just the old TVL leaderboard.
Also watch follow-on governance threads. When a protocol starts using cap policy to separate durable routes from soft-frozen ones, the next discovery edge often comes from tracking where the constraints migrate next.
