KVORUM
aaveSource: Aave governor v2 · #230

Fix rate strategies issue on Aave v2 Polygon

executedMay 23, 2023, 09:12 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal fixes a compatibility issue on Aave v2 Polygon caused by Proposal 224. It replaces the interest rate strategy contracts for WETH, WBTC, WMATIC, and USDT with new versions that include the required interface function for v2 Polygon compatibility. The interest rate parameters remain unchanged; only the contract implementation is updated to restore functionality to these assets.

Type
contract upgrade

Key changes

  • Replace interest rate strategy contract for WETH with v2 Polygon compatible version(high)
  • Replace interest rate strategy contract for WBTC with v2 Polygon compatible version(high)
  • Replace interest rate strategy contract for WMATIC with v2 Polygon compatible version(high)
  • Replace interest rate strategy contract for USDT with v2 Polygon compatible version(high)
  • Add calculateInterestRates function to all four rate strategy contracts to ensure LendingPool compatibility(high)

Notable concerns

  • Proposal 224 created incompatible rate strategy contracts on v2 Polygon that prevented user actions on WETH, WBTC, WMATIC, and USDT
  • User actions were reverting due to missing required interface function in the rate strategy contracts
ContractsWETH interest rate strategy (Aave v2 Polygon)WBTC interest rate strategy (Aave v2 Polygon)WMATIC interest rate strategy (Aave v2 Polygon)USDT interest rate strategy (Aave v2 Polygon)POOL_CONFIGURATOR (Aave v2 Polygon)
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

389 words

Simple Summary

This proposal fixes an issue created by proposal 224 on WETH, WTBC, USDT and WMATIC of Aave v2 Polygon, by connecting new rate strategy contracts with exactly the same approved parameters on 224, but this time fully compatible with v2 Polygon.

Motivation

Proposal 224 updated the interest rate strategies of different assets on Aave v2 Ethereum and Polygon. Even if this worked perfectly fine on Ethereum, due to legacy reasons, Aave v2 Polygon requires slightly different interface on the rates strategy contracts, for them to be compatible with the LendingPool. The new rate strategies connected on proposal 224 for WETH, WMATIC, WBTC and USDT lacked this compatibility, which doesn't allow for user actions to be performed, when involving those assets. Even if not putting any funds at risk, this is a problem for users and integrators of Aave v2 Polygon, so this new proposal applies a patch.

Specification

This is a cross-chain governance proposal, targeting Aave v2 Polygon.

Upon execution, the proposal will:

  • call POOL_CONFIGURATOR.setReserveInterestRateStrategyAddress(ASSET) for each of the assets WETH, WBTC, WMATIC and USDT, on Aave v2 Polygon

Security and additional considerations

The following verification/test have been made on this proposal:

  • Diff reports on configuration parameters of all Aave v2 Polygon listed assets: everything should be exactly the same as before, as parameters don't change; only the Solidity code of the interest rate strategies.

  • Diff reports on the Solidity code of the new interest rate strategies, to check that compared with the current interest rate strategies of the affected assets (wrong), the new ones have an extra function, which is the required by the LendingPool:

function calculateInterestRates(
    address reserve,
    address aToken,
    uint256 liquidityAdded,
    uint256 liquidityTaken,
    uint256 totalStableDebt,
    uint256 totalVariableDebt,
    uint256 averageStableBorrowRate,
    uint256 reserveFactor
  ) external view override returns (uint256, uint256, uint256)
  • Post-execution actions tests, more specifically supplying liquidity on WETH, WBTC, WMATIC and USDT. The revert() caused by proposal 224 boils down to ReserveLogic.updateInterestRates(), function used on all pool actions to retrieve the current rate from the rate strategy. deposit() working implies the logic of calling the new rate strategy works for all actions.

References

Proposal 224 creating the problem

https://app.aave.com/governance/proposal/224/

Disclosure of the issue

https://governance.aave.com/t/arfc-aave-v2-interest-rate-curve-recommendations-from-gauntlet-2023-04-21/12846/11

Tests

https://github.com/bgd-labs/aave-proposals/blob/main/src/AaveV2PolygonIR_20230519/AaveV2PolygonIR_20230519.t.sol

