KVORUM
aaveSource: Aave governor v2 · #279

Chaos Labs Risk Parameter Update - MAI Aave V3

executedJul 30, 2023, 01:57 AM UTCby320x329c…3ed4

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to reduce MAI supply caps, borrow caps, and debt ceilings on Aave V3 across Polygon, Arbitrum, and Optimism in response to MAI's recent depegging. Supply caps would be set to current supply levels, borrow caps to current borrow levels, and debt ceilings calculated based on available liquidity. This effectively restricts new MAI usage on these chains.

Type
parameter change

Key changes

  • Arbitrum: Reduce supply cap from 4,800,000 to 325,000 MAI(high)
  • Arbitrum: Reduce borrow cap from 2,400,000 to 250,000 MAI(high)
  • Arbitrum: Reduce debt ceiling from $1,200,000 to $100,000(high)
  • Optimism: Reduce supply cap from 7,600,000 to 650,000 MAI(high)
  • Optimism: Reduce borrow cap from 2,500,000 to 525,000 MAI(high)
  • Optimism: Reduce debt ceiling from $1,900,000 to $130,000(high)
  • Polygon: Reduce supply cap from 2,200,000 to 900,000 MAI(high)
  • Polygon: Reduce borrow cap from 1,200,000 to 700,000 MAI(high)

Notable concerns

  • MAI has recently depegged from its intended value
  • Recommended changes on Polygon effectively disable further MAI usage as collateral
  • Significant reduction in available MAI supply and borrow capacity across all three chains may impact existing positions
ContractsAave V3 PolygonAave V3 ArbitrumAave V3 Optimism
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

256 words

Simple Summary

A proposal to reduce the Supply and Borrow Caps and Debt Ceiling for MAI on Aave V3 Polygon, Arbitrum and Optimism

Motivation

In light of MAI's recent depegging and the insights provided in the Chaos Labs - MAI Depeg Update , we propose a conservative approach, including a temporary reduction in both the supply and borrow caps as well as the debt ceilings. With consideration of the current usage on Aave and existing liquidity, we recommend implementing the following updates:

  1. Set supply caps at the current supply in each deployment
  2. Set borrow cap at the current borrow in each deployment
  3. Set Debt Ceiling at 2*(Liquidity within LB range / MAI LT)

Note: Final recommendations will be rounded for simplicity

Recommendations

ChainCurrent Supply CapRecommended Supply CapCurrent Borrow CapRecommended Borrow CapCurrent Debt Ceiling ($)Recommended Debt Ceiling ($)
Arbitrum4,800,000325,0002,400,000250,0001,200,000100,000
Optimism7,600,000650,0002,500,000525,0001,900,000130,000
Polygon2,200,000900,0001,200,000700,0002,000,000180,000

Note: Given the current usage on Polygon, these recommendations effectively disable further usage of MAI as collateral.

References

Tests: Tests

Proposal payload implementations:

Arbitrum Payload

Optimism Payload

Polygon Payload

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal describes reducing MAI supply/borrow caps and debt ceilings across three Aave V3 deployments (Arbitrum, Optimism, Polygon), citing specific target numbers per chain and referencing three payload contracts (one per chain) that implement these changes. The decoded calldata contains exactly three actions, each calling execute(address) on what appear to be cross-chain bridge executor contracts, each passing a distinct payload address to be delegatecalled. This structural pattern (3 actions, 3 chains, 3 payload addresses) matches the proposal's reference section listing three separate payload implementations for Arbitrum, Optimism, and Polygon. Because the decoded calldata only exposes the bridge-forwarding call and the payload address - not the internal parameter-setting logic inside each payload contract - the specific numeric values (e.g., 325,000 supply cap on Arbitrum) cannot be directly confirmed from this calldata alone. However, this is the expected and standard pattern for Aave cross-chain governance execution, so it is not treated as a red flag. No mismatched targets, no extra or missing high-level actions, and no evidence of the calldata doing something other than what's described. Confidence is medium rather than high because the actual parameter values are not independently verifiable from the visible calldata, only inferable from the consistent architecture and referenced source code.

Discrepancies

  • lowomitted in description

    The decoded calldata only shows generic execute(address) calls forwarding to bridge executors with payload addresses; the actual parameter values (supply cap, borrow cap, debt ceiling numbers) are not visible in the decoded calldata itself - they reside inside the referenced payload contracts. This is standard for Aave's cross-chain governance pattern and not a sign of malicious intent, but it does mean the specific numeric values in the table cannot be independently verified from the calldata alone.

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

04Actions

3 total
#0execute(address)chain 0x1
Target
0x158a…d45b
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x4449A4d0C1cA7C0EA218F11C8a84DD9b8e633D43"
}
Calldata
#1execute(address)chain 0x1
Target
0x5f5c…6711
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x7e840CFFea2D273ED58e7b9B806Cd8BeD619CA88"
}
Calldata
#2execute(address)chain 0x1
Target
0xd1b3…cfa3
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x4449A4d0C1cA7C0EA218F11C8a84DD9b8e633D43"
}
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.