KVORUM
aaveSource: Aave governor v2 · #7

desactivation of Aave V1 stable rate borrowing

executedApr 7, 2021, 11:35 AM UTCbyF80xf82e…97b5

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to disable new stable rate borrowing positions on Aave V1 and update the rebalance mechanism to enforce variable rate migration during high borrowing pressure. This aims to reduce V1 liquidity pressure, address high transaction fees, and eliminate friction from inefficient lending rate oracles by updating LendingPool and LendingPoolCore implementations.

Type
protocol deprecation

Key changes

  • Disable ability to open new stable rate borrowing positions on Aave V1(high)
  • Update rebalanceStableRate() function to enforce automatic migration from stable to variable rates during high borrowing pressure(high)
  • Execute disableReserveStableBorrowRate() across all V1 protocol assets(high)

Notable concerns

  • Existing stable rate borrowers will be forced to variable rates under high borrowing pressure conditions
  • V1 users experience high transaction fees that will not be directly addressed
  • Relies on users migrating to V2 which requires additional action from users
ContractsLendingPool (V1)LendingPoolCore (V1)All V1 reserve assets
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

353 words

AIP rationale

The Aave Protocol V2 was launched in Dec 2020 and is now concentrating the majority of the Aave protocol Liquidity Aave V1 users have the option to upgrade their position seamlessly into V2 with the native Aave migration tool

With significant reserves in, the community has the opportunity to implement a plan to transition the remaining reserves from V1 to v2. The community has the opportunity to bring about this change to ease the borrowing pressure on V1, to address high transaction fees that exist now, and may increase further upon the implementation of Berlin hardfork. The migration can benefit not only Aave users, but also the Aave ecosystem as a whole because it will allow protocols integrating with Aave to have additional stablecoins liquidity available(due to the ecosystem wide stablecoin liquidity crush).

Besides the beneficial effects on the migration procedure, disabling the stable rate borrowing overcomes the friction generated by the inefficient lending rate oracle V1, which currently proposes rates that are too low for the current market conditions. This has generated a consistent amount of stable rate debt, which results in frictions for the V1 liquidity providers and integrators that still rely on Aave V1 for their deposits.

If this proposal is approved by the Aave governance, new stable rates loans positions will be disabled for Aave V1.

The rebalancing mechanism will also be updated to an enforced swap to variable rates. Which means, in case of extremely high borrowing pressure on the stablecoins reserves, users at stable rate will be migrated to variable until rebalancing conditions are not satisfied anymore.

AIP content in short

Deactivation of the ability to open new stable rate borrowing positions on Aave V1 and update of the rebalance mechanism

Implementations details

Executes the proposal deployed at

https://etherscan.io/address/0x6a46c03c861cab74c8a213983b7eb295234c16b3#code

The proposal executes the following:

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal follows the standard Aave governance pattern: the only decoded on-chain action is a parameterless execute() call to a separately deployed executor contract. The actual mechanics described in the prose (updating LendingPool and LendingPoolCore implementations, disabling stable borrow rates on all V1 reserves) are expected to be hard-coded inside that executor contract's bytecode, which is not exposed by the decoded calldata provided here. Because the calldata gives no arguments or sub-calls to compare against the specific claims in the description, I cannot verify or refute the individual implementation addresses or the disableReserveStableBorrowRate calls. However, this opacity is typical for this proposal type and is not itself evidence of a mismatch—there is no contradictory data in the decoded action, only an absence of detail. Given the inability to cross-check specifics, confidence is low, but since nothing in the available calldata conflicts with the description, I record the assessment as consistent rather than flagging an unverifiable claim as a discrepancy. If a full trace or sub-call decode of the executor were available, a more thorough comparison would be possible.

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
#0execute()chain 0x1
Target
0x6a46…16b3
Value
0 wei
Function
execute()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters74
VP participating517.6K
Outcome (current)For
Current support99.9%

06Voters

74 total
Filter:
VoterChoice% of totalRationale
DD0xdd70…8202For183.5K35.46%—6y ago
9B0x9b5e…0499For100.7K19.45%—6y ago
A30xa3f0…b233For63.6K12.29%—6y ago
DB0xdb5a…a48eFor52.5K10.14%—6y ago
3C0x3cb9…d491For36.7K7.08%—6y ago
4B0x4bf0…40fcFor31.6K6.10%—6y ago
700x704d…a0dfFor19.8K3.83%—6y ago
800x80dc…c146For14.8K2.85%—6y ago
970x9757…e331For4.1K0.78%—6y ago
600x6001…887aFor2.1K0.41%—6y ago
FA0xfa61…1f5cFor1.4K0.27%—6y ago
F50xf569…271bFor1.1K0.22%—6y ago
D20xd29f…1e5fFor1K0.19%—6y ago
7B0x7bfe…c060For657.10.13%—6y ago
500x5066…3ac1For500.40.10%—6y ago
C40xc436…bb5fFor4930.10%—6y ago
200x20f3…f044For329.60.06%—6y ago
DF0xdf33…bb49For298.50.06%—6y ago
C10xc179…8ccaAgainst2510.05%—6y ago
820x82bb…f7c2Against250.80.05%—6y ago
6F0x6fb5…3744For2260.04%—6y ago
F40xf4f5…52eaFor209.90.04%—6y ago
990x9965…d279For2060.04%—6y ago
1F0x1f2e…d90aFor196.30.04%—6y ago
2C0x2c68…54cdFor150.30.03%—6y ago
AD0xad91…8ab0For1500.03%—6y ago
960x96b0…ec7cFor1290.02%—6y ago
D50xd53a…03a1For103.50.02%—6y ago
1A0x1a68…b9f1For1000.02%—6y ago
AB0xabe7…ae28For72.10.01%—6y ago
8D0x8d07…a265For500.01%—6y ago
120x125f…f4ebFor45.10.01%—6y ago
1D0x1de1…9255For43.70.01%—6y ago
3A0x3adb…0facFor37.10.01%—6y ago
7E0x7e86…e3c5For35.60.01%—6y ago
B30xb31e…4012For25.10.00%—6y ago
430x43b3…b9b0For250.00%—6y ago
CB0xcbd9…1b9bFor17.60.00%—6y ago
270x2713…d6e5For14.70.00%—6y ago
690x69fe…0790For14.50.00%—6y ago
280x287e…34ddFor14.10.00%—6y ago
260x2627…d050For12.40.00%—6y ago
BB0xbb95…6e87For8.50.00%—6y ago
5A0x5a2e…bc4cFor7.80.00%—6y ago
540x54f3…8967For7.50.00%—6y ago
410x4167…100dAgainst7.30.00%—6y ago
710x7136…11caAgainst6.30.00%—6y ago
440x44fa…bd0dFor4.60.00%—6y ago
4C0x4c37…8011For4.50.00%—6y ago
320x32ca…c384For4.10.00%—6y ago
Showing 50

07Forum

No forum thread is confidently linked to this proposal.