KVORUM
aaveSource: Aave governor v2 · #238

Update Mai Token implementations, unpause & enable flashloanable

executedJun 10, 2023, 10:54 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal upgrades the MAI token implementations on Optimism and Arbitrum to align with Aave 3.0.2, unpauses the MAI reserve, and enables flash loaning for MAI. The reserve was previously paused due to outdated implementations that prevented liquidations from functioning properly.

Type
contract upgrade

Key changes

  • Upgrade aToken implementation to Aave 3.0.2 on Optimism and Arbitrum(high)
  • Upgrade stableDebtToken implementation to Aave 3.0.2 on Optimism and Arbitrum(high)
  • Upgrade variableDebtToken implementation to Aave 3.0.2 on Optimism and Arbitrum(high)
  • Set MAI reserve flashloanable flag to true on Optimism and Arbitrum(high)
  • Unpause MAI reserve on Optimism and Arbitrum(high)

Notable concerns

  • MAI reserves on Optimism and Arbitrum were paused with approximately $8,000 total liquidity due to incompatible token implementations that prevented liquidations from functioning
  • The previous implementation lacked updated handleRepayment() signature from Aave 3.0.2 specification
ContractsMAI aToken (Optimism)MAI aToken (Arbitrum)MAI stableDebtToken (Optimism)MAI stableDebtToken (Arbitrum)MAI variableDebtToken (Optimism)MAI variableDebtToken (Arbitrum)POOL_CONFIGURATOR
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

209 words

Simple Summary

This proposal updates the MAI a/s/v token implementations on Optimism and Arbitrum to be aligned with Aave 3.0.2. It also unpauses the MAI reserve and sets it as flashloanable.

Motivation

In Aave v3.0.2 the signature of handleRepayment() has changed and a flashloanable flag was added. While all existing reserves a/s/v token implementations were upgraded in the original proposal and flashloanable was set to true on all reserves, shortly after, MAI was listed on the Optimism and Arbitrum pools using the old implementations and not setting flashloanable to true.

In the current state repayments of MAI could still work, as repayWithAToken is not affected, but liquidations wouldn't work as they rely on repay. To reduce risk, the Aave Guardian coordinated a pause for these mostly empty reserves (~$8'000 between Arbitrum and Optimism).

This proposal resolves the current issues by:

  • Upgrading the a/s/v token implementations.
  • Setting the flashloanable flashloanable flag to true.
  • Unpausing the reserve.

Specification

In order to align MAI with other tokens. The proposal executes the following commands:

  • POOL_CONFIGURATOR.updateAToken
  • POOL_CONFIGURATOR.updateStableDebtToken
  • POOL_CONFIGURATOR.updateVariableDebtToken
  • POOL_CONFIGURATOR.setReservePause(AaveV3ArbitrumAssets.MAI_UNDERLYING, false)
  • POOL_CONFIGURATOR.setReserveFlashLoaning(AaveV3ArbitrumAssets.MAI_UNDERLYING, true)

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal follows Aave's standard cross-chain governance pattern: the L1 proposal (target_chain_id 0x1 for both actions) simply calls execute(address) on two different executor/bridge contracts, each forwarding to a payload contract deployed on Arbitrum and Optimism respectively. This structurally matches the description, which references two separate payload contracts (ArbPayload and OptPayload) that each perform the token upgrades, flashloan flag update, and unpause. However, the decoded calldata provided does not expose the inner logic of those payload contracts (i.e., the actual updateAToken, updateStableDebtToken, updateVariableDebtToken, setReservePause, and setReserveFlashLoaning calls), so the specific parameter values and targets described in the Specification section cannot be fully cross-verified from this data alone. Given the well-known and audited nature of this two-step cross-chain execution pattern in Aave governance, and no evidence of any mismatched targets or amounts in what is visible, I assess this as consistent with medium confidence — the high-level structure aligns with the description, but full verification of inner payload actions would require decoding the target payload contracts' bytecode/calldata, which was not provided.

Discrepancies

  • lowomitted in description

    The decoded top-level calldata only shows two generic execute(address) calls to cross-chain governance executors, which in turn invoke separate payload contracts (referenced in the description as ArbPayload and OptPayload) containing the actual updateAToken/updateStableDebtToken/updateVariableDebtToken/setReservePause/setReserveFlashLoaning calls. Those granular actions are not directly visible in the provided decoded calldata, so they cannot be independently verified against the prose, though the two-payload structure (one per chain) matches the description's intent.

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

04Actions

2 total
#0execute(address)chain 0x1
Target
0x5f5c…6711
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x0c2C95b24529664fE55D4437D7A31175CFE6c4f7"
}
Calldata
#1execute(address)chain 0x1
Target
0xd1b3…cfa3
Value
0 wei
Function
execute(address)
Arguments
{
  "0": "0x9441B65EE553F70df9C77d45d3283B6BC24F222d"
}
Calldata

05Tally

Summed from votes

Voters11
VP participating549.1K
Outcome (current)For
Current support100%

06Voters

11 total
Filter:
VoterChoice% of totalRationale
320x329c…3ed4For232.2K42.29%—4y ago
070x0703…961bFor108.9K19.84%—4y ago
130x13bd…8548For81.8K14.90%—4y ago
B80xb83b…cf5cFor81.4K14.83%—4y ago
B90xb933…8dd1For41.7K7.59%—4y ago
180x1855…98baFor3K0.55%—4y ago
EA0xea17…6676For39.60.01%—4y ago
BB0xbbcb…ed9fFor1.70.00%—4y ago
2D0x2df2…b98aFor1.10.00%—4y ago
BF0xbfec…52f2For0.20.00%—4y ago
340x3411…8aa0For00.00%—4y ago
Showing 11

07Forum

No forum thread is confidently linked to this proposal.