BGD. Technical maintenance proposals

Development
1

TL;DR

A unified forum thread for the community to have better visibility on technical maintenance updates coming from BGD.


Context

With Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is necessary to do maintenance tasks related to infrastructure consistency.

In the past, this has been done in ad-hoc governance posts within other forum threads (e.g. HERE), explaining the rationale of each change. But we believe it is more convenient to have a dedicated thread like this, oriented to these maintenance tasks.

Historically, whenever some of these maintenance tasks are minor or routinary, we have proceeded directly to the AIP stage, given that the Snapshot step doesn’t really give value. Examples of this are the following:

Even if we believe this has been acceptable, the visibility for the community has not been ideal in our opinion.


Which proposals belong here?

Only proposals that don’t create any kind of community division or are purely technical maintenance will be included in this thread. Examples of these are:

  • Updating addresses of price feeds if Chainlink recommends so, due to deprecation or optimisation of those in production.
  • Oracle changes required due to the off-boarding of assets. In some cases, assets are deprecated or migrated by their community, and this implies changes in the feeds pricing them.
  • Purely consistency-oriented updates, like the aforementioned proposal to unify fallback oracles to address(0)

How will proposals be presented?

For every maintenance update, we will create a separate post containing the same structure as the AIP description, which always shows both a high-level overview of what the proposal does and its technical specifications.

An example of this description can be found HERE.



Regarding timing, in order for the community to have time to comment on it, we always leave the proposal 3 days on this forum before creating the AIP.

Even if we will only submit in this thread purely operational updates, if the community has any concerns about one of them, we will revert back to the more strict ARFC + AIP procedure.


Next steps

As this is a continuous task, the following step will be the creation of the first maintenance update, which we will describe in its specific post.

2 Likes
2

Deprecate REP/ETH price feed on Aave v1

Summary

Replace the existing REP/ETH price feed by Chainlink on Aave v1 Ethereum with a fixed price adapter.

Motivation

The REP asset listed on Aave 1 Ethereum is a legacy one, that long time ago has suffered a token migration.

With a total supply of this legacy REP on Aave v1 of less than $100, Chainlink is looking to shut down the REP/ETH price feed, but this can only be done if Aave stops using it.

Consequently, given the size of the asset and that factually is off-boarded (frozen), we propose to replace the Chainlink price feed with an ad-hoc one that will return a constant value: the average price of the token for the period from 01/09/2023 till 31/10/2023.

Specification

Average REP price to use: 0.0004625695693 ETH

Actions:

  • call IAaveOracle(AAVE_V1_ORACLE).setAssetSources([0x1985365e9f78359a9B6AD760e32412f4a445E862], [0xc7751400F809cdB0C167F87985083C558a0610F7]) to replace the price feed of the REP on the Aave v1 Ethereum Pool.
1 Like
3

Activate FreezingSteward on v3 missing networks

Summary

Activates the FreezingSteward smart contract across all the networks of the protocol, which allows the emergency admin to freeze reserves, as expected.

Currently, there are freezing stewards live for all the networks except Avalanche, Metis, and Base, and this proposal synchronizes the missing ones.

Motivation

This is a follow-up to AIP-319 where on some networks (Avalanche, Metis, and Base) the proposal wasn’t executed. We now resubmit the proposal as an operational update to maintain security and consistency across Aave V3.

Specification

Adds the FreezingSteward contract as RISK_ADMIN on the canonical Aave V3 deployments on the following networks:

  • Avalanche.
  • Metis.
  • Base.

The FreezingSteward is identical to the one currently deployed on Ethereum, Polygon, Optimism, Arbitrum and only allows for entities holding EMERGENCY_ADMIN role on ACLManager to freeze reserves.

2 Likes
4

Following the timeline, both previous proposals have been create, with voting starting in approximately 24 hours.

Deprecate REP/ETH price feed on Aave v1
https://app.aave.com/governance/proposal/?proposalId=364

Activate FreezingSteward on v3 missing networks
https://app.aave.com/governance/proposal/?proposalId=363

Participate :ghost:

2 Likes
5

Allow emergencyAdmin to freeze on Aave V2, as on V3


Summary

Proposal to allow the emergencyAdmin role to freeze reserves on Aave V2 pools - including Aave V2 AMM, Aave V2 Ethereum, Polygon, and Avalanche; same behavior as on Aave v3.

Additionally, the Liquidations Grace Sentinel is activated for Aave V2 AMM, following the same approach as AIP 361


Motivation

To be consistent with the approved Aave v3 approach of Freezing Stewards (AIP 319), and maintain security across all Aave V2 deployments, the protocol needs to have up-to-date preventative functionality.

