KVORUM
aaveSource: Aave governor v2 · #241

Polygon Supply Cap Update

executedJun 14, 2023, 10:36 AM UTCby550x55b1…f262

01Summary

AISummary by Kvorumclaude-haiku-4-5

This AIP increases the stMATIC Supply Cap from 32M to 40M units and the MaticX Supply Cap from 29.3M to 38M units on Polygon v3 to address 100% utilization that is blocking yield aggregation strategies from depositing funds. The increases are supported by Chaos Labs, Polygon Foundation, Stader Labs, and passed Snapshot votes.

Type
parameter change

Key changes

  • stMATIC Supply Cap increased from 32,000,000 units to 40,000,000 units on Polygon(high)
  • MaticX Supply Cap increased from 29,300,000 units to 38,000,000 units on Polygon(high)

Notable concerns

  • Gauntlet has a more conservative risk model recommending lower Supply Caps (50% of supply vs Chaos Labs' 75%)
  • Previous smaller Supply Cap increases filled quickly and were absorbed by large users/products, creating poor UX for retail users
Contracts0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c40xfa68fb4628dff1028cfec22b4162fccd0d45efb6
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

479 words

Summary

This AIP increases the stMATIC and MaticX Supply Cap on Polygon to 40M units and 38M units respectively.

Abstract

The utilisation of the stMATIC and MaticX Supply Caps has reached 100% and is preventing strategies built on Aave Protocol from depositing into these reserves.

The yield maximising strategy is current incentivised by two communities, Polygon Foundation and Stader Labs. These incentives encourage users to deposit either Liquid Staking Token (LST) into Aave v3 Protocl.

This AIP, with support from Chaos Labs and a favourable Snapshot, shall increase the Supply Caps to enable users to deposit funds in the stMATIC and MaticX reserves on Polygon v3.

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. These products are now active with more soon to be deployed.

With conservative Supply Caps being implemented and filled within minutes, or hours, communities who have built products on Aave v3 are experiencing great frustration. After investing time, resources and incurring audit costs, these communities are unable to promote their products to prospective users without the newly implemented Supply Caps being filled.

For these integrations to be successful, the Supply Caps need to be increased such that a wide array of prospective users can enter into these automated strategies. Currently, the smaller Supply Cap increases are filling quickly and we are experiencing several whales / products absoring near 100% of newly implemented Supply Caps is not promoting a desirable UX for users.

The original ARFC links below:

The proposed Supply Caps are supported by Chaos Labs. However, Gauntlet has a more conservative risk model which limits the Supply Cap to 50% of supply on the network relative to Chaose Lab's 75%. This difference leads to differing Supply Cap recommendations. Do note, Aave DAO voted to increase the Supply Caps to 75% of supply. A Snapshot vote for each Supply Cap is linked below:

The community has shown clear support for increasing the Supply Caps in line with the original.

The stMATIC and MaticX Supply Cap on Polygon to 40M units and 38M units respectively.

Specification

The following risk parameters changes are presented:

Polygon

Ticker: stMATIC

Contract: 0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4

ParameterCurrent ValueProposed Value
SupplyCap32,000,000 units40,000,000 units

Ticker: MaticX

Contract: 0xfa68FB4628DFF1028CFEc22b4162FCcd0d45efb6

ParameterCurrent ValueProposed Value
SupplyCap29,300,000 units38,000,000 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

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal follows Aave's standard governance execution pattern: a single top-level action calling execute(address) on the Short Executor, which delegatecalls into a dedicated payload contract (0x76884cAF...). This payload contract, per the linked 'Payload Implementation' source in the Implementation section, is expected to contain the logic that sets the stMATIC supply cap to 40,000,000 and the MaticX supply cap to 38,000,000, matching the values stated in the Specification table. Because the decoded calldata only shows the outer execute(address) call and not the internal state changes performed by the payload contract, I cannot directly verify the exact numeric values inside the payload from the provided JSON alone. However, this indirection is routine and expected for all Aave AIPs of this type (supply cap updates via BGD Labs-reviewed payloads), and there is no evidence of a target mismatch, an unrelated payload address, or any other action bundled in that would contradict the description. Given the well-known Aave governance pattern and the alignment between the described intent (raising two specific supply caps to specific values) and the single, appropriately scoped execute() call, I assess this proposal as consistent with the description. Confidence is medium rather than high because the actual parameter-setting logic resides one level deeper (inside the payload contract) and is not independently decoded in the data given to me.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0execute(address)chain 0x1
Target
0x158a…d45b
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x76884cAFeCf1f7d4146DA6C4053B18B76bf6ED14"
}
Calldata

05Tally

Summed from votes

Voters25
VP participating523.8K
Outcome (current)For
Current support100%

06Voters

25 total
Filter:
VoterChoice% of totalRationale
320x329c…3ed4For232.4K44.36%—3y ago
620x62a4…816aFor82.8K15.81%—3y ago
130x13bd…8548For81.8K15.61%—3y ago
B80xb83b…cf5cFor81.4K15.54%—3y ago
B90xb933…8dd1For41.7K7.96%—3y ago
180x1855…98baFor3K0.57%—3y ago
A00xa06c…61f7For678.80.13%—3y ago
EA0xea17…6676For39.60.01%—3y ago
A00xa0ef…2d56For8.30.00%—3y ago
8B0x8bc8…7276For1.20.00%—3y ago
820x82a9…e279For10.00%—3y ago
880x8824…5443For0.50.00%—3y ago
E40xe459…e666For0.50.00%—3y ago
BF0xbfec…52f2For0.20.00%—3y ago
D50xd5c9…066fFor0.20.00%—3y ago
280x28d0…0eacFor0.20.00%—3y ago
330x33e8…6284For0.10.00%—3y ago
120x121d…876eAgainst0.10.00%—3y ago
D70xd7bb…962eFor0.10.00%—3y ago
A90xa9c0…273dFor0.10.00%—3y ago
B60xb656…bb59Against0.10.00%—3y ago
8D0x8d52…6f34For0.10.00%—3y ago
820x8280…c89bFor00.00%—3y ago
3B0x3b53…e3d4For00.00%—3y ago
650x65b8…692dFor00.00%—3y ago
Showing 25

07Forum

No forum thread is confidently linked to this proposal.