KVORUM
aaveSource: Aave governor v2 · #391

Update PriceOracleSentinel

executedDec 7, 2023, 09:56 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal updates the PriceOracleSentinel implementation across Aave V3 on Arbitrum, Optimism, Base, and Metis to align their sequencer health check logic. OP stack networks will be standardized to only respond to sequencer status changes rather than 24-hour health check updates, matching Arbitrum's behavior and preventing unexpected downtime.

Type
contract upgrade

Key changes

  • Update PriceOracleSentinel implementation on Aave V3 Arbitrum to use new logic(medium)
  • Update PriceOracleSentinel implementation on Aave V3 Optimism to respond only to sequencer status changes instead of 24-hour health checks(high)
  • Update PriceOracleSentinel implementation on Aave V3 Base to align with corrected logic(medium)
  • Update PriceOracleSentinel implementation on Aave V3 Metis to align with corrected logic(medium)
  • Unify L2 sequencer feed behavior across all OP stack networks to match Arbitrum's approach(high)

Notable concerns

  • OP stack networks currently have different sequencer feed behavior than Arbitrum which could cause unexpected protocol downtime
ContractsPriceOracleSentinel (Arbitrum)PriceOracleSentinel (Optimism)PriceOracleSentinel (Base)PriceOracleSentinel (Metis)PoolAddressesProvider
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

130 words

Simple Summary

This proposal aligns the Aave PriceOracleSentinel in both Arbitrum and OP stack, to common and correct logic.

Motivation

Compared with Arbitrum, the L2Sequencer Chainlink feed on OP stack networks behaves differently: it updates every 24 hours as a health check, instead of only when the status (up or down) of the sequencer changes.

In order to be fully precise and avoid unexpected downtime, the approach should be unified across networks.

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 Arbitrum, Optimism, Base and Metis.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal describes updating the PriceOracleSentinel implementation via setPriceOracleSentinel calls on four networks: Arbitrum, Optimism, Base, and Metis. The decoded on-chain actions are four forwardPayloadForExecution calls from the L1 cross-chain governance controller, targeting chain IDs 10 (Optimism), 42161 (Arbitrum), 1088 (Metis), and 8453 (Base) — exactly matching the four networks named in the description. This is the standard Aave cross-chain governance pattern: the top-level L1 proposal only forwards payloads to L2/L3 executors, which then execute the actual setPriceOracleSentinel calls referenced in the linked implementation contracts (AaveV3Optimism_UpdatePriceOracleSentinel, AaveV3Arbitrum_UpdatePriceOracleSentinel, etc.). Since we cannot inspect the bytecode of the destination payload contracts from this calldata alone, we cannot verify the exact new sentinel address deployed on each chain, but the structure (four networks, correct chain IDs, standard forwarding mechanism, and references to per-network implementation contracts matching the four named networks) is fully consistent with what the description claims. No values, targets, or omitted/extra actions stand out as suspicious at this level of decoding. Confidence is medium because full verification would require decoding the sub-payloads on each L2, which are not included here.

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

04Actions

4 total
#0forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "10",
    "1",
    "0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4",
    "6"
  ]
}
Calldata
#1forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "42161",
    "1",
    "0x89644CA1bB8064760312AE4F03ea41b05dA3637C",
    "5"
  ]
}
Calldata
#2forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "1088",
    "1",
    "0x2233F8A66A728FBa6E1dC95570B25360D07D5524",
    "3"
  ]
}
Calldata
#3forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "8453",
    "1",
    "0x2DC219E716793fb4b21548C0f009Ba3Af753ab01",
    "2"
  ]
}
Calldata

05Tally

Summed from votes

Voters13
VP participating623.4K
Outcome (current)For
Current support100%

06Voters

13 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.