Freezing is a less invasive mechanism compared with pause, which can already be done by the emergencyAdmin on v2.


Specification

The proposal payloads will update the freezeReserve()/unfreezeReserve() functions on the pool configurator contract to use the new onlyPoolOrEmergencyAdmin modifier, which allows both the emergency admin (Aave Guardian) and pool admin (governance Executor contract) to freeze and unfreeze reserves.

On AaveV2Ethereum, AaveV2EthereumAMM, AaveV2Polygon and AaveV2Avalanche the proposal will call:

POOL_ADDRESSES_PROVIDER.setLendingPoolConfiguratorImpl(NEW_POOL_CONFIGURATOR)

To update the pool configurator with the new implementation.


In addition LendingPoolCollateralManager for Aave V2 AMM is updated analog to AIP 361.

1 Like
6

Freeze price feeds on v3 Harmony following shutdown of Harmony services by Chainlink


Summary

Following Chainlink’s Harmony deprecation, replace all existing price feeds by Chainlink on Aave v3 Harmony with fixed price adapters (with the last known Chainlink price).

Additionally, update interest rate strategies to one with exact zero values.


Motivation

As Harmony remains unstable following the bridge exploit, and Chainlink is planning to shut down all the price feeds on the network, we believe that the most neutral solution (since there are still users who can withdraw) is to replace the Chainlink feeds with fixed adapters that return the last available price.

Additionally, since the pool dynamics are non-functional, accruing any debt makes no difference, even if it was already set to minimal. Therefore, we are going to replace the interest rate strategies for every asset with a zero-interest one.


Specification

  • Call AaveV3Harmony.ORACLE.setAssetSources() passing the appropriate parameters to replace the price feeds of the assets on the Aave v3 Harmony Pool.
  • For each asset on the pool, call PoolConfigurator.setReserveInterestRateStrategyAddress(asset, zeroInterestRateStrategy) to replace their rate strategy.

1 Like
7

Following the timeline, both previous proposals have been create, with voting starting in approximately 24 hours.

Allow emergencyAdmin to freeze on Aave V2, as on V3
https://app.aave.com/governance/proposal/?proposalId=386

Freeze price feeds on v3 Harmony following the shutdown of Harmony services by Chainlink
https://snapshot.org/#/aave.eth/proposal/0x6dcd1bec49cc196c02c53746f5d63a96044eb476a9320120aa1fe773c7b47502

Participate :ghost:

2 Likes
8

Sync implementation of L2 PriceOracleSentinel across all networks


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.


1 Like
9

Following the timeline, we have created proposal 391 to Sync the implementation of L2 PriceOracleSentinel across all networks, with voting starting in approximately 24 hours.

https://app.aave.com/governance/proposal/?proposalId=391

Participate :ghost:

10

Sync emergency admin on deprecated v2 AMM


Summary

This proposal aligns the emergency admin address on the deprecated Aave v2 AMM pool with the one of Aave v2 and v3 Ethereum.


Motivation

During an internal security review procedure of Aave, we detected that the emergency admin on Aave v2 AMM is a legacy address, not aligned with the Aave Guardian.

Even if the v2 AMM pool is deprecated (frozen) and almost off-boarded, for hygiene we think it is appropriate to have consistency on all Aave instances in the same network, and simpler for operations.


Specification

Upon execution, the proposal will call setEmergencyAdmin(0xCA76Ebd8617a03126B6FB84F9b1c1A0fB71C2633) on the addresses provider contract of v2 AMM, passing the address of the Aave Ethereum Guardian.


11

Activate Aave Proof of Reserve on Aave v2 Avalanche


Summary

Activation of the Aave Proof of Reserve system into Aave v2 Avalanche, to be aligned with Aave v3 Avalanche, even if the v2 pool is slowly getting deprecated in favor of v3.


Motivation

In the past, Aave Proof of Reserve was activated on Aave v3 Avalanche. Due to extra complexity on permissions and cross-chain governance not previously applied to Aave Avalanche, v2 Proof of Reserve was not enabled.

For consistency of the codebases/behavior and to facilitate operational analysis, enabling the system on v2 Avalanche is still reasonable.


Specification

Upon execution, the proposal will call setLendingPoolConfiguratorImpl(NEW_CONFIGURATOR) on the addresses provider contract of v2 Avalanche, passing the address of an upgraded LendingPoolConfigurator which allows the Proof of Reserve system to execute protective actions like freezing or halting borrowing.

In addition setAddress() will be called on the addresses provider of v2 Avalanche, to register the address of the Proof of Reserve Executor contract, to have the aforementioned protective permissions.


1 Like
12

We can confirm that both these proposal have been executed:

1 Like