[ARFC] Polygon v3 Supply Cap Update 2023.05.21

[Llamaxyz]

---

title: [ARFC] Polygon v3 Supply Cap Update 2023.05.21
shortDescription: Increase SupplyCap stMATIC on Polygon v3 from 30M units to 40M units.
author: @Llamaxyz - @TokenLogic
dated: 2023-05-21

---

Summary

This publication proposes increasing the stMATIC Supply Cap on Polygon from 30.0M to 40M units.

Abstract

This AIP implements risk parameter changes to stMATIC Polgyon v3.

The utilisation of the stMATIC reserve has reached 99.95% and this publication proposes increasing the SupplyCap by a further 33.33% to 40M 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. These products are now active with otheres through audit and 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 prior the newly implemented Supply Caps being filled. Some communities have coordinated large distribution network agreements in anticipation of offering users yield derived from Aave v3.

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 Supply Caps are filling so fast Aave DAO can not even proactively implement upgrades through governance to maintain spare deposit capacity. At the root of the issue are the small incremental Supply Cap increases, these are being filled within minutes, or hours (34 hours previous stMATIC increase). These small windows of time, where users can deposits LSTs into Aave Protocol, are not conducive to creating an environment that encourages teams to build on Aave.

The previous stMATIC Supply Cap increase was 5M units and the cap was filled within 34 hours. Other cap increases have been filled in as little as 3 minutes (wstETH on Arbitrum). The growth in TVL and the resulting revenue is good for Aave DAO. However, the risk exposure must be considered and it is the authors opinion that Aave DAO should consider implementing a larger increase this time. The last two stMATIC Supply Cap increases have not led to meaningful stable coin debt which is the primary risk concern.

Something the DAO should also consider is that teams are distributing assets on Aave v3 Polygon to promote users entering the yield maximising strategy. It has led to Aave v3’s TVL overtaking v2 on Polygon and increased LST adoption. If Aave DAO seeks to encourage teams to continual distribute rewards on Aave v3, then creating a supportive environment through larger Supply Cap increases is something that should be considered.

This publications seeks to increase the Supply Cap of stMATIC by 33.3%, or 10M units. This is twice the previous increase and represents 72.5% of the supply on Polygon and 33.4% of the total supply on Ethereum. This represents a pivot from the more conservative approach to risk and it recognises that liquidators could migrate stMATIC, or wMATIC, to Ethereum and redeem it for MATIC before swapping to stable coins. This type of liquidation is not atomic, nor quick and it requires the liquidator to take on price exposure over the duration of the process. However, it is wMATIC to stable coin liquidity on Polygon that is the limiting factor as stMATIC to wMATIC swaps incur low price impact on Polygon.

The author welcomes input from risk providers and feedback from the community towards the potential to implement a larger Supply Cap increase that pushes towards the 75% maximum, acknowledging there are some stable coin debt positions. If the community prefers for a more conservative 5M unit increase, same as previous proposal, the author will not hesitate to implement this whilst the discussion is ongoing.

Specification

The following risk parameters changes are presented:

Polygon

Ticker: stMATIC

Contract: 0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4

Parameter	Current Value	Proposed Value
SupplyCap	30,000,000M units	40,000,000 units

Copyright

Copyright and related rights waived via CC0.

[Marin]

@Llamaxyz

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.

Thank you @Llamaxyz and @TokenLogic for addressing this general problem stAssets face as well as the integration partners. Currently, it is hard to predict a sweet spot and we obviously did not reach the proper level to stabilize close to 80% of the cap utilization, and multiple protocols are impacted by this.

Contributors are open to work on the specific problem and trying to find a better solution to reduce overhead on all parties involved.

@Llamaxyz

This represents a pivot to prior more conservative approach to risk and it recognises that liquidators could migrate stMATIC to Ethereum and redeem it for MATIC before swapping to stable coins. This type of liquidation is not atomic, nor quick and it requires the liquidator to take on price exposure over the duration of the process.

Just to highlight that this is a multi-day process and the risk is much higher than regular users would understand by reading the statement.

Unstaking takes 80 checkpoints which can take up to 3 days.

[ChaosLabs]

Per our supply cap methodology and community preference for LSD caps, we support the increase suggested in this post.
We conducted stress tests simulating depeg scenarios yielding the results in the graphs below.

[Llamaxyz]

Hi Everyone,

When Gauntlet’s analysis is shared here, if it is supportive of the proposed Supply Cap increase, we propose this upgrade be implemented by the Risk Stewards.

If not, we will create a Snapshot vote presenting both Chaos Lab’s and Gauntlet’s proposed parameters, in line with the governance process.

[Gauntlet]

Gauntlet believes this cap increase for stMATIC is premature based on the current implementation for LST Emode. Our methodology, as tailored to how LSTs are currently priced, thresholds the supply cap to 50% of the local supply which in this case is 32m. stMATIC pricing must move to the synchronized price adapter solution, and the community align on potential “killswitches” in the event of stMATIC depeg, for this cap increase to not add excess market risk.

At this current time, Gauntlet would recommend increasing the cap to 32M.

[Llamaxyz]

