# Technical maintenance proposals

**URL:** <https://governance.aave.com/t/technical-maintenance-proposals/15274>\
**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:** 4

<div class="post-metadata">

**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 14, 2025, 6:42pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/62 "2025-01-14T18:42:30Z")

</div>

> [@bgdlabs](#):
>
> a.DI/Governance. Enable support for Celo

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻

[https://vote.onaave.com/proposal/?proposalId=232](https://vote.onaave.com/proposal/?proposalId=232)

---

<div class="post-metadata">

**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 15, 2025, 2:58pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/63 "2025-01-15T14:58:39Z")

</div>

# Collector operational upgrade: multiple funds admin support
  

## Simply summary

Upgrade of the Aave Collector contracts across networks, to unify its implementation and enable the finance contributors of the DAO to progress on initiatives like the [Finance Stewards](https://governance.aave.com/t/arfc-aave-finance-steward/17570).

  

## Motivation

Currently, the Aave Collector (treasury smart contract of the DAO, one per network) is managed by a single `Funds Admin` role, which across all Aave instances is configured to be the Governance Level 1 Executor (Short).

Karpatkey & Tokenlogic proposed to upgrade the Collector to allow multiple `Fund Admin` entities, which would allow to delegate control to a set of [Finance Steward](https://governance.aave.com/t/arfc-aave-finance-steward/17570) helper contracts.

Upon working on the [original proposal](https://github.com/aave-dao/aave-v3-origin/pull/82), the authors noticed that the current Collector contracts vary in their storage layout, and this situation makes maintaining and upgrading them more complicated than it should be.

Therefore, in order to eliminate the technical debt, and make future upgrades more seamless, we created a [slight modification](https://github.com/aave-dao/aave-v3-origin/pull/84) of the proposed upgrade, which allows an upgrade of all the existing Collector instances to the same codebase.

  

## Specification
  

**Collector implementation** : [https://github.com/aave-dao/aave-v3-origin/pull/84](https://github.com/aave-dao/aave-v3-origin/pull/84)  
**Upgrade proposal:** [https://github.com/bgd-labs/collector-upgrade-rev6](https://github.com/aave-dao/aave-v3-origin/pull/84)

  

The proposal will upgrade all collector contracts to the new version proposed on the aave-origin repository. To account for the differences in the storage layout, a custom `initializer` is implemented that aligns the storage layout across versions.

As the new version of the Collector implements [`AccessControl`](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/access/AccessControlUpgradeable.sol) from OZ and removes the existing fundsAdmin role, the proposal will also grant the `FUND_ADMIN` role to the Level 1 Executor (Short Executor). This way, the setup post-proposal execution will be the same as currently.

**Important**. The proposal creation will be done only once the engaged security provider of the DAO (Certora) reviews the new Collector implementation.

---

<div class="post-metadata">

**Author:** ![marek](https://avatars.discourse-cdn.com/v4/letter/m/b2d939/32.png) [@marek](https://governance.aave.com/u/marek)\
**Post date:** [January 22, 2025, 6:18am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/65 "2025-01-22T06:18:21Z")

</div>

I’m so excited for this!!!

---

<div class="post-metadata">

**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 28, 2025, 12:42pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/66 "2025-01-28T12:42:23Z")

</div>

> [@bgdlabs](#):
>
> Collector operational upgrade: multiple funds admin support

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻

[https://vote.onaave.com/proposal/?proposalId=237](https://vote.onaave.com/proposal/?proposalId=237)

---

<div class="post-metadata">

**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 30, 2025, 10:06am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/67 "2025-01-30T10:06:54Z")

</div>

While validating the running Collector upgrade proposal against some follow-up development (finance stewards), we noticed a small inconsistency in production: some collectors have a `receive()` (for receiving ETH transfers) function while others do not.  
Even if this functionality is not really critical for the correct functioning of the Collector (Aave v2 and v3 don’t work with native assets), the upgrade would have consistently removed the receive function on all networks, something non-intended and potentially causing nuisances in the future.

Therefore we have cancelled proposal 237 and we will be resubmitting it shortly, with a version that includes a `receive()` function across all Aave networks.

---

<div class="post-metadata">

**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, 2025, 11:52am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/68 "2025-02-05T11:52:06Z")

</div>

After applying the required fix (including the `receive()` function) on the proposal payloads, we have re-submitted the proposal to upgrade the Aave Collector across all networks. The new version has been once again reviewed by @Certora.

  

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=239](https://vote.onaave.com/proposal/?proposalId=239)

---

<div class="post-metadata">

**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 11, 2025, 5:24pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/69 "2025-02-11T17:24:00Z")

</div>

# a.DI/Governance. Enable support for Sonic
  

## Simple Summary

Proposal to register the necessary Sonic adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Sonic.

  

## Motivation

To pass messages from Ethereum to Sonic via a.DI (Aave Delivery Infrastructure), it is necessary to have at least three valid adapters Ethereum → Sonic smart contracts enabled in the system.

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

This procedure mirrors the requirements on previous networks like ZkSync, Linea, or Celo.

  

## Specification

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

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

  

The following are the configured adapters for the Ethereum → Sonic path. _The required confirmations on the path are 2 out of 3_.

| Network | Hyperlane Adapter | LayerZero Adapter | CCIP Adapter |
| --- | --- | --- | --- |
| Ethereum | [0x01dcb90Cf13b82Cde4A0BAcC655585a83Af3cCC1](https://etherscan.io/address/0x01dcb90Cf13b82Cde4A0BAcC655585a83Af3cCC1) | [0x8FD7D8dd557817966181F584f2abB53549B4ABbe](https://etherscan.io/address/0x8FD7D8dd557817966181F584f2abB53549B4ABbe) | [0xe3a0d9754aD3452D687cf580Ba3674c2D7D2f7AE](https://etherscan.io/address/0xe3a0d9754aD3452D687cf580Ba3674c2D7D2f7AE) |
| Sonic | [0x1098F187F5f444Bc1c77cD9beE99e8d460347F5F](https://sonicscan.org/address/0x1098F187F5f444Bc1c77cD9beE99e8d460347F5F) | [0x7B8FaC105A7a85f02C3f31559d2ee7313BDC5d7f](https://sonicscan.org/address/0x7B8FaC105A7a85f02C3f31559d2ee7313BDC5d7f) | [0x1905fCdDa41241C0871A5eC3f9dcC3E8d247261D](https://sonicscan.org/address/0x1905fCdDa41241C0871A5eC3f9dcC3E8d247261D) |

  

The new a.DI deployments on Sonic network are as follows:

| Contract | Address |
| --- | --- |
| CrossChainController | [0x58e003a3C6f2Aeed6a2a6Bc77B504566523cb15c](https://sonicscan.org/address/0x58e003a3C6f2Aeed6a2a6Bc77B504566523cb15c) |
| Granular Guardian | [0x10078c1D8E46dd1ed5D8df2C42d5ABb969b11566](https://sonicscan.org/address/0x10078c1D8E46dd1ed5D8df2C42d5ABb969b11566) |
| Chainlink Emergency Oracle | [0xECB564e91f620fBFb59d0C4A41d7f10aDb0D1934](https://sonicscan.org/address/0xECB564e91f620fBFb59d0C4A41d7f10aDb0D1934) |

  

The new Aave Governance deployments on Sonic network are as follows:

| Contract | Address |
| --- | --- |
| PayloadsController | [0x0846C28Dd54DEA4Fd7Fb31bcc5EB81673D68c695](https://sonicscan.org/address/0x0846C28Dd54DEA4Fd7Fb31bcc5EB81673D68c695) |
| Executor Lvl 1 | [0x7b62461a3570c6AC8a9f8330421576e417B71EE7](https://sonicscan.org/address/0x7b62461a3570c6AC8a9f8330421576e417B71EE7) |
| Governance Guardian | [0x63C4422D6cc849549daeb600B7EcE52bD18fAd7f](https://sonicscan.org/address/0x63C4422D6cc849549daeb600B7EcE52bD18fAd7f) |
| BGD Labs Guardian | [0x7837d7a167732aE41627A3B829871d9e32e2e7f2](https://sonicscan.org/address/0x7837d7a167732aE41627A3B829871d9e32e2e7f2) |

---

<div class="post-metadata">

**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 12, 2025, 6:41pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/70 "2025-02-12T18:41:58Z")

</div>

> [@bgdlabs](#):
>
> a.DI/Governance. Enable support for Sonic

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻

[https://vote.onaave.com/proposal/?proposalId=249](https://vote.onaave.com/proposal/?proposalId=249)

---

<div class="post-metadata">

**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 17, 2025, 6:04pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/71 "2025-03-17T18:04:51Z")

</div>

## Gov v3 VotingMachine/VotingPortal maintenance proposal
  

### Simple Summary

Proposal to make minor improvements on the Governance v3 VotingMachine smart contracts.

  

## Motivation

After more than 1 year of working in production without changes, the Aave governance v3 Voting Machine smart contracts (Ethereum, Polygon, Avalanche) require minor maintenance to move them to an up-to-date state with the rest of the system, more precisely the a.DI (Aave Delivery Infrastructure) directly connected.  
As they are not upgradeable, it is necessary to deploy new DataWarehouse contracts, new VotingStrategy contracts and new VotingPortals.

  

## Specification

The governance proposal will call `approveSenders()` on the `CrossChainController` contract on every voting network (Ethereum, Polygon, Avalanche) to register the new VotingMachine contracts.  
Additionally, `addVotingPortals()` will be called on the core Governance contract on Ethereum, with the new Voting Portals addresses, so that the Aave Governance can communicate with the new Voting Machines.

  

**Voting Machines** :

| Network | VotingMachine |
| --- | --- |
| Ethereum | [0x06a1795a88b82700896583e123F46BE43877bFb6](https://etherscan.io/address/0x06a1795a88b82700896583e123F46BE43877bFb6) |
| Polygon | [0x44c8b753229006A8047A05b90379A7e92185E97C](https://polygonscan.com/address/0x44c8b753229006A8047A05b90379A7e92185E97C) |
| Avalanche | [0x4D1863d22D0ED8579f8999388BCC833CB057C2d6](https://snowscan.xyz/address/0x4D1863d22D0ED8579f8999388BCC833CB057C2d6) |

  

**Voting Portals** :

| Network Path | Voting Portal |
| --- | --- |
| Ethereum - Ethereum | [0x6ACe1Bf22D57a33863161bFDC851316Fb0442690](https://etherscan.io/address/0x6ACe1Bf22D57a33863161bFDC851316Fb0442690) |
| Ethereum - Polygon | [0xFe4683C18aaad791B6AFDF0a8e1Ed5C6e2c9ecD6](https://etherscan.io/address/0xFe4683C18aaad791B6AFDF0a8e1Ed5C6e2c9ecD6) |
| Ethereum - Avalanche | [0x9Ded9406f088C10621BE628EEFf40c1DF396c172](https://etherscan.io/address/0x9Ded9406f088C10621BE628EEFf40c1DF396c172) |

  

We have requested Certora to review the new smart contracts, and confirm here on the forum that there is no security problem with them and the proposal.

_In addition, the old Voting Portals and Voting Machines remain active as a last-resort fallback, to be disabled in a follow-up proposal._

---

<div class="post-metadata">

**Author:** ![Certora](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/certora/32/6230_2.png) [@Certora](https://governance.aave.com/u/Certora)\
**Post date:** [March 17, 2025, 10:10pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/72 "2025-03-17T22:10:11Z")

</div>

We reviewed the upgrade proposal and found no issues in the smart contracts or the AIP.

---

<div class="post-metadata">

**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 19, 2025, 12:11pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/73 "2025-03-19T12:11:06Z")

</div>

> [@bgdlabs](#):
>
> Gov v3 VotingMachine/VotingPortal maintenance proposal

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=272](https://vote.onaave.com/proposal/?proposalId=272)

---

<div class="post-metadata">

**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 23, 2025, 2:31pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/74 "2025-03-23T14:31:55Z")

</div>

The previous proposal 272 has not reached a quorum due to lower governance participation than usual.  
Given that even if not reaching said quorum there were no AGAINST votes (and ~302’000 FOR), we have submitted again the same proposal for vote.

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=273](https://vote.onaave.com/proposal/?proposalId=273)

---

<div class="post-metadata">

**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:** [April 7, 2025, 7:11am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/75 "2025-04-07T07:11:21Z")

</div>

## POOL\_ADMIN renounceRole() by Guardian on new pools

### Simple Summary

After some maturity, it is perfectly safe for the Aave Guardian to renounce the `POOL_ADMIN` role in relatively new pools: **Linea, Sonic**.

### Motivation

Whenever Aave expands to a new network, it does so fully decentralised via an on-chain governance proposal (e.g., [Aave v3 Sonic](https://vote.onaave.com/proposal/?proposalId=257)).  
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 for security.

From a technical/security perspective, we don’t see any risk at the moment or need for the Guardian to hold this role anymore on the aforementioned networks: all apart from Celo, as this last one has undergone a network infrastructure migration only slightly more than 1 week ago.

### 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` role and its address.

---

<div class="post-metadata">

**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:** [April 7, 2025, 2:43pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/76 "2025-04-07T14:43:30Z")

</div>

> [@bgdlabs](#):
>
> POOL\_ADMIN renounceRole() by Guardian on new pools

We can confirm the Aave Scroll Guardian has renounced the `POOL_ADMIN` role on Linea and Sonic.

---

<div class="post-metadata">

**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:** [April 8, 2025, 9:07am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/77 "2025-04-08T09:07:28Z")

</div>

# Removal of legacy VotingPortals from Governance v3
  

## Simple Summary

Proposal to remove the deprecated `VotingPortals` from the Aave Governance.

  

## Motivation

[Proposal 273](https://vote.onaave.com/proposal/?proposalId=273) enabled new VotingPortal contracts on the Aave Governance, but without removing the previous ones to be sure no issues during the transition would happen.

As the new `VotingPortals` have already been proven to be working by using them for voting on at least 4 new proposals (279 - 282), it is time to remove the old ones, so that there is no confusion or possibility of using the old `VotingPortals` on new proposals.

  

## Specification

The payload calls `removeVotingPortals()` on the Aave Governance contract, with the list of old VotingPortals.

  

`VotingPortals` to remove:

| Network | Path | Address |
| --- | --- | --- |
| Ethereum | Eth - Eth | [0xf23f7De3AC42F22eBDA17e64DC4f51FB66b8E21f](https://etherscan.io/address/0xf23f7De3AC42F22eBDA17e64DC4f51FB66b8E21f) |
| Ethereum | Eth - Avax | [0x33aCEf7365809218485873B7d0d67FeE411B5D79](https://etherscan.io/address/0x33aCEf7365809218485873B7d0d67FeE411B5D79) |
| Ethereum | Eth - Pol | [0x9b24C168d6A76b5459B1d47071a54962a4df36c3](https://etherscan.io/address/0x9b24C168d6A76b5459B1d47071a54962a4df36c3) |

---

<div class="post-metadata">

**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:** [April 8, 2025, 5:37pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/78 "2025-04-08T17:37:33Z")

</div>

# Caps AGRS activation on Base/Avalanche

## Simple Summary

Following the successful operation of the cap risk stewards (AGRS) on Aave v3 Arbitrum since [the end of February](https://governance.aave.com/t/arfc-supply-and-borrow-cap-risk-oracle-activation/20834), this proposal enables exactly the same constraint system on Base and Avalanche.

  

## Motivation

[Proposal 253](https://vote.onaave.com/proposal/?proposalId=253) approved by governance and executed February 25th enabled an automated AGRS (Aave Generalised Risk Stewards) system to allow modification of supply and borrow caps in Aave v3 Arbitrum as pilot, to make caps maintenance more efficient, reducing the overall overhead of updating them via manual stewards or governance proposals, while having a more dynamic system reducing the delta between caps and supplies/borrowings.

Since then, the system has been working [flawlessly on Arbitrum](https://governance.aave.com/t/chaos-labs-monthly-community-update/11174/26#p-55100-supply-and-borrow-caps-7), with 55 caps updates. So, following the plan, it is reasonable to continue optimising by introducing the same on other networks, more precisely Base and Avalanche.

  

## Specification

_This new Base and Avalanche instances of AGRS will mirror the same infrastructure as the currently active on Arbitrum_, but a summary of specifications is the following:

- The AGRS will only have two configurable parameters: supply and borrow caps.
- Recommendation of these parameters will be submitted to a RiskOracle smart contract, from the Edge off-chain infrastructure.
- Between the risk oracle smart contract and the AGRS contract, there will be a thin middleware AaveStewardCapsInjector, with the following logic:
  - Takes recommendations from the Edge Risk Oracle side and propagates them to the AGRS contract.
  - Enforce that only the whitelisted assets can be acted upon.
  - Given the protections (percentage constraints and time delay) on the AGRS side and that it is an assumption that risk recommendations will be timed correctly on the Edge Risk Oracle side, the propagation will be permissionless.

- The AaveStewardCapsInjector will be part of the Aave Robot infrastructure, running on Chainlink Automation and consuming LINK from the Aave Collector on each network.
- The new AGRS contract will be given `RISK_ADMIN` role.
- All currently listed assets on Base and Arbitrum will be automated, aside from rsETH and ezETH on Base, as those have pretty ad-hoc caps dynamics.
- Constraints on both Base and Avalanche will be the same as on the system currently live on Arbitrum: maximum 30% increase/decrease every 3 days
- The off-chain caps methodology description can be found on the Aave governance forum [HERE](https://governance.aave.com/t/arfc-supply-and-borrow-cap-risk-oracle-activation/20834).

  

**Base**

| Contract | Address |
| --- | --- |
| EdgeRiskStewardCaps | [0xB892202d9Ce2C16C565A492a5168689b215Eb269](https://basescan.org/address/0xB892202d9Ce2C16C565A492a5168689b215Eb269#code) |
| AaveStewardInjectorCaps | [0x4f84A364B66Eb6280350da011829a6BD02B4712f](https://basescan.org/address/0x4f84A364B66Eb6280350da011829a6BD02B4712f#code) |
| RiskOracle | [0x239d3Bc5fa247337287cb03f53B8bc63DBBc332D](https://basescan.org/address/0x239d3Bc5fa247337287cb03f53B8bc63DBBc332D#code) |

  

**Avalanche**

| Contract | Address |
| --- | --- |
| EdgeRiskStewardCaps | [0x57218F3aB422A39115951c3Eb06881a7A719DfdD](https://snowtrace.io/address/0x57218F3aB422A39115951c3Eb06881a7A719DfdD#code) |
| AaveStewardInjectorCaps | [0x54714FAc85b0bf627288CC3a186dE81A42f1D635](https://snowtrace.io/address/0x54714FAc85b0bf627288CC3a186dE81A42f1D635#code) |
| RiskOracle | [0x1273f29204fC102bD4620485B13cFE27a794fF32](https://snowtrace.io/address/0x1273f29204fC102bD4620485B13cFE27a794fF32/contract/43114/code) |

---

<div class="post-metadata">

**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:** [April 10, 2025, 5:42am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/79 "2025-04-10T05:42:57Z")

</div>

> [@bgdlabs](#):
>
> Removal of legacy VotingPortals from Governance v3

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=291](https://vote.onaave.com/proposal/?proposalId=291)

---

<div class="post-metadata">

**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:** [April 10, 2025, 2:02pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/80 "2025-04-10T14:02:52Z")

</div>

> [@bgdlabs](#):
>
> # Caps AGRS activation on Base/Avalanche

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=292](https://vote.onaave.com/proposal/?proposalId=292)

---

<div class="post-metadata">

**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:** [April 14, 2025, 12:14pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/81 "2025-04-14T12:14:32Z")

</div>

# a.DI/Governance. Enable support for Mantle
  

## Simple Summary

Proposal to activate the necessary a.DI and governance infrastructure for the Mantle network, a technical prerequisite for an activation vote of Aave v3 Mantle.

  

## Motivation

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

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

This procedure mirrors the requirements of previous networks like ZkSync or Linea.

  

## Specification

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

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

The following are the configured adapters for the Ethereum → Mantle path. The required confirmations on the path are 1 out of 1.

| Network | Mantle Native Adapter |
| --- | --- |
| Ethereum | [0xb66FA987fa7975Cac3d12B629c9c44e459e50990](https://etherscan.io/address/0xb66FA987fa7975Cac3d12B629c9c44e459e50990) |
| Mantle | [0x4E740ac02b866b429738a9e225e92A15F4452521](https://mantlescan.xyz/address/0x4E740ac02b866b429738a9e225e92A15F4452521) |

  

The _new a.DI deployments on the Mantle network_ are as follows:

| Contract | Address |
| --- | --- |
| CrossChainController | [0x1283C5015B1Fb5616FA3aCb0C18e6879a02869cB](https://mantlescan.xyz/address/0x1283C5015B1Fb5616FA3aCb0C18e6879a02869cB) |
| Granular Guardian | [0xb26670d2800DBB9cfCe2f2660FfDcA48C799c86d](https://mantlescan.xyz/address/0xb26670d2800DBB9cfCe2f2660FfDcA48C799c86d) |

  

The _new Aave Governance deployments_ on the Mantle network are as follows:

| Contract | Address |
| --- | --- |
| PayloadsController | [0xF089f77173A3009A98c45f49D547BF714A7B1e01](https://mantlescan.xyz/address/0xF089f77173A3009A98c45f49D547BF714A7B1e01) |
| Executor Lvl 1 | [0x70884634D0098782592111A2A6B8d223be31CB7b](https://mantlescan.xyz/address/0x70884634D0098782592111A2A6B8d223be31CB7b) |
| Governance Guardian | [0x14816fC7f443A9C834d30eeA64daD20C4f56fBCD](https://mantlescan.xyz/address/0x14816fC7f443A9C834d30eeA64daD20C4f56fBCD) |
| BGD Labs Guardian | [0x0686f59Cc2aEc1ccf891472Dc6C89bB747F6a4A7](https://mantlescan.xyz/address/0x0686f59Cc2aEc1ccf891472Dc6C89bB747F6a4A7) |

---

<div class="post-metadata">

**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:** [April 15, 2025, 12:37pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/82 "2025-04-15T12:37:41Z")

</div>

> [@bgdlabs](#):
>
> # a.DI/Governance. Enable support for Mantle

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate 👻  
[https://vote.onaave.com/proposal/?proposalId=294](https://vote.onaave.com/proposal/?proposalId=294)

[Previous page](https://governance.aave.com/t/technical-maintenance-proposals/15274.md?page=3)

[Next page](https://governance.aave.com/t/technical-maintenance-proposals/15274.md?page=5)
