# Technical maintenance proposals **URL:** \ **Category:** Development\ **Created:** [October 30, 2023, 3:04pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274 "2023-10-30T15:04:01Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 30, 2023, 3:04pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/1 "2023-10-30T15:04:01Z")
## 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](https://governance.aave.com/t/bgd-operational-oracles-update/13213)), 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: - The [activation of the price oracle sentinel on Aave v3 Optimism](https://governance.aave.com/t/bgd-operational-oracles-update/13213#h-2-activate-price-oracle-sentinel-on-aave-v3-optimism-5). This is a mechanism part of Aave v3 itself, fully approved by the community. So the activation didn’t require any extra approval, apart from the always necessary on-chain AIP. - Factually [disable the already deprecated fallback oracles](https://governance.aave.com/t/bgd-operational-oracles-update/13213/13). In order to keep consistency with v3, set the addresses of all fallback oracles to `address(0)`. This is also a purely technical change, to reduce differences between Aave instances. 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](https://github.com/bgd-labs/aave-proposals/blob/main/src/AaveV2_Eth_UnifyFallbackOracles_20230507/UnifyFallbackOracles.md). * * * 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 31, 2023, 2:42pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/2 "2023-10-31T14:42:02Z")
## 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 2, 2023, 12:51pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/3 "2023-11-02T12:51:53Z")
## 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](https://app.aave.com/governance/proposal/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](https://etherscan.io/address/0x2eE68ACb6A1319de1b49DC139894644E424fefD6#code), [Polygon](https://polygonscan.com/address/0xa7b40ed4dfAC9255EA9Dd218A3874f380D9FbBEB), [Optimism](https://optimistic.etherscan.io/address/0x3829943c53F2d00e20B58475aF19716724bF90Ba), [Arbitrum](https://arbiscan.io/address/0xe59470b3be3293534603487e00a44c72f2cd466d) and only allows for entities holding `EMERGENCY_ADMIN` role on `ACLManager` to freeze reserves. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 8, 2023, 10:40am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/4 "2023-11-08T10:40:02Z")
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](https://app.aave.com/governance/proposal/?proposalId=364) **Activate FreezingSteward on v3 missing networks** [https://app.aave.com/governance/proposal/?proposalId=363](https://app.aave.com/governance/proposal/?proposalId=363) Participate 👻 ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 21, 2023, 4:40pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/5 "2023-11-21T16:40:22Z")
## 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](https://app.aave.com/governance/proposal/361/) ### Motivation To be consistent with the approved Aave v3 approach of Freezing Stewards ([AIP 319](https://app.aave.com/governance/proposal/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](https://app.aave.com/governance/proposal/361/). ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 22, 2023, 9:28am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/6 "2023-11-22T09:28:15Z")
## 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](https://docs.chain.link/data-feeds/price-feeds/addresses?network=harmony), 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 27, 2023, 2:34pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/7 "2023-11-27T14:34:51Z")
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](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](https://snapshot.org/#/aave.eth/proposal/0x6dcd1bec49cc196c02c53746f5d63a96044eb476a9320120aa1fe773c7b47502) Participate 👻 ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 30, 2023, 2:03pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/8 "2023-11-30T14:03:19Z")
## 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 3, 2023, 5:16pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/9 "2023-12-03T17:16:02Z")
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](https://app.aave.com/governance/proposal/?proposalId=391) Participate 👻 ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 5, 2023, 11:33am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/10 "2023-12-05T11:33:45Z")
## 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 7, 2023, 9:21am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/11 "2023-12-07T09:21:44Z")
## 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 8, 2023, 10:35am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/12 "2023-12-08T10:35:35Z")
We can confirm that both these proposal have been executed: - [386](https://app.aave.com/governance/proposal/?proposalId=386) has been executed via the Aave Governance smart contracts. - Being a deprecated pool without cross-chain governance, the Aave Guardian executed the Harmony price feeds freezing, as [pre-authorized on the Snapshot vote by Aave Governance](https://snapshot.org/#/aave.eth/proposal/0x6dcd1bec49cc196c02c53746f5d63a96044eb476a9320120aa1fe773c7b47502). ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 12, 2023, 10:44am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/13 "2023-12-12T10:44:15Z")
We have created proposal 401 for the previously announced _Sync emergency admin on deprecated v2 AMM_. Voting will start in approximately 24 hours, participate 👻 [https://app.aave.com/governance/proposal/?proposalId=401](https://app.aave.com/governance/proposal/?proposalId=401) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 12, 2023, 3:07pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/14 "2023-12-12T15:07:21Z")
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 👻 [https://app.aave.com/governance/proposal/?proposalId=402](https://app.aave.com/governance/proposal/?proposalId=402) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [January 24, 2024, 4:47am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/15 "2024-01-24T04:47:17Z")
## 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [January 29, 2024, 8:47am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/16 "2024-01-29T08:47:44Z")
We have created proposal gov v3 #12 for the previously announced _Register a.DI Scroll adapter_. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=12](https://vote.onaave.com/proposal/?proposalId=12) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [February 1, 2024, 8:17am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/17 "2024-02-01T08:17:40Z")
## 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](https://governance.aave.com/t/bgd-aave-paraswap-fee-claimer/10671) 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](https://dashboard.paraswap.io/public/dashboard/5b6dae52-b39e-4c49-a670-e0f0c0aebee5?partner=aave) there are some funds (~100k) pending to claim from the previous system which still need [migration](https://governance.aave.com/t/bgd-aave-paraswap-fee-claimer/10671/3). 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)` ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [February 5, 2024, 2:17pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/18 "2024-02-05T14:17:54Z")
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 👻 [https://vote.onaave.com/proposal/?proposalId=22](https://vote.onaave.com/proposal/?proposalId=22) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [February 26, 2024, 9:48am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/19 "2024-02-26T09:48:36Z")
## 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](https://vote.onaave.com/proposal/?proposalId=6)). 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. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [March 14, 2024, 9:18pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/20 "2024-03-14T21:18:39Z")
# 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](https://governance.aave.com/t/bgd-statatoken-v3/11894) 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. [Next page](https://governance.aave.com/t/technical-maintenance-proposals/15274.md?page=2)