Aave Strategy Shift: Deprecating 75 Asset Reserves and Six Network Deployments
According to Incrypted, Aave’s risk management team has proposed winding down 75 low-activity asset reserves and gradually deprecating deployments across six networks.
Lucas Meade·updated August 06, 2026

Aave Proposed Deprecating 75 Asset Reserves and Six Network Deployments
The proposal covers assets with a combined supply of $98.1 million and open borrows of $15.6 million, making this less a routine listing cleanup than a change in the protocol’s operational risk surface. For developers and integrators, the immediate question is not which network is being removed, but whether their contracts still depend on markets that may soon become non-operational.
The bottleneck is maintenance, not nominal liquidity
Aave’s stated rationale is straightforward: every reserve carries ongoing infrastructure and risk-management costs. The proposal cites price-oracle support, monitoring of risk parameters, and maintenance of liquidation mechanisms as recurring obligations. When usage is too low, the cost of preserving that market is no longer justified.
The plan reportedly includes 50 low-adoption asset reserves across multiple deployments, plus another 25 reserves connected to the gradual wind-down of Aave markets on Sonic, Scroll, zkSync, Metis, Soneium, and Aptos. The available reporting identifies these networks as part of the proposal; it does not establish that all markets on each network will disappear at once.
Aave also plans to end support for 21 expired Pendle PT tokens and replace them with new series. That detail matters because integrations often treat reserve availability as a static property. In practice, tokenized yield products and lending markets have their own lifecycle, and an address that was valid for one series should not automatically be assumed to remain relevant for its successor.
What developers should verify now
The proposed wind-down mechanism is designed to give users time to exit. Affected reserves would be frozen, preventing new deposits and borrowing, while supply and borrowing caps would be reduced to the minimum level. For reserves with outstanding loans, the Reserve Factor would be raised to 99% to encourage liquidity withdrawal and debt repayment.
That sequence creates several concrete checks for protocol teams:
- Inventory every Aave reserve address used by lending adapters, yield strategies, liquidation bots, dashboards, and monitoring systems.
- Separate “deployment exists” from “market remains usable.” A contract may continue to resolve an address even after deposits and borrowing are disabled.
- Review assumptions around supply caps, borrow caps, reserve factors, and frozen-market behavior.
- Confirm how the integration handles a reserve with debt outstanding but no practical path for opening new positions.
- Treat the 21 expired Pendle PT tokens as a separate migration surface rather than assuming that replacement series preserve the same identifiers or risk profile.
This is the kind of change that can expose a hidden coupling in otherwise production-ready systems. A strategy may not borrow directly from an affected market, yet still depend on its oracle, liquidity path, liquidation route, or accounting data. The correct response is therefore an address-and-parameter audit, not merely a check of whether a front end still displays the asset.
A narrower deployment matrix may be the safer one
Aave’s proposal reflects a familiar trade-off in multi-network lending: broad deployment increases reach, but it also multiplies the number of reserves, oracles, liquidation paths, and parameter sets that must be maintained. Conversely, a smaller deployment matrix can reduce operational overhead and concentrate liquidity, although the evidence available here does not quantify how that would affect individual networks or users.
For L2 teams and application developers, the practical signal is that deployment breadth should not be treated as a permanent commitment. Each additional chain introduces another dependency surface, and low activity can eventually turn that surface into a liability rather than an advantage. The same utilization-versus-maintenance question appears in other infrastructure domains, including how bidirectional charging turns an electric vehicle into a grid-scale power asset.
The recommendation is conservative: treat the Aave changes as a pending dependency event, identify affected reserves and network-specific assumptions, and prepare an orderly migration path before any freeze or cap reduction is enacted. Aave says it will continue reviewing assets and deployments under updated risk-management and listing frameworks. For integrators, that means reserve support should be modeled as a changeable protocol condition—not a hardcoded guarantee.