We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate 
2 Likes
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.
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 helper contracts.
Upon working on the original proposal, 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 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
Upgrade proposal: https://github.com/bgd-labs/collector-upgrade-rev6
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 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.
3 Likes
I’m so excited for this!!!
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
1 Like
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.
2 Likes
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
3 Likes
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 | 0x8FD7D8dd557817966181F584f2abB53549B4ABbe | 0xe3a0d9754aD3452D687cf580Ba3674c2D7D2f7AE |
| Sonic | 0x1098F187F5f444Bc1c77cD9beE99e8d460347F5F | 0x7B8FaC105A7a85f02C3f31559d2ee7313BDC5d7f | 0x1905fCdDa41241C0871A5eC3f9dcC3E8d247261D |
The new a.DI deployments on Sonic network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x58e003a3C6f2Aeed6a2a6Bc77B504566523cb15c |
| Granular Guardian | 0x10078c1D8E46dd1ed5D8df2C42d5ABb969b11566 |
| Chainlink Emergency Oracle | 0xECB564e91f620fBFb59d0C4A41d7f10aDb0D1934 |
The new Aave Governance deployments on Sonic network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0x0846C28Dd54DEA4Fd7Fb31bcc5EB81673D68c695 |
| Executor Lvl 1 | 0x7b62461a3570c6AC8a9f8330421576e417B71EE7 |
| Governance Guardian | 0x63C4422D6cc849549daeb600B7EcE52bD18fAd7f |
| BGD Labs Guardian | 0x7837d7a167732aE41627A3B829871d9e32e2e7f2 |
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
1 Like
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 |
| Polygon | 0x44c8b753229006A8047A05b90379A7e92185E97C |
| Avalanche | 0x4D1863d22D0ED8579f8999388BCC833CB057C2d6 |
Voting Portals:
| Network Path | Voting Portal |
|---|---|
| Ethereum - Ethereum | 0x6ACe1Bf22D57a33863161bFDC851316Fb0442690 |
| Ethereum - Polygon | 0xFe4683C18aaad791B6AFDF0a8e1Ed5C6e2c9ecD6 |
| Ethereum - Avalanche | 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.
5 Likes
We reviewed the upgrade proposal and found no issues in the smart contracts or the AIP.
2 Likes
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
1 Like
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
2 Likes
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).
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.
2 Likes
We can confirm the Aave Scroll Guardian has renounced the POOL_ADMIN role on Linea and Sonic.
1 Like
Removal of legacy VotingPortals from Governance v3
Simple Summary
Proposal to remove the deprecated VotingPortals from the Aave Governance.
Motivation
Proposal 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 |
| Ethereum | Eth - Avax | 0x33aCEf7365809218485873B7d0d67FeE411B5D79 |
| Ethereum | Eth - Pol | 0x9b24C168d6A76b5459B1d47071a54962a4df36c3 |
2 Likes
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, this proposal enables exactly the same constraint system on Base and Avalanche.
Motivation
Proposal 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, 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_ADMINrole. - 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.
Base
| Contract | Address |
|---|---|
| EdgeRiskStewardCaps | 0xB892202d9Ce2C16C565A492a5168689b215Eb269 |
| AaveStewardInjectorCaps | 0x4f84A364B66Eb6280350da011829a6BD02B4712f |
| RiskOracle | 0x239d3Bc5fa247337287cb03f53B8bc63DBBc332D |
Avalanche
| Contract | Address |
|---|---|
| EdgeRiskStewardCaps | 0x57218F3aB422A39115951c3Eb06881a7A719DfdD |
| AaveStewardInjectorCaps | 0x54714FAc85b0bf627288CC3a186dE81A42f1D635 |
| RiskOracle | 0x1273f29204fC102bD4620485B13cFE27a794fF32 |
1 Like
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
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
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 |
| Mantle | 0x4E740ac02b866b429738a9e225e92A15F4452521 |
The new a.DI deployments on the Mantle network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x1283C5015B1Fb5616FA3aCb0C18e6879a02869cB |
| Granular Guardian | 0xb26670d2800DBB9cfCe2f2660FfDcA48C799c86d |
The new Aave Governance deployments on the Mantle network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0xF089f77173A3009A98c45f49D547BF714A7B1e01 |
| Executor Lvl 1 | 0x70884634D0098782592111A2A6B8d223be31CB7b |
| Governance Guardian | 0x14816fC7f443A9C834d30eeA64daD20C4f56fBCD |
| BGD Labs Guardian | 0x0686f59Cc2aEc1ccf891472Dc6C89bB747F6a4A7 |
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
1 Like