MaticX Supply Cap Increase Polygon v3 and AGD Approval
01Summary
Proposal to increase MaticX Supply Cap on Polygon v3 from 17.2M to 29.3M units to support yield aggregation strategies and continued SD reward distribution by Stader Labs. Also corrects a previous error in the Aave Grants DAO aUSDT allowance by setting v1 aUSDT allowance to zero and properly setting v2 aUSDT allowance to $812,944.90.
- Type
- parameter change
- Funding
- $812944.90
Key changes
- Increase MaticX Supply Cap on Polygon v3 from 17.2M units to 29.3M units (70% increase)(high)
- Correct Aave Grants DAO aUSDT allowance by setting v1 aUSDT to zero and properly configuring v2 aUSDT allowance to $812,944.90(high)
Notable concerns
- Increased counterparty risk concentration with MaticX exposure rising to 75% of circulating supply on Polygon network
- Current supply cap utilization at 94% indicates high demand but limited capacity
- Dependence on continued SD reward distribution from Stader Labs to justify the increased capacity
Generated by Kvorum
02Description
Summary
This publication proposes increasing the MaticX Supply Cap on Polygon v3 from 17.2M units to 29.3M units. It also corrects the Aave Grants DAO aUSDT allowance that was incorrectly set previously.
Abstract
After a vote for increasing the communities counter party risk was passed on Snapshot, the Supply Cap for MaticX can be increased from 50% to 75% of circulating supply.
The dominant use case for MaticX on Aave Protocol is as collateral to borrow wMATIC. Since the MaticX oracle, a calculated price feed provided by Chainlink based upon the underlying asset's (MATIC) price, the risk of liquidation is minimal. As a result, the primary risk of increasing aave Protocol's exposure to MaticX is the assocaited counterparty risk which is expressed as concentration risk with up to 75% of supply on the Polygon network.
The current Supply Cap's utilisation is hovering around 94%, with 1.03M units of MaticX deposit capacity. Stader Labs is currently offering SD rewards to user who deposit MaticX. This proposal seeks to encourage Stader Labs to continue distributing SD rewards by increasing the Supply Cap and enabling more MaticX to be deposited into Aave.
Motivation
Over the previous months, Llama has been working with various communities to craft favourable conditions conducive to growing TVL and Revenue by facilitate the creation of several yield aggregation products.
With liquidity mining ongoing, MaticX deposit rewards (SD) and wMATIC borrowing rewards (stMATIC & MaticX), ensuring there is adequate capacity enabling the yield maximising strategies to grow is key for Aave Protcol's abililty to generate wMATIC revenue. Several liquidity pools on Balancer v2 now include bb-a-wMATIC with over 14.5M units of wMATIC being deposited in Aave Protocol. This has lead to reduced borrowing rates for wMATIC and supports the continued growth of yield maximising strategies on Aave Protocol.
To facilitate the continued growth of the MaticX reserve, the Supply Cap needs to be raised enabling more deposits into the reserve.
With reference to the new ARFC Aave V3 Caps update Framework the preferred path forward is to implement several upgrades to gradually increase Aave's MaticX exposure over time.
This proposal will increase the Supply Cap from 17.2M units to 29.3M units. Feedback from Chaos Labs and Gauntlet can be found here. The two appllicable Snapshot votes can be founds here and here.
Specification
Ticker: MaticX
Contract: polygon: 0xfa68FB4628DFF1028CFEc22b4162FCcd0d45efb6
| Parameter | Current Value | Proposed Value |
|---|---|---|
| SupplyCap | 17.2M units | 29.3M units |
Implementation
A list of relevant links like for this proposal:
The proposal Payload was reviewed by Bored Ghost Developing.
Aave Grants Dao
Previously, the allowance of aUSDT for AGD was incorrectly set to the v1 implementation of aUSDT which the Collector contract does not hold any of. This new proposal will set the v1 aUSDT allowance to zero, and correctly set the v2 aUSDT implementation to the originally specified amount of $812,944.90.
Please see the original proposal to renew the grants program here.
The original payload with the incorrect approval can be found here.
The original communication about this issue can be found here.
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded on-chain actions are both generic 'execute' calls to executor/payload contracts (a common Aave governance pattern where the real logic — setting the MaticX supply cap and fixing the aUSDT allowance — lives in separate payload contracts referenced by address, e.g. 0x22C6...32A4F84). Because the calldata here does not expose the granular parameters (the new supply cap value, the specific allowance amounts), it is not possible to directly verify the numeric claims in the description (17.2M → 29.3M units, $812,944.90 v2 allowance, zeroing the v1 allowance) against the calldata. There is no evidence of a mismatch — the two actions align in count and general purpose with the two initiatives described (a caps-update payload and an AGD grants payload) — but the comparison cannot be made with confidence since the decoded fields are opaque executor calls rather than fully decoded parameter-level actions. Per guidance, when the on-chain data is too vague to compare against the description, confidence should be marked low and no discrepancy should be asserted without evidence. No omissions, extra claims, or value/target mismatches can be substantiated from the given data.'
Generated by Kvorum
04Actions
- Target
- 0x7be4…18a6
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0x158a…d45b
- Value
- 0 wei
- Function
- execute(address)
- Arguments
{ "0": "0x22C669EEDf6e58De81777692B070CDB7432A4F84" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 620x62a4…816a | Against | 82.4K | 88.79% | — | 4y ago |
| 5B0x5b3b…7c98 | For | 7K | 7.51% | — | 4y ago |
| 180x1855…98ba | Against | 3K | 3.23% | — | 4y ago |
| A00xa06c…61f7 | For | 397.7 | 0.43% | — | 4y ago |
| EA0xea17…6676 | For | 39.6 | 0.04% | — | 4y ago |
| E40xe459…e666 | For | 0.5 | 0.00% | — | 4y ago |
07Forum
- [ARFC] MaticX Supply Cap Increase Polygon v3 ↗discourse · high confidence
- [ARFC] Aave V3 Caps update Framework ↗discourse · high confidence
- Updated Proposal: Aave Grants DAO Renewal ↗discourse · high confidence
Arguments for
- Increasing the MaticX supply cap allows continued deposits, preserves SD reward flows, and supports the recursive MaticX/wMATIC yield strategy, driving TVL and revenue growth.— Llamaxyz
- Polygon PoS LSTs like MaticX carry minimal secondary liquidity risk because they are redeemable at fair primary market value on L1 and priced via smart contract oracles, so caps should not be limited by secondary liquidity or circulating supply alone.— MarcZeller
- MaticX circulating supply and on-network liquidity have been steadily growing (partly due to prior cap increases and SD incentives), and Aave should remain the leading integration for LST adoption.— Llamaxyz
- From a market risk perspective, MaticX's oracle tracks the underlying MATIC price, making liquidation risk minimal, supporting an increase in the cap.— ChaosLabs
- A community Snapshot vote determined a preference for allowing supply caps up to 75% of an LST's on-chain circulating supply, justifying a larger cap increase.— Llamaxyz
- General expression of support for the proposal update.— drzcrypto
Arguments against
- The proposed cap would represent 100% of Polygon's circulating MaticX supply, exceeding Chaos Labs' methodology recommendation of not concentrating more than 50% of circulating supply on Aave, which risks excessive counterparty/concentration exposure.— ChaosLabs
- Gauntlet's methodology also caps recommended exposure at 50% of circulating supply, and the current cap already reflects that limit, so no further increase should be endorsed at this time.— seawolf, GarrettPetersen
- Raising the cap to 75% of circulating supply (rather than 50%) would create outsized risk to the protocol per Gauntlet's e-mode LST methodology.— GarrettPetersen
- The primary risks for MaticX are counterparty risk from Stader Labs protocol failure and L1<>L2 bridge failure, which are not fully captured by current supply cap models and warrant caution before large increases.— ChaosLabs, MarcZeller
- Bundling an unrelated AGD operational component into the MaticX supply cap AIP is inappropriate, denies token holders vote granularity, and sets a dangerous precedent for future governance actions.— MarcZeller, 0xkeyrock.eth, fig
Unresolved concerns
- Disagreement persists between risk providers (Gauntlet favoring 50% cap) and the community-approved 75% threshold on the appropriate risk appetite for LST supply caps.— GarrettPetersen, ChaosLabs
- No clear DAO policy was established on when and how bundling of unrelated proposal components (e.g., risk parameter changes with operational/governance changes) should be disclosed or permitted going forward.— MarcZeller, 0xkeyrock.eth, fig
- Risk teams' models for LST-specific counterparty and bridge failure risks (as opposed to standard liquidity/circulating supply metrics) have not been fully updated as requested.— MarcZeller
Notable participants
- LlamaxyzProposer who authored the ARFC, provided supporting liquidity data, and iteratively adjusted the proposed supply cap in response to feedback.
- MarcZellerACI representative who voiced strong support for the risk framework around LSTs, but later publicly objected to bundling an unrelated AGD component into the AIP.
- ChaosLabsRisk service provider who repeatedly flagged concentration risk concerns, clarified methodology details, and eventually supported a smaller compromise cap increase.
- seawolfRepresented Gauntlet's initial position opposing any further supply cap increase beyond the 50% circulating supply threshold.
- GarrettPetersenGauntlet representative who supported a 50% cap but explicitly opposed raising it to 75% due to outsized risk concerns.
- 0xkeyrock.ethDelegate who supported the supply cap increase itself but voted NAY specifically over the bundling of unrelated proposal components.
- figFlipside representative who voted NAY over the bundling issue while acknowledging merit on both sides and referencing precedent for combined proposals.
Generated by Kvorum
08Similar proposals
- aaveexecutedMaticX Supply Cap Increase Polygon v396%
- aaveexecutedPolygon Supply Cap Update93%
- aavecanceledMaticX Supply Cap Increase Polygon v393%
- aaveexecutedMaticX Supply Cap Increase Polygon v393%
- aavedefeatedMaticX Polygon Supply Cap Update92%
- aaveexecutedMaticX Polygon Supply Cap Update92%
- aaveexecutedMaticX Supply Cap Increase in Polygon V390%
- aaveexecutedMaticX Risk Parameter & Interest Rate Upgrade88%
- aaveexecutedIncrease wMATIC Supply Cap & BAL Borrow Cap88%
- aaveexecutedstMATIC SupplyCap Increase Polygon v388%