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.

3 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.
3 Likes
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.

3 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:

3 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.

2 Likes
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.

3 Likes
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.


2 Likes
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
13

We have created proposal 401 for the previously announced Sync emergency admin on deprecated v2 AMM.

Voting will start in approximately 24 hours, participate :ghost:

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

1 Like
14

We have created proposal 402 for the previously announced Activate Aave Proof of Reserve on Aave v2 Avalanche.

Voting will start in approximately 24 hours, participate :ghost:

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

1 Like
15

Register a.DI Scroll adapter


Summary

Proposal to register the Scroll adapter on Ethereum a.DI, a technical requirement for an activation vote of Aave v3 Scroll.


Motivation

In order to be able to pass messages from Ethereum to Scroll via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → Scroll smart contract enabled in the system.

The first case of message passing Ethereum → Scroll is the activation proposal for an Aave v3 Scroll pool and consequently, to be able to execute on the Scroll side the payload, the Aave governance should approve in advance the a.DI adapter smart contract.

This procedure was not required on previous activations like BNB, given that their adapter were pre-configured on the initial a.DI release, but will be needed going forward.


Specification

The proposal payload simply registers a pre-deployed Scroll adapter (with the necessary configurations to communicate with the Scroll a.DI) on the Ethereum a.DI instance.

This is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.


4 Likes
16

We have created proposal gov v3 #12 for the previously announced Register a.DI Scroll adapter.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=12

6 Likes
17

Migration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage


Simple Summary

Migrate Aave Arc pool permissions & Paraswap positive slippage funds allocated to the old governance v2 Short Executor.


Motivation

In November 2022 a permissionless contract was introduced to collect positive slippage from Paraswap swaps to the Aave Collector, gained on features like collateral swap, debt swap or repay with collateral. While this system is well and active since then there are some funds (~100k) pending to claim from the previous system which still need migration.

Additionally, when Governance v3 was introduced, some permissions for the deprecated Aave Arc pool were not migrated to the new governance system. For proper hygiene and permissions alignment, this should still be done.


Specification

On Ethereum & Polygon the proposal calls:

  • pspclaimer.batchWithdrawAllERC20(assets, collector) to claim pending rewards to the collector

The proposal will also authorise the Aave Guardian to do the claim to the Collector on the other applicable networks

On Ethereum the proposal also queues a call to:

  • arcTimelock.updateEthereumGovernanceExecutor(GovernanceV3Ethereum.EXECUTOR_LVL_1)
5 Likes
18

We have created proposal Gov v3 #22 for the previously announced Migration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=22

2 Likes
19

POOL_ADMIN renounceRole() by Guardian on new pools

Simple Summary

After some maturity time, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role on relatively new pools: Metis, Base, Gnosis and BNB Chain.

Motivation

Whenever Aave expands to a new network, this is done in a fully decentralised way via an on-chain governance proposal (e.g. Aave v3 BNB Chain).
Major permissions (upgradeability) of the pool are set to the Aave governance from day 0, but the POOL_ADMIN is given to the Aave Guardian during a period of time for security, even if almost never exercised.
From a technical/security perspective, we don’t see any risk at the moment or need for the Guardian to hold this role anymore, so we will coordinate with its members to renounce on all applicable pools: all apart from Scroll.
From now on, we think that after 1-month of the activation of a pool, it should always be safe enough for the Guardian to renounce to POOL_ADMIN, on any upcoming pool.

Specification

This proposal doesn’t require any governance procedure (Snapshot, on-chain), as the renounce is done directly by the Guardian.

Each instance of the Aave Guardian (Safe) will call the renounceRole() function for the POOL_ADMIN and their own address.

2 Likes
20

v3 Periphery maintenance proposal



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).

As both proposals are purely technical nature, we will batch them together in a single AIP.



Motivation


Scroll Sequencer uptime feed

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.


stataTokens

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


Scroll Sequencer uptime feed

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.


stataTokens

Upon execution, the proposal will call upgrade(token, NEW_TOKEN_IMPLEMENTATION) for all the existing tokens and upgrade(token, NEW_FACTORY_IMPLEMENTATION) for all the existing factories.

4 Likes