wMATIC Supply & Borrow Cap Increase Polygon v3
01Summary
Proposal to increase wMATIC Supply Cap from 66M to 90M units and Borrow Cap from 39.95M to 50M units on Aave v3 Polygon to accommodate growth from Balancer integration and v2 migration, with post-implementation utilization expected at 73.33% for supply and 62.5% for borrowing.
- Type
- parameter change
Key changes
- Increase wMATIC Supply Cap from 66M to 90M units (24M unit increase)(high)
- Increase wMATIC Borrow Cap from 39.95M to 50M units (25% increase)(high)
Notable concerns
- Supply Cap currently at 100% utilization preventing new deposits
- Strong demand for wMATIC borrowing due to subsidized borrowing costs may continue to pressure caps
Generated by Kvorum
02Description
Summary
This AIP proposes increasing the wMATIC Supply and Borrow Cap on Polygon v3.
Abstract
With strong deposit flows from the Balancer bb-a-wMATIC integration and the continual growth of the yield maximising strategy, the Supply and Borrow Cap of wMATIC are both experiencing strong utilisation.
This AIP enables the continued growth of wMATIC deposits as Balancer Liquidity Providers migrate to the new gauges and users continue to migrate from Aave v2 to v3. As wMATIC deposits grow so does the demand for borrowing wMATIC. Subsidised borrowing costs has lead to significant demand for wMATIC and TVL growth for Aave.
Increasing the Supply and Borrow Caps as outlined will continue to users of yield maximising strategies.
Motivation
With several Balancer liquidity pools depositing wMATIC into Aave v3 on Polygon, the utilisation of the Supply Cap has increased to 100%. This is currently preventing the Balancer linear pools from depositing into the wMATIC reserve.
Currently, there is around 5,294,939 and 1,228,487 units of wMATIC not yet migrated to the new gauges. The wMATIC Supply Cap is at 100% utilisation.
There is also 15.13M units of wMATIC on Aave v2 that has not yet migrated to v3.
Collectively, this represents around 21.65M units of wMATIC relative to a Supply Cap. This AIP intends to provide sufficent capacity for the 21.65M units to be deposited into the wMATIC reserve by increasing the Supply Cap from 66M units to 90M units, a 24M unit increase. The utilisation of the pool will be 73.33% after the Supply Cap is implemented.
With many teams are offering yield maximising strategies, there is continued strong demand for borrowing wMATIC. The current Borrow Cap has reached 74.50% utilisation. The newly proposed Borrow Cap 50M units is equivalent to 25% increase and represents 62.5% of the Supply Cap.
With reference to the new ARFC Aave V3 Caps update Framework it is possible to ship several upgrades to gradually increasing Aave's exposure to wMATIC over time.
Specification
The following risk parameters have been proposed by Llama and Chaos Labs has expressed support on the governance forum.
Ticker: wMATIC
Contract: polygon: 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270
| Parameter | Current Value | Proposed Value |
|---|---|---|
| SupplyCap | 66.00M units | 90M units |
| BorrowCap | 39.95M units | 50M units |
Implementation
A list of relevant links like for this proposal:
The proposal Payload was reviewed by Bored Ghost Developing.
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows the standard Aave governance pattern: a single top-level action that calls execute(address) on a cross-chain executor, delegating to a separately deployed payload contract (address matches the naming convention referenced in the 'Implementation' section, e.g. AaveV3PolCapsUpdates_20230518_Payload). The decoded calldata for this top-level action does not expose the actual parameter-setting logic (setSupplyCap/setBorrowCap calls) because that logic lives inside the target payload contract's own bytecode, which is not part of the provided decoded action. This is routine and expected for Aave AIPs, and the description's narrative (increasing wMATIC Supply Cap to 90M and Borrow Cap to 50M) is consistent with the referenced payload/test files and forum discussion links provided in the Implementation section. Because the decoded calldata only shows a generic 'execute(address)' delegation rather than the underlying setCap calls, I cannot directly verify the numeric values (66M->90M, 39.95M->50M) against on-chain calldata - hence confidence is low. However, there is no evidence of a mismatch: no target_mismatch, no extra or omitted actions, and no numeric conflict is observable given the available decoded data. I found no basis for flagging a discrepancy, so overall_assessment is consistent, but confidence is capped at low due to inability to verify specifics from the calldata alone.
Generated by Kvorum
04Actions
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0xeB06d30b4bb21CA98279B74fd2325b8f2759aA50" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 320x329c…3ed4 | For | 231.2K | 0.00% | — | 4y ago |
| 070x0703…961b | For | 108.5K | 0.00% | — | 4y ago |
| 620x62a4…816a | For | 82.4K | 0.00% | — | 4y ago |
| 130x13bd…8548 | For | 81.4K | 0.00% | — | 4y ago |
| B80xb83b…cf5c | For | 81K | 0.00% | — | 4y ago |
| B90xb933…8dd1 | For | 41.7K | 0.00% | — | 4y ago |
| 180x1855…98ba | For | 3K | 0.00% | — | 4y ago |
| A00xa06c…61f7 | For | 753 | 0.00% | — | 4y ago |
| EA0xea17…6676 | For | 39.6 | 0.00% | — | 4y ago |
| BF0xbf78…10cc | For | 2.4 | 0.00% | — | 4y ago |
| E40xe459…e666 | For | 0.5 | 0.00% | — | 4y ago |
| 420x4229…9006 | For | 0.3 | 0.00% | — | 4y ago |
| 6E0x6efd…67e2 | For | 0 | 0.00% | — | 4y ago |
07Forum
- [ARFC] Aave V3 Caps update Framework ↗discourse · high confidence
- [ARFC] wMATIC Supply & Borrow Cap Increase Polygon v3 ↗discourse · medium confidence
Arguments for
- A direct-to-AIP process for cap changes/FreezeReserve reduces governance delay and helps the protocol adapt quickly to market conditions.— MarcZeller
- Introducing 'Risk Steward' smart contracts controlled by a 2-of-2 Gauntlet/Chaos Labs multisig would automate routine cap updates and cut voting overhead while speeding execution.— bgdlabs, MarcZeller, dtalwar, ChaosLabs, fig
- Historical data shows cap-update proposals have been near-unanimously supported by the community, justifying automation of these routine decisions.— bgdlabs
- Aave governance retains full sovereignty and can revoke Risk Steward permissions at any time, preserving ultimate DAO control.— bgdlabs, MarcZeller
- A leaner, simpler governance structure for routine risk-parameter changes aligns with Aave's broader governance philosophy and improves efficiency.— fig
Arguments against
None surfaced.
Unresolved concerns
- Decreasing supply/borrow caps could in some cases effectively freeze a reserve, and the community's view on allowing this outcome was not settled in the thread.— ChaosLabs
- Whether the Risk Steward multisig should be expanded beyond Gauntlet and Chaos Labs to include entities like ACI, Llama, or governance coordinators remained an open question, with MarcZeller preferring to wait until the pilot matures.— fig, MarcZeller
- The long-term solution of an elected Risk Council with broader risk-management authority was acknowledged as technically possible but still immature, leaving the Risk Steward as only a temporary measure.— MarcZeller
Notable participants
- MarcZellerOriginal proposer of the Caps Update Framework and vocal supporter of the subsequent Risk Steward proposal, responding to community suggestions.
- bgdlabsProposed the Risk Steward smart contract mechanism to automate cap changes via a Gauntlet/Chaos Labs multisig.
- dtalwarRepresented Gauntlet, expressing support for reducing governance overhead through automation.
- ChaosLabsRepresented Chaos Labs, supporting the proposal while flagging a concern about cap decreases effectively freezing reserves.
- figRepresented Flipside, endorsing the leaner governance approach and suggesting future expansion of the multisig.
- Kene_AnodeAgreed to incorporate the new framework into the broader Aave governance process documentation.
Generated by Kvorum
08Similar proposals
- aaveexecutedIncrease wMATIC Supply Cap & BAL Borrow Cap94%
- aaveexecutedMaticX Supply Cap Increase Polygon v390%
- aaveexecutedMaticX Polygon Supply Cap Update88%
- aavedefeatedMaticX Polygon Supply Cap Update88%
- aavedefeatedMaticX Supply Cap Increase Polygon v3 and AGD Approval88%
- aaveexecutedPolygon Supply Cap Update88%
- aaveexecutedMaticX Supply Cap Increase Polygon v387%
- aavecanceledMaticX Supply Cap Increase Polygon v387%
- aaveexecutedIncrease SupplyCap stMATIC Polygon & wETH Arbitrum87%
- aaveexecutedLST Supply Cap Increase Polygon & Arbitrum86%