Increase SupplyCap stMATIC Polygon & wETH Arbitrum
01Summary
This AIP increases the stMATIC Supply Cap on Polygon v3 from 21M to 25M units (19% increase) and the wETH Supply Cap on Arbitrum v3 from 35,280 to 45,000 units, in response to high utilization rates (77.92% for stMATIC and 93.54% for wETH) to support yield aggregation products and meet market demand.
- Type
- parameter change
Key changes
- Increase stMATIC Supply Cap on Polygon v3 from 21,000,000 to 25,000,000 units(high)
- Increase wETH Supply Cap on Arbitrum v3 from 35,280 to 45,000 units(high)
Notable concerns
- stMATIC utilization already at 77.92% before increase
- wETH utilization already at 93.54% before increase
- previously approved wETH upgrade on Arbitrum was not executed before this proposal
Generated by Kvorum
02Description
Summary
This AIP increasing the stMATIC Supply Cap on Polygon from 21.0M to 25.0M units and the wETH Supply Cap on Arbitrum from 35,280 to 45,000 units.
Abstract
This AIP implements risk parameter changes to stMATIC Polgyon v3 adn wETH on Arbitrum v3.
The utilisation of the stMATIC reserve has reached 77.92% and this AIP will increase the SupplyCap by a further 19% to 25M units.
Utilisation of wETH Supply Cap on Arbitrum has reached 93.54% and this AIP will increase the Supply Cap from 35,280 to 45,000 units.
Motivation
Over the previous months, Llama has been working with various communities to craft favourable conditions on Aave v3 Polygon to facilitate the creation of several yield aggregation products. This has led to increase stMATIC deposits and the continual revision of Supply Caps enabling users to enter the yield maximising strategy.
This AIP is a continuation of LLama's efforts and presents the community the opportunity to enable stMATIC deposits to grow on Polygon v3.
Previously an AIP was submitted to increase the wETH Supply Cap on Arbitrum and although being approved, the upgrade was not executed. This AIP includes the Arbitum wETH Supply Cap upgrade in collaboration with Gauntlet.
The wETH Supply Cap is to be increased from 35,280 to 45,000 units on Arbitrum with no other changes being made.
Specification
The following risk parameters changes are presented:
Polygon
Ticker: stMATIC
Contract: 0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4
| Parameter | Current Value | Proposed Value |
|---|---|---|
| SupplyCap | 21,000,000M units | 25,000,000 units |
Arbitrum
Ticker: wETH
Contract: 0x82aF49447D8a07e3bd95BD0d56f35241523fBab1
| Parameter | Current Value | Proposed Value |
|---|---|---|
| SupplyCap | 35,280 units | 45,000 units |
Implementation
A list of relevant links like for this proposal:
- stMATIC Governance Forum Discussion
- wETH Governance Forum Discussion
- stMatic Test Cases
- stMatic Payload Implementation
- wETH Test Cases
- wETH Implementation
Risk Service providers have endorsed the contents of 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 where the top-level on-chain actions are generic execute(address) delegatecalls to per-chain 'payload' contracts, rather than directly encoding the parameter change (e.g., setSupplyCap). There are exactly two actions, matching the two changes described in the prose (Polygon stMATIC cap increase and Arbitrum wETH cap increase), and each targets a distinct executor address consistent with routing to different network governance modules. The description links to the specific payload source files (AaveV3PolCapsUpdates_20230418_Payload.sol and AaveV3ArbCapsUpdate_20230327.sol) that implement the exact cap values cited in the tables (25,000,000 and 45,000 units), which is the normal way Aave AIPs document parameter changes since the actual numeric parameters live inside the payload contract bytecode, not in the top-level calldata. Because the decoded calldata only shows the outer execute(address) wrapper and not the internal setSupplyCap calls, I cannot directly verify the exact numeric values (25M / 45,000) against calldata, so confidence is medium rather than high. However, the count, structure, and target routing of actions align cleanly with the two described changes, and there is no evidence of extra, missing, or misdirected actions. No value, target, or scope mismatches are apparent from the available data, so the overall assessment is consistent.
Generated by Kvorum
04Actions
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x26366920975b24A89CD991A495d0D70CB8E1BA1F" }- Calldata
- Target
- 0xd1b3…cfa3
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x4c68fDA91bfb4683eAB90017d9B76a99F2d77Eed" }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
- [ARFC] stMATIC Supply Cap Increase Polygon v3 ↗discourse · high confidence
Arguments for
- stMATIC utilization on Polygon v3 had reached 74.4%, justifying an increase to the Supply Cap to avoid constraining deposits.— Llamaxyz
- Raising the cap allows continued growth of the stMATIC/wMATIC recursive yield strategy and helps sustain wMATIC deposit demand and incentive programs from Lido and other communities.— Llamaxyz
- Chaos Labs explicitly supported the initially proposed increase to 25M units.— ChaosLabs
- Gauntlet's aggressive methodology also recommended a 25M unit cap, aligning with the proposal.— seawolf
- A community Snapshot vote established that Supply Caps could be set as high as 75% of an LST's circulating supply on the network, supporting a higher cap (37.5M) than originally proposed.— Llamaxyz
- Using on-chain liquidity or total circulating supply methodologies (rather than Polygon-only circulating supply), the cap could theoretically be raised much further (up to 40-42M units).— Llamaxyz
Arguments against
- Chaos Labs would not support raising the cap based on Ethereum-bridged stMATIC liquidity, since there is no evidence bridged liquidity is used by liquidators during market stress.— ChaosLabs
- Chaos Labs argued the cap should not exceed 50% of circulating supply because, unlike MaticX, stMATIC is primarily used as collateral to borrow stablecoins rather than the underlying MATIC asset, meaning counterparty and liquidity/concentration risk (not just price-correlation risk) must be prioritized, limiting how aggressive the cap can be even after the Snapshot vote allowing up to 75%.— ChaosLabs
- Gauntlet's conservative recommendation was only 10M units, far below the proposed 25M (and later 37.5M) figures, indicating a more cautious stance was available.— seawolf
Unresolved concerns
- How exactly E-Mode-specific supply caps would address the risk concern Chaos Labs raised, given that the flagged risky usage (borrowing stablecoins against stMATIC) occurs outside E-Mode, was not fully clarified.— sakulstra, ChaosLabs
- Disagreement over whether Ethereum (bridged) liquidity for stMATIC should factor into the Supply Cap calculation was not resolved, with Llamaxyz favoring its inclusion and Chaos Labs rejecting it.— Llamaxyz, ChaosLabs
- The gap between Gauntlet's conservative (10M) and aggressive (25M) recommendations, and which should guide the final cap, was not explicitly reconciled in the thread.— seawolf
Notable participants
- LlamaxyzProposer who authored the proposal, provided supporting data on utilization and inflows, and pushed for higher caps following the Snapshot vote.
- ChaosLabsRisk service provider who supported the initial 25M cap but repeatedly pushed back against further increases, citing liquidity, concentration, and counterparty risk concerns.
- seawolfProvided Gauntlet's conservative and aggressive supply cap recommendations for stMATIC.
- sakulstraBGD Labs contributor who questioned Chaos Labs' reasoning on E-Mode caps and risk framing, seeking clarification without taking a stance.
Generated by Kvorum
08Similar proposals
- aaveexecutedLST Supply Cap Increase Polygon & Arbitrum95%
- aaveexecutedPolygon Supply Cap Update91%
- aaveexecutedstMATIC SupplyCap Increase Polygon v390%
- aaveexecutedSupply Cap Update - stMATIC Polygon v387%
- aavedefeatedMaticX Supply Cap Increase Polygon v3 and AGD Approval87%
- aaveexecutedwMATIC Supply & Borrow Cap Increase Polygon v387%
- aaveexecutedMaticX Supply Cap Increase Polygon v387%
- aaveexecutedSupply Cap increase - wstETH86%
- aavedefeatedSupplyCapLSTs86%
- aaveexecutedIncrease wMATIC Supply Cap & BAL Borrow Cap86%