KVORUM
aaveSource: Aave governor v2 · #172

stMATIC SupplyCap Increase Polygon v3

executedMar 11, 2023, 06:10 AM UTCby550x55b1…f262

01Summary

AISummary by Kvorumclaude-haiku-4-5

Llama proposes doubling the stMATIC Supply Cap on Aave v3 Polygon from 7.5M to 15M units to enable the stMATIC/wMATIC yield strategy and incentivize Lido DAO to distribute LDO rewards.

Type
parameter change

Key changes

  • Increase stMATIC SupplyCap from 7.5M units to 15M units on Polygon v3(high)
  • Enable users to deposit stMATIC and participate in the recursive stMATIC/wMATIC yield strategy(high)
  • Create conditions for Lido DAO to distribute LDO rewards on Aave v3 Polygon liquidity pools starting March(medium)

Notable concerns

  • The current stMATIC reserve utilization is at 100% requiring this cap increase
  • Gauntlet analysis indicates conservative cap ceiling of 16.17M and aggressive ceiling of 24.26M; proposed 15M is within conservative range
  • This increase follows the principle of not more than doubling SupplyCap in a single proposal per Chaos Labs recommendation
Contracts0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

387 words

Summary

Llama proposes increasing the stMATIC Supply Cap on Polygon to facilitate an expansion of the stMATIC/wMATIC loop strategy.

Abstract

The utilisation of the stMATIC reserve has reached 100% and this proposal seeks to increase the SupplyCap to 15M units up from 7.5M units.

Increasing the SupplyCap will enable users to deposit stMATIC and enter the recursive stMATIC/wMATIC yield strategy.

Lido DAO currently has the ability to distribute LDO rewards on the Polygon v3 deployment. Due to the stMATIC SupplyCap being reached there is little to no incentive for Lido DAO to distribute LDO rewards. This proposal seeks to encourage Lido DAO to distribute LDO rewards, as early as March on the Aave v3 Polygon liquidity pools.

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. The below proposals details are applicable to stMATIC:

This proposal is a continuation of the above work.

Analysis performed by Gauntlet generated a conservative and aggressive SupplyCap ceiling of 16.17M and 24.26M units respectively.

Chaos Lab's supports increasing the SupplyCap to 15M units. This follows the general rule of thumb that SupplyCap should not be more than doubled in any single proposal.

As Chaos Lab's recommendation is less than the maximum conservative SupplyCap presented by Gauntlet's methodology, Llama proposes increasing the SupplyCap to 15M SupplyCap.

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 stMATIC over time.

Specification

The following risk parameters being proposed have been reviewed by Gauntlet and Chaos Labs.

Ticker: stMATIC

Contract: polygon: 0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4

ParameterCurrent ValueProposed Value
SupplyCap7.5M units15M units

Implementation

A list of relevant links like for this proposal:

Chaos Labs and Gauntlet both contributed to the development of the ARFC forum post.

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 describes a single, well-defined action: increasing the stMATIC SupplyCap on Aave v3 Polygon from 7.5M to 15M units via a payload contract. The only decoded on-chain action is a call to execute() targeting address 0xAa7EF2f9b31Fa26e802cA9B3E33990ada4143fb9, which is an exact match to the 'Deployed Contracts' address explicitly linked in the proposal's Implementation section (polygonscan link to 0xaa7ef2f9b31fa26e802ca9b3e33990ada4143fb9). This is the standard Aave cross-chain governance pattern where a payload contract executed on the target chain performs the actual parameter change (setting the SupplyCap), and the mainnet-side calldata only shows the delegated execute() call rather than the internal setSupplyCap logic. Since we cannot decode the internal logic of the payload contract from the data given, we cannot directly verify the numeric 15M value inside the calldata, but the target contract address matches precisely what the description claims will be executed, and this pattern (bridge execute call to a named payload) is routine and expected for Aave governance proposals of this type. There is no evidence of target mismatch, extra actions, or omitted actions. Confidence is medium rather than high because the actual SupplyCap value change is not independently verifiable from the single decoded action alone, but the structural match between the description and calldata target is strong and no red flags are present.

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": "0xAa7EF2f9b31Fa26e802cA9B3E33990ada4143fb9"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

AIForum synthesis by Kvorumclaude-sonnet-5
sentiment · favorablethread · constructive

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