We have created an on-chain AIP for this proposal.
Voting will start in approximately 24 hours, participate 
https://vote.onaave.com/proposal/?proposalId=438
2 Likes
POOL_ADMIN renounceRole() by Guardian on pending pools
Simple Summary
After some maturity, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role in relatively new pools: Celo, Soneium, Plasma.
Motivation
Whenever Aave expands to a new network, it does so fully decentralised via an on-chain governance proposal (e.g., Aave v3 Plasma).
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: Celo, Soneium, and Plasma.
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.
We can confirm the Aave Guardian has renounced the roles on Celo, Soneium and Plasma.
2 Likes
Risk Agents maintenance proposal
Simple Summary
This proposal activates the new CAPO Risk Agent on Ethereum and expands the existing Slope2 Interest Rates Agent (live on Ethereum Core, Linea) to Avalanche, Arbitrum, and Base networks.
Additionally, it tightens and aligns the Slope2 Interest Rates Agent constraints on Ethereum Core and Linea with the new networks.
Motivation
Following the successful migration of the AGRS (Risk Stewards) infrastructure to Risk Agents, which activated the Slope2 Interest Rates Agent on Ethereum Core, Linea, it feels natural to expand the Rates Agent on more networks and introduce the new CAPO agent type.
Both initiatives have been suggested by the Risk Service providers on the forum—Slope2 RatesAgent expansion and new CapoAgent addition—along with the latest assets, networks, and constraints for the agents.
CAPO Agent (new)
The CAPO system provides critical price safeguards for yield-bearing assets by defining upper bounds on exchange rates. However, when CAPO parameters remain static for extended periods, the derived maximum ratio can become increasingly detached from real-world exchange rate dynamics, creating vulnerability to price manipulations. By activating the CAPO Risk Agent on Ethereum, parameters like snapshotRatio and maxYearlyRatioGrowthPercent can be dynamically calibrated through the Risk Oracle, maintaining tight and responsive protection for yield-bearing collateral assets without requiring manual governance intervention. More details can be found on the forum post here.
Slope2 Rates Agent (expansion on more networks)
Additionally, extending the Interest Rates Agent to Avalanche, Arbitrum, and Base networks allows for automated adjustment of the variableRateSlope2 parameter on high-utilization assets, ensuring interest rates remain responsive to market conditions across these networks. As part of this expansion, the constraints on Ethereum Core and Linea are tightened from 4% to 2% for stablecoins and 1.5% for WETH, aligning them with the new networks. More details can be found on the forum post here.
Specification
The proposal activates the AaveCapoAgent and AaveRatesAgent with the following params using the chaos-agents infra:
CAPO Agent
| Network | Assets | Parameter | Constraint |
|---|---|---|---|
| Ethereum | wstETH, weETH, rsETH, osETH, ezETH, cbETH, rETH, tETH, ETHx, LBTC, eBTC, sUSDe, syrupUSDT, sDAI | snapshotRatio | Max 3% relative change per 3 days |
| Ethereum | wstETH, weETH, rsETH, osETH, ezETH, cbETH, rETH, tETH, ETHx, LBTC, eBTC, sUSDe, syrupUSDT, sDAI | maxYearlyRatioGrowthPercent | Max 10% relative change per 3 days |
Rates Agent
| Network | Assets | Parameter | Constraint |
|---|---|---|---|
| Avalanche | USDC, USDt | variableRateSlope2 | Max 2% absolute change per 8 hours |
| Avalanche | WETH.e | variableRateSlope2 | Max 1.5% absolute change per 8 hours |
| Arbitrum | USDC, USDT | variableRateSlope2 | Max 2% absolute change per 8 hours |
| Arbitrum | WETH | variableRateSlope2 | Max 1.5% absolute change per 8 hours |
| Base | USDC | variableRateSlope2 | Max 2% absolute change per 8 hours |
| Base | WETH | variableRateSlope2 | Max 1.5% absolute change per 8 hours |
Rates Agent Constraint Alignment (Ethereum Core & Linea)
To align the variableRateSlope2 constraints on Ethereum Core and Linea with the new networks:
| Network | Assets | Parameter | New Constraint | Previous Constraint |
|---|---|---|---|---|
| Ethereum Core | USDC, USDT, USDe | variableRateSlope2 | Max 2% absolute change per 8 hours | Max 4% absolute change per 8 hours |
| Ethereum Core | WETH | variableRateSlope2 | Max 1.5% absolute change per 8 hours | Max 4% absolute change per 8 hours |
| Linea | USDC, USDT | variableRateSlope2 | Max 2% absolute change per 8 hours | Max 4% absolute change per 8 hours |
| Linea | WETH | variableRateSlope2 | Max 1.5% absolute change per 8 hours | Max 4% absolute change per 8 hours |
The payload does the following actions:
- Register new agents on the AgentHub contract by calling
registerAgent() - Configure constrained ranges on the RangeValidationModule to strictly bound the risk param update from the Chaos Risk Oracle. For Ethereum Core and Linea instances we update the constraints to align with the new networks (2% for stablecoins, 1.5% for WETH).
- Give
RISK_ADMINrole to the AgentContract which will be called by the Chaos Agent system to inject updates onto the Aave protocol. - Register new Chainlink automation on the AgentHub Automation wrapper contract for the agents.
- Reimburse BGD Labs with 108 LINK by withdrawing aLINK from the Collector on Ethereum. BGD Labs previously funded Chainlink automation on Base out of pocket, as the Collector did not hold LINK on that network. The reimbursement also covers costs related to governance automation actions.
Please note: On Ethereum, the following price feeds are shared across both Core and Prime instances: wstETH, rsETH, ezETH, tETH, sUSDe so changes on the capo feed params will be applied to both instances. Since the CAPO feeds use the ACL Manager of both instances, we give the RISK_ADMIN role to the agent contract from both Core and Prime instances.
3 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=455
1 Like
a.DI/Governance. Enable support for Monad
Simple Summary
Proposal to register the necessary Monad adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Monad.
Motivation
In order to be able to pass messages from Ethereum to Monad via a.DI (Aave Delivery Infrastructure), it is necessary to have at least one valid adapter Ethereum → Monad smart contract enabled in the system.
The first case of message passing Ethereum → Monad is the activation proposal for an Aave V3 Monad pool, and consequently, to be able to execute on the Monad side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts.
Specification
The proposal payload simply registers pre-deployed Monad adapters (with the necessary configurations to communicate with the Monad 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 → Monad path. The required confirmations on the path are 2 out of 3.
The new a.DI deployments on Monad network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x8dd5b84b26ae3916A5Fb34C8968F93d206216b63 |
| Granular Guardian | 0xD3DD0bE957fcE2dCd359e09374Cbc99f60337D42 |
The new Aave Governance deployments on Monad network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0x442CA936e5E6Db875357d0A16481145c96dd9a82 |
| Executor Lvl 1 | 0xa9d0EAFF48cE1DF468f9eAeb7e628c413343F6A2 |
| Governance Guardian | 0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4E |
| Aave Labs Guardian | 0x2B99790c35a401be873FA7Eb514D9220736BB1cA |
The Protocol Guardian on Monad is as follows:
| Contract | Address |
|---|---|
| Protocol Guardian | 0xc887455536CBD4e615B745e70CaCde15B3117e74 |
USDG price feed update on Aave V3 instances
Simple Summary
Replace the existing USDG price feed on the applicable Aave V3 instances (Ethereum Core and X Layer) with a price cap adapter, set to a maximum price of 1.04 and using the Chainlink USDG feed as the underlying source. USDG is also listed on Aave V3 Ink instance, where this change can be applied as well. The same price adapter must also be used for the PT-USDG-28MAY2026 asset, given that its maturity is now expired.
Motivation
Per LlamaRisk’s latest assessment, liquidity conditions for USDG have improved such that the Chainlink feed now provides higher-quality pricing than the source currently in production. Following the same strategy already applied to other assets across the protocol, the proposal wraps this feed in a price adapter with a cap of 1.04, ensuring the reported price tracks Chainlink while remaining bounded on the upside.
Specification
Upon execution, on each applicable instance the proposal will call setAssetSources([USDG_ADDRESS], [PRICE_CAP_ADAPTER]) on the Aave V3 oracle, pointing USDG at the newly deployed price cap adapter for that network. Each adapter uses the corresponding Chainlink USDG feed as its underlying source and the cap price listed below. The same call applies to the USDG listing on Aave V3 Ink using its respective addresses.
Since the maturity of the PT-USDG-28MAY2026 asset is now expired, the same price adapter must be used as well.
| Pamateter (Ethereum) | Value |
|---|---|
| Chainlink Price Feed | 0x14f0737d6b705259e521EA6E9E3506AC78dBd311 |
| Price Adapter | 0x83D20dEEdcd4aC1313496c8CBcAad0fa298c0CE4 |
| Price cap | 1.04 |
| Pamateter (X Layer) | Value |
|---|---|
| Chainlink Price Feed | 0x385C6bDDE06b0E438319bF4ddBfFe51C521ABf3D |
| Price Adapter | 0xe00B2732396a1f047d4A00e0165025A9cF400245 |
| Price cap | 1.04 |
| Pamateter (Ink) | Value |
|---|---|
| Chainlink Price Feed | 0xdb3B1fa77CF2c9597f9d4871Bed1Df03D096fdf3 |
| Price Adapter | 0x32b1f1A1D3423dE69cf1f75092eCfDc5090d6624 |
| Price cap | 1.04 |
2 Likes
The AIP for this proposal was successfully created, proposal#494
The AIP for this proposal was successfully created, proposal#499, voting will start in less than 24hs.
Configuration Maintenance on the Global Dollar Hub (Aave V4)
Summary
During a post-deployment review of the Global Dollar Hub launch proposal on Aave V4, we identified two configuration deviations from the intended governance setup. This proposal aligns both settings with the rest of the Aave V4 architecture.
The practical impact is minimal, and this only pertains to the Tokenization Spokes of the Global Dollar Hub. There is also no risk to user funds. However, we believe addressing these deviations now will avoid any potential operational issues and simplify future integrations.
Motivation
The review identified two configuration deviations:
-
The three Tokenization Spokes deployed for the Global Dollar Hub have their ProxyAdmin contracts owned by the PayloadsController. These contracts should instead be owned by the Protocol Security Council.
-
The Global Dollar Hub and USDG Pendle Spoke are currently owned by the Aave Governance Executor. During the hardening phase, ownership is intended to reside with the Protocol Security Council.
| Tokenization Spoke | Asset | Contract Address |
|--------------------------|-------------------|--------------------------------------------|
| waPaxosPT_USDG_24SEP2026 | PT_USDG_24SEP2026 | 0x27eF1140364948A0E30E248297FfDFE5a4091ec4 |
| waPaxosUSDC | USDC | 0x4131E0B2E7AFeCEAf3d3b4225aA61a3B2B7535b8 |
| waPaxosUSDT | USDT | 0x8Dabe53E8cB991c57f0307F6f419E6D469b0deAA |
As mentioned above, the impact of these deviations is minimal and user funds are not at risk. The affected Tokenization Spokes have accumulated almost no liquidity since deployment (only a single ~$20 position exists in the Global Dollar USDC Tokenization Spoke), which means facilitating the transition now carries no migration burden. We believe it is appropriate to adjust the configuration now to avoid future operational friction and integration issues.
Regarding the ownership of the Global Dollar Hub and USDG Pendle Spoke, no action is deemed necessary, as ownership by the Aave Governance Executor is the intended final state. The affected permissions are primarily upgrade-related and can still be exercised through the standard governance process.
Specification
The proposal performs the following actions:
-
Retire the three Global Dollar Hub Tokenization Spokes by setting their add cap to zero via the Protocol Security Council. The small $20 position in the Global Dollar USDC Tokenization Spoke will be able to withdraw normally, while new deposits will no longer be accepted.
-
Deploy and activate three replacement Tokenization Spokes.
-
Coordinate the migration with Service Providers and integrators to ensure a smooth transition to the new Tokenization Spokes.
No action is deemed necessary regarding the ownership of the Global Dollar Hub and USDG Pendle Spoke, which will remain assigned to the Aave Governance Executor.
Disclaimer
Aave Labs is presenting this proposal as a service provider to the Aave DAO. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations.
Copyright
Copyright and related rights waived via CC0.
This update was successfully executed, see 0x4e4ac…5d3fd and 0x461c0…aeefe.
New Tokenization Spokes:
| Tokenization Spoke | Asset | Contract Address |
|---|---|---|
| waPaxosPT_USDG_24SEP2026 | PT_USDG_24SEP2026 | 0x7Df10B4A01350D2A1d95cFbE7c9207d7210A2663 |
| waPaxosUSDC | USDC | 0xaed7c529bD2878170B61C758DfAa215AC7a4FD07 |
| waPaxosUSDT | USDT | 0xa0e97e45C2f89003730E467Bd484fA3eEcE5B4Cf |
We kindly ask integrators to update their implementations to target the new addresses.
Following coordination with integrators, we confirm that all deposits have been withdrawn from the three retired Global Dollar Hub Tokenization Spokes.
With no remaining positions, the deactivation of these spokes was coordinated and executed via the Protocol Security Council, completing their deprecation. See transaction 0x45e8ae6c38a2f27d6d79604733f1fe1b93d79016cd51b7fdf1564a9609cb1f4a.