Hi Everyone,

With Gauntlet and Chaos Lab’s analysis drawing different results. We will be progressing this proposal to Snapshot to determine if an AIP will be submitted:

The following voting options will be shown on Snapshot.

YAE - Chaos Lab’s 40,000,000 units
YAE - Gauntlet 32,000 units
NAE
ABSTAIN

[Marin]

I agree that stMATIC pricing should move to a synchronized price adapter solution.

Open question:

How can competing products to stMATIC have the same cap (30m) if the limiting factor here is increased depeg risk? Correlation to local supply in this case is an odd risk factor.

By logic if the liquidity of an asset is low the depeg risk is greater than the risk of assets being stuck on Ethereum where it is essentially out of circulation. No utility for the asset is provided there, no trading, no oracles, no impact.

To expand, none of the LST protocols that are Polygon based provide utility on Ethereum mainnet. However, due to the architecture of Polygon POS chain, the design of staking, and therefore liquid staking is on Ethereum.

Aggregation excludes Balancer a-bb pools and Kyber elastic (which are being rebuilt). Another proof of robustness is that a crash of a major liquidity source for stMATIC on Kyber did not cause a change in conversion rates. The sole fact you can unstake the token mitigates death spiral effects as users buy at discount and unstake for a premium.

Additionally if we consider Balancer as a major risk due to being LST power house and liquidity tends to get concentrated there stMATIC still provides superior rates.

Would be grateful for a clear and standardized insight into risk assessments that would enable all builders in the space to create efficient strategies for their stAssets as with current understanding it is constantly shifting which results in the loss of large amounts of money both in incentives and manhours.

[Llamaxyz]

Hi Everyone

The Risk Stewards are in the process of updating the stMATIC Supply Cap to 32M units. The Supply Cap increase has been initiated by Chaos Labs and is pending Gauntlet signing + executing the transaction linked below.

Safe{Wallet}

[CBeckman]

Thank you @Llamaxyz @TokenLogic for calling attention and proposing a rational solution to this limitation that has been impairing the growth of LST protocols primarily rooted/contributing to AAVE.

Although this increase is significant compared to the previous ones, based on foregoing governance discussions and growing demand for LSTs on Polygon, this cap (40M) would likely allow dependent protocols to sustain long enough (without interruption) for the on-chain liquidity to catch up, while justifying the continuation of strategies’ development and LST providers’ incentivization.

@Llamaxyz

The following voting options will be shown on Snapshot.

YAE - Chaos Lab’s 40,000,000 units
YAE - Gauntlet 32,000 units

One or the other, that said;

@Llamaxyz

At the root of the issue are the small incremental Supply Cap increases, these are being filled within minutes, or hours (34 hours previous stMATIC increase). These small windows of time, where users can deposits LSTs into Aave Protocol, are not conducive to creating an environment that encourages teams to build on Aave.

While security has to remain a must, it seems to me that the disparity between these two caps (+2M vs +10M) could set a tone that might affect long-term partners’ efforts. Based on previous increases, 2M would likely be filled in hours, leading to a similar proposal for identical purposes, thus costing everyone’s time and effort.

If the synchronized price adapter solution is the way to go, I am in favor. Until then, if there was a way to move on in a non-conservative way without further impeding the ecosystem growth, that would be, in my opinion, optimal for all parties involved.

[Llamaxyz]

Hi Everyone

A Snapshot vote has been created.

https://snapshot.org/#/aave.eth/proposal/0xd0e157ef44b5429df7e412126d632afa1192f84fa6045dcdcaed61bc79ad1b45

[Gauntlet]

Thanks @Marin for your open questions on the relationship between liquidity and the supply caps. We’ve published our methodologies here where in our LST supply cap computation, we take into account the liquidity conditions for each asset amidst both hypothetical depeg events and normal conditions. Our framework balances both these conditions to create supply caps that are flexible for all market conditions.

From a risk perspective, Gauntlet did not support the MaticX supply cap increase to the current 29M, whereas we have been supporting stMATIC supply cap increases. That being said, the community preferred to increase MaticX caps at the time, so as a result both MaticX and stMATIC have similar supply caps, which currently are little under 50% circulating supply. For additional context, our current methodology recommends a cap of 21M for MaticX and 33M for stMATIC, where the differentiating factor is indeed the liquidity of the assets.

Gauntlet has consistently maintained our stance that the supply cap should be thresholded at 50% of the circulating supply, to avoid supply concentration and tail risk from LST depegs. Now that the synchronized price adapters have been executed, Aave is one step closer to safely supporting more aggressive parameters for LSTs. We believe the final step should be community alignment on how LST markets should behave when significant depegs occur - whose length magnitude, cause, and permanence are impossible to predict.

[Llamaxyz]

Hi @ChaosLabs and @Gauntlet,

Can you please process the Supply Cap increase in line with the community Snapshot ?
If not, please let us know and we will prepare an AIP.

[Gauntlet]

As we mentioned above, our analysis indicates that if the community would like to raise the cap, we recommend increasing the cap to no more than 32M. If the community wishes to raise to 40M, then it would be best to move forward with AIP.