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, @llamaxyz 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. If, or when, the new SupplyCap is reached a new proposal can be presented to the community to further extend the SupplyCap.
Specification
The following risk parameters are being proposed and have been reviewed by Gauntlet and Chaos Labs.
That said I feel like it’s quite sad that there are so many “reactive” proposals created when supply cap is 100% reached. Would be great if @gauntlet and @ChaosLabs would be a bit more pro-active. On polygon essentially for weeks now CRV/bal/maticx and now also stMatic have been at 100% supply cap making this pool quite ineffective. Having 100% reached should be a rare case, not the norm imo.
Hi @sakulstra, we continuously monitor the caps utilization and propose updates accordingly, such as here.
It is important to note that for some of the examples provided above (CRV, MaticX), there were already proposals to amend the caps on the forums even before the caps were filled. However, they were delayed by the governance process. Thanks to the proposal by @MarcZeller, future cap updates should be much quicker to be implemented.
We propose updated caps when a supply or borrow cap reaches 85% utilization, increasing up to 2X the current supply. However, to improve the efficiency of this process, we will incorporate the following changes:
Propose to update caps at 75% utilization rather than 85%
Update the upper bound of the supply cap increase to 2X the current supply cap (instead of the current supply) to allow for more room for growth
We plan to add a section to our public portals, alerting on caps nearing full utilization.
Hi @sakulstra, we agree on the importance of proactivity. However, we think there is some misunderstanding of what it means to be proactive in this context.
From a risk management perspective, we do not agree that caps should consistently be increased. More specifically, our process is not “let’s continuously increase caps to allow for more growth over time.” This is not proper risk management.
Instead, our process is “let’s first determine what the max size of the market should be (which depends on research, methodology, and community strategic preference). After we determine the max size, we can then progressively update the cap up until the max size.”
In other words, without first determining the maximum acceptable size of the market, it would be premature for Gauntlet and the risk managers to recommend increasing caps.
This is why we have spent months conducting research on how the introduction of supply/borrow cap mechanisms impacts our holistic risk management methodology under different assumptions. Our research discovered that many markets have already grown too large, and for those markets, the cap should be increased only if the community has an Aggressive preference. It would not be transparent to the community if we increased these caps without first hearing the community’s risk preference, and we are especially cautious around non-Ethereum mainnet chains. Now that we have proactively researched and developed a methodology, and aligned on community risk preference (which concluded last week), we can propose paths forward to scale up the size of markets in accordance with the community’s updated strategic preferences.
We hope that this helps align expectations. Moving forward, for assets nearing utilization (e.g., 75% of the supply cap), Gauntlet will provide Conservative and Aggressive recommendations, which should be interpreted as “hard cap” figures.
I would like to express my sincere gratitude for your time and effort in crafting the recent proposal related to incentivizing the use of Aave on Polygon by lifting the stMATIC supply cap. Your contribution @llamaxyz / @matthewgraham, Gauntlet / @pauljlei and Chaos Labs / @omergoldberg is greatly appreciated.
As you may be aware, Lido’s reWards committee had allocated a budget for Aave incentivization. However, upon further analysis, we discovered that the total value locked of Aave v3 deposits for stMATIC on Polygon had reached 99.99% utilization. Therefore, we are unable to allocate the incentives at this time. We strongly support the proposal as it will enable us to provide rewards to Aave depositors and our token holders and further boost the growth of DeFi ecosystem on Polygon.
We will continue to closely monitor the situation and eagerly await the lifting of the capacity constraint.
Thank you once again for your valuable contributions.
From a risk management perspective, we do not agree that caps should consistently be increased. More specifically, our process is not “let’s continuously increase caps to allow for more growth over time.” This is not proper risk management.
My critics was not, about “not updating caps”
If risk allows, would imo be good to adjust the caps accordingly.
To quote my statement from other threads regarding the topic.
My critics are about not initiating the discussion about these assets at all, which i would expect risk teams to do.
BAL, CRV, MAI have been utilized around 100% on polygon v3 since December last year while some other assets had no caps at all (some still don’t have and some others had the arbitrary 2B caps which is a bit ridiculous as well).
Some of these things have been changed by aci, chaos and llama(if i followed proposals correctly), but gauntlet took till mid-February to e.g. have a stance on MAI (which essentially said, “we would have been fine with more”, so doesn’t seem like the risk was holding back) [ARFC] increase borrow cap for MAI Aave Polygon V3 - #5 by Pauljlei
In the gauntlet renewal, missing proactivity was pointed out as one of the concerns. In my eyes this is one manifestation of it.
That said, I have no risk expertise and think all parties involved do good work - my complained is about missing proactivity, not the results, which i cannot judge.
Anyhow let’s not derail this discussion to much as it’s about stMATIC specifically not caps generally.
This proposal is currently schedule in for next weeks engineering workload intake. We are targeting an AIP submission mid/late next week or soon thereafter.
No Snapshot is required due to the nature of the upgrade and support being attained from a risk service provider.
