[ARFC] MaticX Supply Cap Increase Polygon v3

[ChaosLabs]

We would like to clarify a few points regarding the proposed supply cap increase:

Firstly, we would like to highlight that the current circulating supply on Polygon is around 34M. Therefore, the proposed cap would represent 100% of Polygon circulating supply. Our methodology recommends not concentrating more than 50% of the circulating supply on Aave, which is why the current supply cap is set at 17M. This is necessary to limit Aave’s risk exposure to a single asset on a given deployment.

Secondly, we would like to clarify that the supply caps methodology is being used for the EMode LT of MaticX, which is not covered by this version of the methodology.

Lastly, we would like to point out that the 15% price drop being used is intended for market caps greater than $20B, while MaticX is currently at around $60M. The correct price drop for this case is 50%, but this does not change the outcome of our methodology when disregarding the total circulating supply limitation.

Given the above points, we believe it is important to wait for more liquidity to flow to Polygon before considering a significant (2x) increase in the supply cap.

[seawolf]

Per Gauntlet’s Methodology, we do not advise any further increase in MaticX’s supply cap at the moment. As previously stated, MaticX’s current supply cap already accounts for 50% of the circulating supply on the Polygon chain. From the standpoint of asset risk concentration, we cannot endorse any additional exposure exceeding 50%.

[MarcZeller]

This is a crucial discussion about LSTs, and within the ACI, we view the Polygon PoS as a “canary” network for LSTs in general.

Both MaticX and stMatic can be redeemed at fair primary market value on ETH L1 within three days.

Aave V3 market utilizes calculated price feeds that track the primary market pricing for both assets.

In terms of liquidity, both assets are essentially MATIC with a three-day delay, and their secondary liquidity is not as significant as other assets. Their circulating supply is elastic, with anyone able to mint and burn new assets on L1 within a reasonable timeframe.

That’s why, for both LST assets, liquidity risk and especially secondary liquidity risk are less relevant.

The actual risks with these two assets involve protocol failure risks from Lido and Stader, as well as the L1 <> L2 canonical bridge failure. These risks should be the primary focus of the risk team when modeling risk parameters for LST tokens on Polygon PoS. Other risk parameters should be considered within the scope of MATIC itself since LSTs are MATIC wrappers with minimal timeframe delays.

There is simply no scenario in which the Aave protocol incurs bad debt if, for some reason, MaticX’s secondary price on PoS becomes depegged, because the protocol takes primary market prices into account. If such a scenario occurs, arbitrageurs would profit by leveraging on Aave and other markets on PoS, and/or by purchasing LSTs on PoS and redeeming them for fair value MATIC on L1 with a slight delay.

We believe it is essential to have this conversation now since, after the Shanghai upgrade (in 8 days) and the withdrawal queue clearing (a few weeks/months after Shanghai), ETH and its LSTs will exhibit similar properties.

LSTs represent a significant source of growth and revenue for the Aave protocol, and risk teams should not hinder Aave’s growth by employing inadequate models. Protecting the protocol is everyone’s priority, but let’s do so with the right data by implementing the appropriate models.

We invite both risk service providers to update their models concerning LSTs in general.

[ChaosLabs]

The calculated price feed and redeemability mechanisms of the said assets (and other LSTs in general) are considered in our analyses and recommendations.

The 50% limit of total circulating supply in our supply cap methodology is set to strike a balance between allowing the growth of the protocol and mitigating counterparty and concentration risk. While Chaos Labs does not recommend increasing the supply cap beyond 50% of the total on-chain circulating supply, the community should ultimately decide how to approach this issue as it pertains to the appetite for counterparty risk, as noted in the comment by @MarcZeller.

@MarcZeller

The actual risks with these two assets involve protocol failure risks from Lido and Stader, as well as the L1 <> L2 canonical bridge failure.

We are targeting a Snapshot vote for Tuesday, April 18th, to gauge the community’s preference with respect to limiting the supply caps for LSTs, which will be considered in future supply cap recommendations. The options we propose are:

