Update PriceOracleSentinel
01Summary
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
Generated by Kvorum
02Description
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
- Implementation: AaveV3Optimism, AaveV3Arbitrum, AaveV3Metis, AaveV3Base
- Tests: AaveV3Optimism, AaveV3Arbitrum, AaveV3Metis, AaveV3Base
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
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
04Actions
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "10", "1", "0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4", "6" ] }- Calldata
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "42161", "1", "0x89644CA1bB8064760312AE4F03ea41b05dA3637C", "5" ] }- Calldata
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "1088", "1", "0x2233F8A66A728FBa6E1dC95570B25360D07D5524", "3" ] }- Calldata
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "8453", "1", "0x2DC219E716793fb4b21548C0f009Ba3Af753ab01", "2" ] }- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedPrice feeds operational update78%
- aaveexecutedAlter mUSD Oracle Price Implementation70%
- aaveexecutedPrice feeds operational update Pt2 - stETH70%
- aaveexecutedUpdate xSushi price feed on Aave V268%
- aaveexecutedSet Price Cap Adapters for Aave V266%
- aaveexecutedEnable SVR V1 on Aave V3 Ethereum66%
- aaveexecutedMKR and USDtb oracle adjustments66%
- aaveexecutedPrices operational update. Unify disabled fallback oracles65%
- aaveexecutedSet Price Cap Adapters (CAPO)65%
- aaveexecutedFixed REP price feed on AAVE v164%