We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate 
4 Likes
Re-activation of Aave PoR (Proof of Reserve) after v3.1 upgrade
Simple Summary
Proposal to re-enable Aave Proof of Reserve on Avalanche, after temporarily halting the system during the Aave v3.1 upgrade.
Motivation
With the release of Aave V3.1, it is no longer necessary to set the asset’s LTV to zero before freezing during the execution of an emergency action on a Proof of Reserve alert, as the protocol does both actions in batch.
Moreover, setting LTV to zero that way would break the “rollback” mechanism (pendingLtv) of LTV back to normal value on unfreeze.
Specification
The proposal is separated into two payloads because multiple blocks must pass between canceling the existing Aave Robot automation and withdrawing funds from it. The order of execution is guaranteed by the fact that it is impossible to withdraw funds before the robot is canceled.
The two payloads do the following:
- Cancels the existing Aave Robot automation for PoR, by calling
cancel()on the Aave Robot operator contract. - Activates the new PoR system by:
2.1. Granting Aave v3 AvalancheRISK_ADMINrole to the new PoR executor contract, by callingaddRiskAdmin()on the ACLManager contract.
2.2. Withdrawing LINK funds from the existing Robot PoR by callingwithdrawLink()on the Robot operator contract.
2.3. Registering a new PoR Robot, by callingregister()on the Robot operator contract.
2.4. Refilling the new PoR Robot with 15 LINK from the Aave Collector.
The new contracts involved are the following:
| Contract | Address |
|---|---|
| Proof Of Reserve Executor V3.1 | 0xB94e515615c244Ab25f7A6e592e3Cb7EE31E99F4 |
| Proof Of Reserve Robot | 0x7aE2930B50CFEbc99FE6DB16CE5B9C7D8d09332C |
2 Likes
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
3 Likes
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
4 Likes
Aave v3.2 patch for legacy periphery
Simple Summary
Upgrade the Pool contract across all networks, to add an extra fallback on the getReserveData() view function, allowing for integrators unable to update peripheral contracts (Aave Pool Data Provider) to still be compatible with v3.2.
Motivation
Aave v3.2 included the removal of all the logic of stable rate borrow mode, and the release of a new ProtocolDataProvider maintaining retro-compatibility.
However, post-release we have been contacted by integrators with totally immutable infrastructure depending on so-called “hardcoding” of legacy peripheral contracts, in this case, an old version of the ProtocolDataProvider, designed to be replaced on the core contract of Aave (PoolAddressesProvider) whenever an upgrade happens.
Even if non-critical, this has created issues for those integrators, and from the Aave side, it is possible to increase even more the retro-compatibility by doing a simple upgrade on the Pool smart contract.
Specification
The governance proposal will configure a MOCK_STABLE_DEBT variable on the PoolAddressesProvider, together with upgrading the Aave Pool contract across all networks.
On this pool upgrade, the only modification would be to now return the previously configured MOCK_STABLE_DEBT address for stableDebtTokenAddress on Pool.getReserveData(), this way removing any type of unexpected behavior from integrators using legacy ProtocolDataProvider peripheral contracts, consuming getReserveData().
The upgraded Pool can be found HERE and the proposal payload HERE, both in the draft stage until the Aave DAO security partner (@Certora) reviews them.
2 Likes
After reviewing the suggested solution approach, the solution’s implementation and the upgrade implementation (upcoming AIP payload), we can confirm that the upgrade solves the issue without introducing any undesired effects to the pool.
The upgrade has a green light from Certora to proceed to the AIP phase.
1 Like
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
1 Like
Update legacy Guardian (protocol & governance) to new addresses
Simple summary
Proposal to update emergency roles (protocol & governance) to the new elected Aave Protocol & Emergency Guardians.
Motivation
This year, the community decided to renew the Aave Guardian and making it more granular with a Protocol Emergency Guardian and a Governance Emergency Guardian.
Even if new pieces of infrastructure (e.g. Lido/Etherfi/zkSync) pools have been configured with the new Guardians on activation stage, it is still necessary to update via governance proposal different on-chain roles, from old guardians to new ones.
Specification
→ Protocol Guardian
- For Aave v2 pools
POOL_ADDRESS_PROVIDER.setEmergencyAdmin()is called to replace the old Guardian with the new one. - For Aave v3
ACL_MANAGER.addEmergencyAdmin()is called to give the role to the new Guardian andACL_MANAGER.removeEmergencyAdmin()to remove it from the old Guardian. This is not necessary for new pools where the new Guardian is already configured: zkSync, Lido, Etherfi.
The list of Protocol Guardian Safes is the following:
With signers being the previously approved by Aave governance:
- Chaos Labs (risk service provider).
- Llamarisk (risk service provider).
- Karpatkey (finance service provider).
- Certora (security service provider).
- Tokenlogic (finance service provider).
- BGD Labs (development service provider).
- ACI (growth and business development service provider).
- Ezr3al (Aave DAO delegate).
- Stable Labs (Aave DAO delegate).
→ Governance Guardian
- On all the networks,
PAYLOADS_CONTROLLER.updateGuardian()is called to replace the old Guardian with the new one. This is not necessary for new networks where the new Guardian is already configured: zkSync, Lido, Etherfi. - Only on Ethereum,
GOVERNANCE.updateGuardian()is called to update the guardian for the Governance Core smart contract.
The list of Governance Guardian Safes is the following:
With signers being the previously approved by Aave governance:
- Fernando (Balancer).
- Mounir (Paraswap)
- Gavi Galloway (Standard Crypto)
- Meltem Demirors (Coinshares)
- Seb (Zapper)
- Roger (Chainlink community)
- Mariano Conti (DeFi OG)
- Marin (Lido)
- Certora (security service provider). In this governance guardian too given their role reviewing governance proposals.
2 Likes
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
1 Like
POOL_ADMIN renounceRole() by Guardian on latest pools
Simple Summary
After some maturity time, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role on the latest activated pools: Lido, Etherfi and zkSYNC.
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 the applicable pools: Lido, EtherFi and zkSync.
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.
GHO CCIP Integration Maintenance (CCIP v1.5 upgrade)
Simple Summary
Proposal to update GHO CCIP Token Pools to ensure GHO’s CCIP integration remains functional during and after the upcoming migration to CCIP version 1.5.
Motivation
The Chainlink Cross-Chain Interoperability Protocol (CCIP) is upgrading to version 1.5 in Q4 2024, introducing several new features and enhancements. We are expecting that a detailed description of this new version will be announced by Chainlink soon.
Currently, GHO CCIP Token Pools are based on version 1.4, and they are not compatible in their current form with CCIP 1.5. The Chainlink CCIP team cannot migrate the GHO CCIP Token Pools as part of the system-wide upgrade, as these are fully controlled by the Aave DAO.
Aave Labs will provide technical support to ensure that GHO CCIP Token Pools remain functional, secure, and aligned with the latest updates, enabling GHO to expand to other networks if needed.
Specification
This proposal aims to upgrade the existing CCIP Token Pools for GHO on Ethereum and Arbitrum to provide compatibility with CCIP version 1.5. To make GHO Token Pools remain accessible by both the old OnRamp (1.4) and the new one (1.5), two actions are necessary:
- Configure an Intermediary Contract: This contract will translate execution calls between the new OnRamp and the existing GHO Token Pools. It was developed and deployed by the Chainlink CCIP team on behalf of the Aave DAO.
- Upgrade the Existing GHO Token Pools: Adjust the existing Token Pools to allow calls from both the old OnRamp and the new one (via the intermediary contract). Although a straightforward change, it requires an upgrade of the Token Pool contracts.
As a precaution, we propose setting a token rate limit on the Ethereum <> Arbitrum lane. This is a temporary security measure that can be lifted later via AIP or by GHO Stewards.
Security
The new CCIP version 1.5 and the migration process have undergone a security review. The Chainlink CCIP team is conducting the migration on testnet in preparation for the production migration.
Certora will review the slightly modified version of the CCIP GHO Token Pool contracts and will also review the AIP once it is finalized.
3 Likes
We can confirm the Aave Protocol Guardian has renounced the roles on v3 Lido, Etherfi and zkSync.
4 Likes
We welcome this proposal by Aave Labs to provide a smooth migration to v1.5 of CCIP. We will continue to work with Aave Labs to help ensure a secure migration, and are happy to work with the DAO to help keep GHO safe as it expands to new chains.
5 Likes
Summary
Chaos Labs provides recommendations for the token rate limit configuration on the Ethereum <> Arbitrum lane.
Motivation
The purpose of configuring a rate limit at this stage is to establish a structure that meets technical, interim, and migrative needs. This involves setting the rate limit based on current user transfer behaviors and the historical clustering of transfer volumes within defined time windows, such that observed user behavior is not hindered during this timeframe while a conservative rate allows the system to provide enough buffer for extreme technical scenarios.
Based on this necessity, to establish the rate limit, the token pool capacity can be set at the 95th percentile of historical GHO cross-chain transfer sizes, which is approximately 300,000 GHO. The refill rate, on the other hand, is calculated by examining GHO bridge volumes within a rolling time window to ensure typical GHO bridge volumes remain unaffected. The accompanying chart illustrates GHO bridge volume percentiles over various rolling windows, showing that maximum bridge volume stabilizes at around 1.5 million GHO between 1.5 and 7 hours of aggregation. This implies that GHO bridging volumes are sporadic, with no more than 1.5 million GHO bridged in aggregate within a 7-hour window.
Consequently, the refill rate can be configured based on the peak bridging volume within a 7-hour window, yielding a per-hour refill rate of 215,000 GHO and a per-second rate of 60 GHO.
Specification
| Lane | Token Pool Rate Limit Capacity | Refill Rate |
|---|---|---|
| Ethereum → Arbitrum | 300,000 | 60 p/s |
| Arbitrum → Ethereum | 300,000 | 60 p/s |
2 Likes
Update Stablecoin CAPO Adapters
Simple Summary
Maintenance proposal to update stable price cap adapters across all v2 and v3 instances to the latest version.
The sDAI adapters on Ethereum and Gnosis Aave instances are also updated from non-capo to capo adapters, and USDS adapters are updated to use USDS/USD feed from the previous DAI/USD feed, given that liquidity of USDS is perfectly normalized.
Motivation
-
With the Aave Generalized Risk Stewards (AGRS) being activated on proposal 197 it is important to update the CAPO adapters for stablecoins across both Aave V2 and V3 instances for it to work seamlessly with the new system. Currently this is not possible, because certain CAPOs are missing a getter method
getPriceCap()which prevents the AGRS system from updating the price caps. -
The CAPO adapter for sDAI was not activated before due to its un-stability on its growth rate, but with positive signaling from Chaos Labs, it is now to be enabled on Aave V3 Ethereum and Aave V3 Gnosis instances.
-
USDS asset was listed with a Chainlink DAI/USD underlying feed as given the asset was just released, and its underlying equivalence with DAI. Since USDS is totally stable now, it is reasonable to migrate to an USDS/USD feed.
Specification
The following stable-coin CAPO feeds are being updated across all networks and instances:
| Aave Instances | Underlying assets for which CAPO feed is updated |
|---|---|
| AaveV3Ethereum | USDC, USDT, USDS, DAI, LUSD, FRAX, crvUSD, pyUSD, sDAI |
| AaveV3EthereumLido | USDC, USDS |
| AaveV3EthereumEtherFi | USDC, pyUSD, FRAX |
| AaveV2Ethereum | USDC, USDT, DAI, FRAX, LUSD, USDP, sUSD, BUSD, TUSD, UST |
| AaveV3Polygon | USDC, USDCn, USDT, DAI, miMATIC, |
| AaveV2Polygon | USDC, USDT, DAI |
| AaveV3Avalanche | USDC, USDT, DAI, FRAX, MAI |
| AaveV2Avalanche | USDC, USDT, DAI |
| AaveV3Arbitrum | USDC, USDCn, USDT, DAI, MAI, LUSD, FRAX |
| AaveV3Optimism | USDC, USDCn, USDT, DAI, MAI, LUSD, FRAX |
| AaveV3Base | USDC, USDbC |
| AaveV3BNB | USDC, USDT, fdUSD |
| AaveV3Gnosis | USDC, USDCe, wxDAI, sDAI |
| AaveV3Metis | USDC, USDT, DAI |
| AaveV3Scroll | USDC |
Price Feeds will be updated using AAVE_ORACLE.setAssetSource() method on Aave V2 Instances and using config-engine on Aave V3 Instances.
Please note that the configurations for the Price Caps adapters and the underlying chainlink feeds are exactly the same as before. Also, price feeds of AaveV2 instances are updated as their underlying feed used ASSET/USD could also be updated via the Stewards using the AaveV3 ACL_MANAGER contract
To be more explicit on the code changes between the previous stablecoin CAPO feed and the new one on v3 markets, the following method is being added on the new stablecoin CAPO feed:
/// @inheritdoc IPriceCapAdapterStable
function getPriceCap() external view returns (int256) {
return _priceCap;
}
On v2 markets, the code diff between the previous feed and the new feed is zero, however the ASSET_TO_PEG underlying feed of the CLSynchronicityPriceAdapterBaseToPeg contract uses the new CAPO feed than the previous.
As suggested by Risk Contributors (Chaos Labs), the following configuration for CAPO has been set for sDAI on Aave V3 Ethereum and Gnosis instances:
| maxYearlyRatioGrowthPercent | MINIMUM_SNAPSHOT_DELAY |
|---|---|
| 9.69% | 7 days |
2 Likes
a.DI Enable support for Linea
Simple Summary
Proposal to register the necessary Liena adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Linea.
Motivation
To pass messages from Ethereum to Linea via a.DI (Aave Delivery Infrastructure), it is necessary to have at least one valid adapter Ethereum → Linea smart contract enabled in the system.
The first case of message passing Ethereum → Linea is the activation proposal for an Aave v3 Linea pool. Consequently, to be able to execute on the Linea side the payload, the Aave governance should approve in advance the a.DI adapter smart contract.
This procedure mirrors the requirements on previous networks like Scroll or ZkSync.
Specification
The proposal payload simply registers a pre-deployed Linea adapter (with the necessary configurations to communicate with the Linea a.DI) on the Ethereum a.DI instance.
This is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.
| Network | Adapter |
|---|---|
| Ethereum | 0x8097555ffDa4176C93FEf92dF473b9763e467686 |
| Linea | 0xB3332d31ECFC3ef3BF6Cda79833D11d1A53f5cE6 |
The new a.DI deployments on Linea network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x0D3f821e9741C8a8Bcac231162320251Db0cdf52 |
| Granular Guardian | 0xc1cd6faF6e9138b4e6C21d438f9ebF2bd6F6cA16 |
The new Aave Governance deployments on Linea network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0x3BcE23a1363728091bc57A58a226CF2940C2e074 |
| Executor Lvl 1 | 0x8c2d95FE7aeB57b86961F3abB296A54f0ADb7F88 |
| Governance Guardian | 0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4E |
| BGD Labs Guardian (retry messaging) | 0xfD3a6E65e470a7D7D730FFD5D36a9354E8F9F4Ea |
3 Likes
We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate
2 Likes
GHO CCIP Integration Maintenance (CCIP v1.5.1 upgrade)
Simple Summary
Proposal to update the GHO CCIP Token Pools to integrate them with CCIP (Chainlink Cross-Chain Interoperability Protocol) version 1.5.1. While the existing deployments on Arbitrum and Ethereum are compatible with 1.5.1, adopting the latest version is preferable in order to leverage the full functionality of CCIP and prepare for future expansions to other chains.
Motivation
The CCIP was upgraded to version 1.5.1 at the beginning of December, 2024, introducing a number of enhancements for cross-chain pool management. Currently, GHO CCIP Token Pools are based on version 1.4, though still compatible with 1.5.1.
Aave Labs will provide technical support to maintain the GHO CCIP Token Pools functional, secure, and aligned with the latest updates, enabling GHO expansion to other networks when needed.
Specification
This proposal aims to upgrade the existing CCIP Token Pools for GHO on Ethereum and Arbitrum to CCIP version 1.5.1, by establishing a new lane between these two chains and deprecating the old one.
The proposal includes the following actions:
- Ownership maintenance of contracts:
a. Accept ownership of new token pool contracts for GHO on each network.
b. Assume Admin role for the GHO token in the CCIP TokenAdminRegistry contract on each network.
c. Take ownership of the existing proxy pools (even though they’ll be deprecated). - Migrate Liquidity Between Old and New Token Pools:
a. On Ethereum: Transfer locked GHO liquidity from the old LockReleaseTokenPool contract to the new one, and properly initialize the new contract to reflect the correct amount of bridged liquidity.
b. On Arbitrum: Mint tokens on the new BurnMintTokenPool contract and burn tokens from the old pool using the newly introduceddirectMintanddirectBurnmethods. This is necessary to offboard the old pool as a facilitator and enable the new pool to handle bridge transactions. - Setup a token rate limit of 300,000 GHO capacity and 60 GHO per second refill rate (216,000 GHO per hour), as recommended by the Risk Provider @ChaosLabs in the previous maintenance upgrade to v1.5, see here.
- Keep GhoStewards functional by validating they can execute actions over the new CCIP lane and remain fully operational.
Security
The new CCIP version 1.5.1 has undergone Chainlink’s standard security process.
Certora has completed a review of the new version of the CCIP GHO Token Pool contracts (see here) and will also review the AIP when ready.
1 Like
Update GHO Risk Stewards
Simple Summary
Proposal to update the Risk Steward contracts to enhance the Risk Council’s user experience and align the design of the Risk Stewards implementations throughout the Aave Protocol.
Motivation
This proposal seeks to enhance the Aave user experience and align the design of the Risk Stewards implementation across the Aave Protocol.
Specification
This following updates will be executed on Ethereum and Arbitrum:
-
GhoAaveSteward: Remove the max cap of 25% configured by
GHO_BORROW_RATE_MAX. While this limitation was sensible when applied to the Ethereum reserve only, it is not necessary for different instances of GHO when implemented as a regular reserve. Additionally, the Risk Stewards already have limitations and sanity checks in place to restrict capabilities during rates update. See here. -
GhoCcipSteward: Add a missing getter for the timelock state of the CCIP. See here.
The implemented changes do not impact other parts of the GHO implementation.
Security
Certora has reviewed these changes and will also review the AIP when ready.
1 Like
a.DI/Governance. Enable support for Celo
Simple Summary
Proposal to register the necessary Celo adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Celo.
Motivation
To pass messages from Ethereum to Celo via a.DI (Aave Delivery Infrastructure), it is necessary to have at least three valid adapters Ethereum → Celo smart contracts enabled in the system.
The first case of message passing Ethereum → Celo is the activation proposal for an Aave v3 Celo pool and consequently, to be able to execute the payload on the Celo side, the Aave governance should approve in advance the a.DI adapters smart contracts.
This procedure mirrors the requirements on previous networks like Scroll, ZkSync, or Linea.
Specification
The proposal payload simply registers pre-deployed Celo adapters (with the necessary configurations to communicate with the Celo a.DI) on the Ethereum a.DI instance.
This is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.
| Network | Hyperlane Adapter | LayerZero Adapter | CCIP Adapter |
|---|---|---|---|
| Ethereum | 0x01dcb90Cf13b82Cde4A0BAcC655585a83Af3cCC1 | 0x8410d9BD353b420ebA8C48ff1B0518426C280FCC | 0x58489B249BfBCF5ef4B30bdE2792086e83122B6f |
| Celo | 0x7b065E68E70f346B18636Ab86779980287ec73e0 | 0x83BC62fbeA15B7Bfe11e8eEE57997afA5451f38C | 0x3d534E8964e7aAcfc702751cc9A2BB6A9fe7d928 |
The new a.DI deployments on the Celo network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x50F4dAA86F3c747ce15C3C38bD0383200B61d6Dd |
| Granular Guardian | 0xbE815420A63A413BB8D508d8022C0FF150Ea7C39 |
| Chainlink Emergency Oracle | 0x91b21900E91CD302EBeD05E45D8f270ddAED944d |
The new Aave Governance deployments on the Celo network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0xE48E10834C04E394A04BF22a565D063D40b9FA42 |
| Executor Lvl 1 | 0x1dF462e2712496373A347f8ad10802a5E95f053D |
| Governance Guardian | 0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4E |
| BGD Labs Guardian (retry messaging) | 0xfD3a6E65e470a7D7D730FFD5D36a9354E8F9F4Ea |
6 Likes