KVORUM
aaveSource: Aave governance v3 · #53

v3 Periphery maintenance

executedMar 24, 2024, 12:17 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Technical maintenance proposal for Aave v3 on Scroll that enables the Sequencer Uptime Feed (price oracle sentinel) to pause liquidations during sequencer downtime, and upgrades stataToken and stataFactory implementations to fix a maxMint function bug for reserves without supply caps and patch a permit griefing vulnerability.

Type
contract upgrade

Key changes

  • Enable Sequencer Uptime Feed on Scroll by setting new PriceOracleSentinel implementation via POOL_ADDRESSES_PROVIDER.setPriceOracleSentinel()(high)
  • Fix stataToken maxMint function to prevent reversion for reserves without supplyCap(medium)
  • Patch stataToken permit griefing vulnerability by upgrading to OpenZeppelin ECDSA library(medium)
  • Upgrade all existing stataToken implementations to latest version(medium)
  • Upgrade all existing stataFactory implementations to latest version(medium)
ContractsPriceOracleSentinelstataTokenstataFactoryPoolAddressesProvider
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

310 words

Simple Summary

Purely technical proposal to do minor improvements on two Aave v3’s periphery components: stataTokens and Sequencer Uptime Feed on Scroll (also known as PriceOracleSentinel).

Motivation

Price oracle sentinel

The Sequencer Uptime Feed (also known as “price oracle sentinel”) is a feature baked into Aave v3 that pauses liquidations & borrowing for a limited amount of time whenever a sequencer downtime is detected on a Chainlink oracle (l2 sequencer feed).

This pause should give users the ability to refill or repay their positions in case the market moved while the sequencer was down.

As the Chainlink Scroll l2 sequencer feed was not yet available when the pool launched, the Sequencer Uptime Feed on Aave was disabled until now.

Stata tokens

In our continuous effort to enhance the security of the aave protocol and the surrounding ecosystem we discovered some minor issues with the Static a token implementation.

  • For reserves without a supplyCap the maxMint function on the static aToken would revert. While there is currently no reserve without a supplyCap on any network, we think it’s reasonable to fix the issue to prevent unforeseen issues for integrators in the future.
  • Similar to an issue fixed on the aave core, the static-a-token is prone to permit griefing. While there is no financial incentive for an attacker to perform griefing, we used the upgrade to close the griefing vector & upgrade the token to rely on the open-zeppelin ECDSA library.

Specification

Upon execution, the proposal will call

  • POOL_ADDRESSES_PROVIDER.setPriceOracleSentinel(NEW_PRICE_ORACLE_SENTINEL) on the addresses provider contract and set the new implementation of the PriceOracleSentinel contract on Aave V3 Scroll
  • upgrade(token, NEW_TOKEN_IMPLEMENTATION) for all the existing stata tokens
  • upgrade(token, NEW_FACTORY_IMPLEMENTATION) for all the existing stata factories

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The decoded calldata contains only one top-level action: a parameterless execute() call to a contract address, which is the typical pattern for Aave/BGD governance proposals — the actual multi-step logic (setPriceOracleSentinel, stataToken upgrades, factory upgrades) lives inside the payload contract's bytecode and is invoked via delegatecall, not surfaced as separate decoded actions in this dataset. Because the calldata trace does not expose the internal calls, I cannot verify specific parameters (target addresses for setPriceOracleSentinel, which tokens are upgraded, or the new implementation addresses) against the prose description. This is a common, expected structure for this proposal type and not itself indicative of a mismatch, but it also means a granular comparison of values (e.g., correct oracle sentinel address, correct token list) is not possible from the given data. Given the lack of decoded detail, confidence in this assessment is low, and per instructions I am not flagging speculative discrepancies. The single high-level action is directionally consistent with the description's claim of a payload executing periphery maintenance changes.' (no discrepancies flagged due to insufficient calldata granularity)

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
0xaddb…1f74
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.