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