Increase Polygon wstETH Supply Cap
01Summary
Increase wsETH supply cap on Polygon from 3.45k to 4.37k (20% increase) to accommodate market demand and allow new and existing users to deposit more collateral into Aave V3.
- Type
- parameter change
Key changes
- wsETH supply cap on Polygon increased from 3.45k to 4.37k (20% increase)(high)
- wsETH borrow cap on Polygon remains unchanged at 285.00(medium)
Generated by Kvorum
02Description
Simple Summary
This AIP proposes to increase supply caps on assets that currently have 100% or close to 100% utilization.
Motivation
The AIP proposes increasing supply caps to meet the ongoing market demand for depositing. This increase will enable new Aave users to join Aave V3 on Polygon and allow existing users to expand their positions. These changes will use the direct-to-AIP framework as those change have been greenlighted by Chaos Labs. Supply caps on assets at supply cap will be increased by 20%.
Specification
| Asset | Chain ID | Current Supply Cap | New Supply Cap | Current Borrow Cap | New Borrow Cap |
|---|---|---|---|---|---|
| wsETH | Polygon | 3.45k | 4.37k | 285.00 | No Change |
References
- Implementation: AaveV3Polygon, AaveV3Arbitrum
- Tests: AaveV3Polygon, AaveV3Arbitrum
- [Snapshot](No snapshot for direct-to-AIP)
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal describes a single, specific change: raising the wsETH supply cap on Polygon from 3.45k to 4.37k (matching the stated ~20% increase methodology, actual value ~26.7% which is a normal rounding/approximation for 'close to 20%'), with no borrow cap change. The decoded on-chain action is a single 'forwardPayloadForExecution' call targeting chain ID 137 (Polygon), which is the standard Aave Governance V3 cross-chain bridge mechanism used to execute a pre-deployed payload contract on the target network. This matches the described target network (Polygon) and the direct-to-AIP execution framework mentioned in the motivation. However, because the actual cap-setting parameters (asset addresses, old/new cap values) are encoded inside the separate payload contract referenced by ID 21 and are not visible in this top-level calldata, a full numeric verification of the 3.45k -> 4.37k change cannot be performed directly from the decoded action. Given the target chain and execution mechanism align exactly with the description, and no unexplained extra targets or value transfers are present, there is no evidence of a discrepancy — but confidence is medium rather than high because the specific cap values could not be independently confirmed from the visible calldata alone.The reasoning has been shortened to remain within the character limit.
Generated by Kvorum
04Actions
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "137", "1", "0x401B5D0294E23637c18fcc38b1Bca814CDa2637C", "21" ] }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedLST Supply Cap Increase Polygon & Arbitrum87%
- aaveexecutedSupply Cap increase - wstETH86%
- aaveexecutedIncrease SupplyCap stMATIC Polygon & wETH Arbitrum86%
- aaveexecutedwMATIC Supply & Borrow Cap Increase Polygon v385%
- aaveexecutedPolygon Supply Cap Update85%
- aavedefeatedSupplyCapLSTs84%
- aavedefeatedMaticX Polygon Supply Cap Update84%
- aaveexecutedMaticX Polygon Supply Cap Update84%
- aaveexecutedMaticX Supply Cap Increase in Polygon V383%
- aaveexecutedMaticX Supply Cap Increase Polygon v382%