1. Limit supply cap to 50% of on-chain circulating supply
2. Limit supply cap to 75% of on-chain circulating supply
3. Do not limit the supply cap as a percentage of the circulating supply

[Llamaxyz]

Hi @ChaosLabs,

Can we please confirm on-chain here means all networks ?

Llama has been working with various teams to facilitate the migration of funds from Ethereum to Polygon in light of the risk parameter guidelines. If on-chain circulating supply considers all networks and not limited to the local network, then for MaticX and stMATIC there is sufficient supply of both assets to support increasing both respective Supply Caps.

[ChaosLabs]

On-chain here means for the specific native chain, in this case, Polygon.

[Llamaxyz]

Hi Everyone

Llama generated some supporting analysis of existing liquidity conditions for MaticX and wMATIC.

This chart shows the MaticX circulating supply and the amount of MaticX that is on the Polygon network. Both are trending higher over time. This appears be linked to the Liquidity Mining on v3 and adoption of structured yield products. Aave is a key integration for any LST provider seeking to grow there LST adoption. It is in Aave’s best interest to be the lending market of choice for LSTs and to continue being a strong growth engine for LST adoption.

Llama is now logging the swap size for a pre-defined amount of price impact via 1inch on Polygon. The data sample period is small as we need to submit a query then store the data to build a library that is then used to generate a chart over time.

When MaticX migrates to the new Balancer MaticX/bb-a-wMATIC pool with a higher amplification factor, we expect liquidity conditions to improve. The chart above provides a visual for tracking the affect of the new pool.

With respect to counterparty and concentration risk, we believe the amount of exposure Aave should have is a community decision. The Polygon Bridge risk is applicable to the v2 and v3 deployment and the TVL in the past has been a lot higher than it is now. Our preference is for liquidity to drive the amount of exposure to a specific asset with the limitation being derived from either the LST and/or underlying network token’s liquidity. It is great to see @ChaosLabs enabling the Snapshot vote.

[ChaosLabs]

@ChaosLabs

We are targeting a Snapshot vote for Tuesday, April 18th, to gauge the community’s preference with respect to limiting the supply caps for LSTs, which will be considered in future supply cap recommendations.

The Snapshot for the community to vote on has been published in collaboration with Flipside (@fig).

Start Date: Wednesday, Apr 19, 2023, 10:00 AM
End Date: Wednesday, Apr 24, 2023, 10:00 A

Thank you in advance for your participation in the vote.

[Llamaxyz]

Hi everyone

The Supply Cap is 98.31% utilised and there is 71bps of yield for depositors in SD rewards.

As MaticX supply was limiting the Supply Cap and now, there is more MaticX on Polygon, we can implement a smaller Supply Cap change. This will support and enable the SD rewards to keep flowing.

New Supply Cap: 50% of Polygon Circulating Supply = 19,556,426.1

Parameter	Current Value	Proposed Value
SupplyCap	17.2M units	19.6M units

@ChaosLabs and @Gauntlet - can you please advise if you are supportive of this change.

[ChaosLabs]

Chaos Labs is supportive of this proposal.

Additionally, the Snapshot for community preferences in regards to counterparty risk appetite and circulating supply limits on the supply caps is underway. We invite the community to vote as the outcome of this vote can impact future supply cap recommendations.

[Llamaxyz]

Hi Everyone

With the Snapshot vote determining the community preference to have a Supply Cap of up to 75% of the supply of the LST on the respective network, @Llamaxyz would like to propose increasing the Supply Cap of MaticX from 17.2M units to 29.3M units.

Parameter	Current Value	Proposed Value
SupplyCap	17,200,000 units	29,300,000 units

If a risk advise can confirm this, we will resubmit our PR to @bgdlabs for review with the incorporation of the new Supply Cap.

[GarrettPetersen]

Per Gauntlet’s e-mode methodology for liquid staking tokens, we can support a supply cap up to 50% of circulating supply (i.e. a supply cap of 19.6M tokens). We do not support raising the supply cap to 75% of circulating supply; our analysis suggests that this would create outsized risk to the protocol.

