KVORUM
aaveSource: Aave governor v2 · #155

Supply/Borrow Cap Updates Polygon and Arbitrum V3

executedFeb 19, 2023, 12:12 PM UTCbyBC0xbc54…7df0

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to adjust supply and borrow caps for 7 assets across Aave V3 Polygon and Arbitrum networks. On Polygon: BAL supply cap increases to 361,000; EURS supply cap to 4M and borrow cap to 947K; DAI supply cap to 45M and borrow cap to 30M; USDC supply cap to 150M and borrow cap to 100M; USDT supply cap to 45M and borrow cap to 30M. On Arbitrum: LINK supply cap increases to 676,980; ETH supply cap to 35,280. Changes based on Chaos Labs' methodology to address high cap utilization.

Type
parameter change

Key changes

  • BAL supply cap increased from 284,600 to 361,000 on Polygon(medium)
  • EURS supply cap increased from 2,000,000,000 to 4,000,000 and borrow cap increased from 728,530 to 947,000 on Polygon(medium)
  • DAI supply cap increased from 2,000,000,000 to 45,000,000 and borrow cap increased from 3,860,000 to 30,000,000 on Polygon(high)
  • USDC supply cap increased from 2,000,000,000 to 150,000,000 and borrow cap increased from 30,680,000 to 100,000,000 on Polygon(high)
  • USDT supply cap increased from 2,000,000,000 to 45,000,000 and borrow cap increased from 5,060,000 to 30,000,000 on Polygon(high)
  • LINK supply cap doubled from 350,000 to 676,980 on Arbitrum(medium)
  • ETH supply cap increased from 20,300 to 35,280 on Arbitrum(medium)

Notable concerns

  • BAL supply cap modification from original Chaos Labs analysis to address Gauntlet feedback
Contracts0x060Bea15AF594FE9e0A243cA632F2C7D1935C70f0x280e404338d9d8e50B11D6677B9C91BA86E0FD22
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

339 words

Simple Summary

A proposal to adjust eleven (11) total risk parameters, including Supply Cap and Borrow Cap, across seven (7) Aave V3 Polygon and Arbitrum assets.

Motivation

The objective of this proposal is to recommend updated supply and borrow caps for V3 assets that have reached high utilization of either cap. The recommendations provided in this proposal were derived using Chaos Labs’ Updated Supply and Borrow Cap Methodology

The respective governance forum discussion is linked below:

Specification

The following risk parameter proposal is presented below:

Polygon

AssetCurrent SupplyCurrent Supply CapRecommended Supply CapCurrent BorrowCurrent Borrow CapRecommended Borrow Cap
BAL284,600284,600361,000136,400256,140No Change
EURS2,060,0002,000,000,0004,000,000728,530728,530947,000
DAI5,680,0002,000,000,00045,000,0003,160,0003,860,00030,000,000
USDC35,590,0002,000,000,000150,000,00018,600,00030,680,000100,000,000
USDT5,940,0002,000,000,00045,000,0004,870,0005,060,00030,000,000

Arbitrum

AssetCurrent SupplyCurrent Supply CapRecommended Supply CapCurrent BorrowCurrent Borrow CapRecommended Borrow Cap
LINK338,490350,000676,980$763,40020,427No Change
ETH17,64020,30035,2803,66311,165No Change

References

Forum Post

Tests: Arbitrum, Polygon

Proposal payload implementation - Arbitrum, Polygon

Deployed proposal payload - Arbitrum, Polygon

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The on-chain calldata consists of two execute(address) calls that forward execution to bridge executor contracts, targeting two payload addresses. These target addresses (0x060Bea15AF594FE9e0A243cA632F2C7D1935C70f for Polygon and 0x280e404338d9d8e50B11D6677B9C91BA86E0FD22 for Arbitrum) exactly match the 'Deployed proposal payload' links explicitly cited in the proposal description for Polygon and Arbitrum respectively. This is the standard Aave cross-chain governance pattern where the top-level proposal simply triggers execution of chain-specific payload contracts that contain the actual risk parameter updates (supply/borrow caps for BAL, EURS, DAI, USDC, USDT, LINK, ETH). Because the decoded calldata only shows the outer execute() calls and not the internal logic of the payload contracts, I cannot directly verify each of the eleven specific cap values inside the payloads from this data alone. However, the addresses align precisely with what the description claims, and this pattern (execute() to a verified payload address matching the disclosed contract) is the expected, non-deceptive structure for these proposals. No mismatches, omissions, or extra actions are apparent given the information available, so I rate this consistent with medium confidence due to the inability to fully decode the nested payload logic from the provided data.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

2 total
#0execute(address)chain 0x1
Target
0x158a…d45b
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x060Bea15AF594FE9e0A243cA632F2C7D1935C70f"
}
Calldata
#1execute(address)chain 0x1
Target
0x2e2b…05f1
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x280e404338d9d8e50B11D6677B9C91BA86E0FD22"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.