KVORUM
aaveSource: Aave governance v3 · #95

Updating weETH Risk Parameters

executedMay 6, 2024, 12:43 PM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to increase weETH supply cap from 48,000 to 84,000, borrow cap from 3,200 to 29,500, reduce optimal utilization from 45% to 35%, and increase reserve factor from 15% to 45% on Aave Ethereum V3 to boost DAO revenue and support growing demand for weETH collateral.

Type
parameter change

Key changes

  • Supply cap increased from 48,000 to 84,000 weETH(high)
  • Borrow cap increased from 3,200 to 29,500 weETH (35% of new supply cap)(high)
  • Optimal utilization ratio (UOpt) decreased from 45% to 35%(medium)
  • Reserve factor increased from 15% to 45%(high)

Notable concerns

  • Supply and borrow caps were reached quickly after initial weETH onboarding, indicating high demand that could create renewed pressure after this increase
ContractsweETH on Aave EthereumV3
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

264 words

Simple Summary

This proposal aims to update the risk parameters and interest rate strategy of the weETH asset on the Ethereum pool to boost Aave DAO revenue and encourage collateral adoption.

Motivation

The successful onboarding of EtherFI into Aave has demonstrated significant demand for weETH usage as both collateral and a borrowing asset, with both initial supply caps reached in minutes and second cap increases filled under similar conditions. To accommodate this demand and facilitate protocol growth, this proposal suggests increasing the supply cap of weETH on the Ethereum pool and the borrow cap at 35% of the new supply cap amount. This proposal also aims at changing the interestRate Strategy to place the optimal ratio at 35% of liquidity.

Expanding borrow capacity will result in a higher collateral yield, which in turn creates a positive flywheel effect on supply and demand. By maintaining the borrow cap at an optimal ratio (35%) of the supply cap, we can balance risk, available liquidity, and LP yield effectively.

We also propose to increase weETH RF to 45% to contribute to Aave DAO revenue.

Specification

The following changes will be made to the weETH asset on Aave EthereumV3:

ParametersCurrentRecommended
Supply Cap48,00084,000
Borrows Caps3,20029,500
UOpt45%35%
Reserve Factor15%45%

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

This is a standard Aave governance proposal pattern: the on-chain action is a single call to execute() on a dedicated payload contract, with no decoded arguments. The actual risk-parameter changes (supply cap, borrow cap, UOpt, reserve factor) are implemented inside that payload contract's bytecode, which is not exposed in the decoded calldata provided here. The description links to the exact implementation and test contracts on GitHub for the address matching the payload target, which is consistent with how Aave proposals are typically structured and reviewed off-chain before being packaged into a single executor call. Because the decoded action set only shows an opaque execute() call with no parameters, I cannot directly verify that the specific numbers in the specification table (48,000→84,000 supply cap, 3,200→29,500 borrow cap, 45%→35% UOpt, 15%→45% reserve factor) match what the payload contract will actually set. There is no evidence of a mismatch, target redirection, or hidden action — the single action target and pattern align with the described intent — but the inability to inspect the actual parameter values inside the payload contract means I cannot assign high confidence to the numeric claims. I am marking this as consistent based on structural alignment (a single payload execution matching a single coordinated risk-parameter update), but confidence is low because the granular values cannot be cross-checked against the decoded calldata alone. continued. discrepancies field left empty since no contradiction is observable in the available decoded data; this reflects the limits of what can be decoded from a fallback execute() call rather than an actual mismatch.}],

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
0x59c6…fcf0
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.