[ChaosLabs]

As can be seen in the table below, provided in the Chaos Labs LSD Methodology Update, MaticX serves mainly as collateral for borrowing MATIC in E-Mode.

@ChaosLabs

Deployment	Asset	Supplied	Native Token Borrowed against	Other Assets Borrowed against	Borrowed	Oracle (Smart Contract/Market Price)
Polygon	MaticX	$17M	$14M	$550K	0	Smart Contract

Since the oracle for MaticX is based on the underlying asset’s (MATIC) price, the risk of liquidation is minimal. As a result, we are confident in increasing the caps from a market risk perspective, assuming there is no significant change in user behavior or position distribution.

The primary risk involved in this case is counterparty risk. While Chaos Labs suggests limiting the supply cap to 50% of the total circulating supply, the community has opted for a more aggressive approach. Therefore, the community should determine its desired risk appetite for this specific proposal.

[Llamaxyz]

Hi Everyone

Given how the discussion around this proposal has progressed. To progress the proposal, we suggest a Snapshot vote presenting the following options:

Option 1 - YAE 19.6M Supply Cap
Option 2 - YAE 29.3M Supply Cap
NAE
ABSTAIN

Total Supply on Polygon is 39,112,852.20 units of MaticX. A Snapshot vote has been created, it can be found here.

[MarcZeller]

With the ACI, we would like to voice our disapproval of @Llamaxyz doing a bundle on AIP-220 integrating an AGD-related component in this AIP. This second component of the AIP has zero links or coherence with the main component of this AIP.

While we’re supportive of both components of this AIPs, we think it sets dangerous precedence in the DAO. We are building not only for now but for the future. Bending the rules now will lead to the far west later.

The voice of the token holders should be respected, and “bundling” is not allowing vote granularity of their decisions.

However, as the “second” component of this AIPs is simply an operational adjustment of a previously approved governance decision, we will not cast a NAY vote on this AIP. We will instead intentionally not cast a vote.

We want to publicly state, that any other bundle in the future will be met by a NAY vote from the ACI and encourage service providers to refrain from publishing them.

[0xkeyrock.eth]

In total agreement here with @MarcZeller. We support the supply cap increase but we will be voting NAY as we don’t like the idea of bundling votes, especially in some ways coming out of nowhere with the aUSDT v1 to v2 migration.

Out of curiosity, @Llamaxyz could you explain the reasoning behind this bundling?

[Llamaxyz]

Thanks for the comments @MarcZeller and @0xkeyrock.eth. We decided to combine the AIPs to minimize governance overload since the AGD update was an operational change that was already approved by the DAO. BGD encouraged us to do so to minimize governance overload and we mentioned it here. Your points are fair and noted though. From next time, we will make sure to separate AIPs such as this even if there has been implicit approval from governance before.

[fig]

Flipside has voted NAY on this proposal due to the differing scopes; one risk-related, and one operational change.

We do believe there is an opportunity to reduce Governance overhead and should not be looked at as a malicious action. This is especially true with rising gas costs and a growth in proposal volume.

It may be worth indicating in the ARFC stage a team’s intention to bundle a proposal, and if so, with which other one(s). Here, voters can evaluate if it’s the right fit.

Feels like both sides to this argument have merit here.

An appropriate example of this may be an asset addition across chains, with similar risk profiles.

---

I would note this “bundling” has happened before: Aave - Add UNI, MKR, SNX & BAL to Ethereum v3

Not that it means it is right but interesting context as well.

[0xkeyrock.eth]

Definitely something to discuss. We’re in agreement that for examples such as assets across chains, bundling makes more sense and would be open to discover this.

The problem here was that the vote regarding MaticX Supply Cap increase, had on the bottom of the AIP something that personally i wasn’t even aware of because it happened back in January.

If @Llamaxyz mentioned it beforehand in this ARFC, we would keep an open mind regarding what to vote and bundling although it remains a completely unrelated operational change.

Happy to collaborate and brainstorm around solving such operational overload.

[drzcrypto]

supporting the update.