KVORUM
aaveSource: Aave governance v3 · #65

Borrow Cap Reductions on Aave V3 Ethereum

executedApr 7, 2024, 10:11 PM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

Reduce borrow caps for 11 long-tailed assets on Aave V3 Ethereum to minimize protocol exposure to volatile debt positions that generate minimal revenue but pose significant liquidation risks.

Type
parameter change

Key changes

  • MKR borrow cap reduced from 3,000 to 1,980(medium)
  • LDO borrow cap reduced from 3,000,000 to 1,500,000(high)
  • UNI borrow cap reduced from 500,000 to 330,000(medium)
  • RPL borrow cap reduced from 480,000 to 316,800(medium)
  • SNX borrow cap reduced from 1,100,000 to 150,000(high)
  • FXS borrow cap reduced from 500,000 to 330,000(medium)
  • CRV borrow cap reduced from 5,000,000 to 2,750,000(high)
  • STG borrow cap reduced from 5,500,000 to 3,200,000(high)

Notable concerns

  • Reduces borrowing capacity for long-tailed assets that typically generate minimal revenue
  • Addresses liquidation risks that could arise during volatile price movements
ContractsAaveV3Ethereum
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

242 words

Simple Summary

Reduce Borrow Caps for long-tailed assets on Aave V3 Ethereum

Motivation

As part of our ongoing 2 strategy to minimize theoretical exposure to long-tailed debt on Aave, this proposal aims to mitigate the impact of volatility in debt assets further by implementing a substantial reduction in Borrow Cap values. Borrowing these assets typically yields minimal revenue but can pose significant risks, particularly in scenarios where liquidating these positions necessitates obtaining the underlying asset during a large pump. Given the recent upward volatility in asset prices, we propose a refined methodology for determining and implementing these Borrow Cap reductions. This approach aims to enhance the protocol’s resilience and stability amidst dynamic market conditions, safeguarding the interests of Aave users and stakeholders.

Specification

AssetCurrent Borrow CapRecommended Borrow Cap
MKR3k1.98k
LDO3m1.5m
UNI500k330k
RPL480k316.8k
SNX1.1m150k
FXS500k330k
CRV5m2.75m
STG5.5m3.2m
KNC650k350k
1INCH720k475.2k
BAL370k244.2k

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal description provides a detailed, specific table of borrow cap reductions for 11 assets on Aave V3 Ethereum. However, the decoded on-chain action is a single opaque call to execute() on a payload contract address, with no arguments or sub-calls decoded. This is the standard architecture for Aave governance proposals: the top-level governance action delegatecalls into a purpose-built payload contract (referenced in the proposal's 'Implementation' link) whose bytecode contains the actual setBorrowCap calls for each asset. Because the decoded calldata here does not expose those internal calls or parameter values, it is not possible to directly verify that the specific numbers in the description (e.g., MKR 3k→1.98k, SNX 1.1m→150k, etc.) match what the payload contract will execute. This is a common and expected pattern for this proposal type and is not inherently suspicious, but it does mean a line-by-line calldata verification of the specification table cannot be performed from the data provided. I have therefore marked confidence as low rather than asserting a discrepancy, since flagging would require speculation about the payload contract's internal logic, which was not included in the decoded actions. No red flags (target mismatches, extra unrelated transfers, etc.) are visible in the single decoded action itself.

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

04Actions

1 total
#0fallback()chain 0x1
Target
0xe9f0…0258
Value
0 wei
Function
fallback()
Arguments
{}
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.