Diffs

https://github.com/bgd-labs/aave-proposals/tree/main/src/AaveV2PolygonIR_20230519/current-new.md

Proposal payload (Polygon)

https://github.com/bgd-labs/aave-proposals/blob/main/src/AaveV2PolygonIR_20230519/AaveV2PolygonIR_20230519.sol

Payload: 0x7e1f23bdFc7287AF276F77B5A867e85cf0377a31

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal is a standard cross-chain Aave governance action: the mainnet vote triggers a single execute(address) call on the cross-chain controller/executor, passing the address of the Polygon payload contract. This decoded action's target payload address (0x7e1f23bdFc7287AF276F77B5A867e85cf0377a31) exactly matches the address explicitly cited in the description under 'Proposal payload (Polygon)'. The description's specification of four setReserveInterestRateStrategyAddress calls (for WETH, WBTC, WMATIC, USDT) is expected to be encoded inside that payload contract's own execute logic, which is not separately decoded here — this is normal for cross-chain proposals where only the dispatch call is visible on the origin chain. Since the address matches precisely and no other on-chain action is present that could indicate a different target or additional undisclosed effect, there is no evidence of a mismatch. Confidence is medium rather than high because the actual sub-actions inside the Polygon payload (the four rate-strategy updates) are not independently visible in the decoded calldata provided, so full verification of the specific asset-level changes cannot be performed from this data 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

1 total
#0execute(address)chain 0x1
Target
0x158a…d45b
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x7e1f23bdFc7287AF276F77B5A867e85cf0377a31"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

AIForum synthesis by Kvorumclaude-haiku-4-5
sentiment · favorablethread · mixed

Arguments for

  • Adjusting interest rate parameters can mitigate the risk of 100% utilization in pools by motivating borrowers to repay and suppliers to deposit more, improving UX and reducing liquidation risks.— wfu
  • Interest rate curve changes can increase protocol revenue through reserve building when market conditions are favorable, without materially impacting risk.— wfu
  • The proposed stablecoin parameter adjustments (USDP, FRAX, USDT, GUSD) address observed utilization spikes and are justified by elasticity models showing suppliers respond to rate increases.— wfu, PennBlockchain
  • Lowering interest rates on high-liquidity non-stablecoin assets (WETH, WBTC, WAVAX, WMATIC) encourages borrowing and increases protocol revenue without materially increasing risk.— wfu, PennBlockchain
  • The elasticity-based methodology with counterfactual utilization analysis provides a data-driven framework for parameter optimization across multiple chains.— wfu, PennBlockchain
  • Parameter changes support yield-maximizing strategies for native network tokens like WMATIC, which are needed to offset risk and justify user participation.— Llamaxyz

Arguments against

None surfaced.

Unresolved concerns

  • The specification table submitted with the snapshot vote contained inconsistencies (WETH Variable Base change and inaccurate stable borrowing parameters) that differed from the original forum post, creating confusion about the actual proposed changes.— Pauljlei
  • Supply cap considerations for preferred collateral assets like stMATIC and MaticX were not addressed in the proposal despite their importance for enabling native token yield strategies.— Llamaxyz
  • Whether Aave V2 and V3 interest rate parameters should remain aligned or whether V3 should receive more competitive rates to encourage migration was not fully resolved.— Llamaxyz

Notable participants

  • wfuGauntlet representative who authored the proposal with detailed methodology, elasticity analysis, and token-specific recommendations.
  • PauljleiGauntlet team member who coordinated voting, acknowledged specification inconsistencies, and decided to proceed with the AIP based on the original forum post.
  • LlamaxyzCommunity member who raised concerns about supply caps for LST collateral and alignment between V2 and V3 parameter strategies.
  • bgdlabsBendingDAO Labs contributor who identified and coordinated the fix for a critical interface compatibility issue on Aave V2 Polygon after proposal 224 execution.
  • GauntletProtocol contributor who announced the on-chain AIP voting launch on May 11.
  • PennBlockchainFranklin DAO representative who expressed support for the proposal, endorsing the elasticity model and optimization approach.
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