KVORUM
aaveSource: Aave governor v2 · #359

Multichain Stable Debt Token Upgrades

executedNov 10, 2023, 02:01 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal updates stable debt token implementations across Aave V2 Ethereum and Aave V3 (Arbitrum, Optimism, Avalanche, Polygon) to prevent new minting of stable debt tokens in response to a reported white-hat attack vector.

Type
contract upgrade

Key changes

  • Update stable debt token implementation on AaveV2Ethereum via updateStableDebtToken()(high)
  • Update stable debt token implementation on AaveV3Arbitrum via updateStableDebtToken()(high)
  • Update stable debt token implementation on AaveV3Optimism via updateStableDebtToken()(high)
  • Update stable debt token implementation on AaveV3Avalanche via updateStableDebtToken()(high)
  • Update stable debt token implementation on AaveV3Polygon via updateStableDebtToken()(high)
  • Prevent new minting of StableDebt tokens across all affected pools and networks(high)

Notable concerns

  • Implementation addresses security vulnerability reported by white-hat
  • Proposal follows emergency measures (pausing, freezing, disabling stable borrowing) already taken on affected assets
  • Affects all tokens with stable debt across multiple networks and versions
ContractsAaveV2Ethereum.POOL_CONFIGURATORAaveV3Arbitrum.POOL_CONFIGURATORAaveV3Optimism.POOL_CONFIGURATORAaveV3Avalanche.POOL_CONFIGURATORAaveV3Polygon.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

155 words

Simple Summary

This proposal updates the stable borrow implementations for all tokens that have stable debt across all pools on all networks. The implementation will effectively stop minting new stable debt tokens.

Motivation

In response to an attack vector reported by a white-hat, some immediate steps where taken to protect the Aave Pools by pausing, freezing, and disabling stable borrowing on the affected assets.

Upon further investigation it turned out to be necessary to also prevent new minting of StableDebt.

Specification

On AaveV2Ethereum the proposal will call:

  • AaveV2Ethereum.POOL_CONFIGURATOR.updateStableDebtToken(underlyingAsset,newSTokenImpl);

On AaveV3Arbitrum, AaveV3Optimism, AaveV3Avalanche, AaveV3Polygon the proposal will call:

  • POOL_CONFIGURATOR.updateStableDebtToken(input);

The proposal has been tested by BGD Labs and reviewed by Aave Companies and Certora.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumclaude-sonnet-5
Consistent

The proposal's top-level calldata consists of five calls to the standard Aave cross-chain governance bridge (forwardPayloadForExecution), each targeting a distinct chain ID (1, 137, 43114, 10, 42161) that correspond exactly to the five networks named in the description: Ethereum, Polygon, Avalanche, Optimism, and Arbitrum. Each call forwards a payload identifier and access level to a chain-specific contract address, which is the well-known BGD Labs pattern for executing network-specific governance payloads (the actual `updateStableDebtToken` calls happen inside those forwarded payload contracts, as documented in the referenced implementation and test links for each network). The description's Specification section accurately describes the ultimate on-chain effect on each network, and the number and ordering of calls (one per network) matches the calldata exactly, with no extra chains, missing chains, or altered targets. There are no numeric parameters to compare (no percentages or amounts), so value_mismatch is not applicable. No unexplained extra actions (e.g., fund transfers, role grants) are present. Given the well-documented nature of this cross-chain forwarding mechanism and the clean 1:1 mapping between description and calldata, I assess this proposal as consistent with high confidence.

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

04Actions

5 total
#0forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "1",
    "1",
    "0xdAbad81aF85554E9ae636395611C58F7eC1aAEc5",
    "5"
  ]
}
Calldata
#1forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "137",
    "1",
    "0x401B5D0294E23637c18fcc38b1Bca814CDa2637C",
    "1"
  ]
}
Calldata
#2forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "43114",
    "1",
    "0x1140CB7CAfAcC745771C2Ea31e7B5C653c5d0B80",
    "1"
  ]
}
Calldata
#3forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "10",
    "1",
    "0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4",
    "1"
  ]
}
Calldata
#4forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "42161",
    "1",
    "0x89644CA1bB8064760312AE4F03ea41b05dA3637C",
    "1"
  ]
}
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.