Technical maintenance proposals

Development
83

a.DI/Governance. Enable support for Soneium


Simple Summary

Proposal to register the necessary Soneium adapters on a.DI, a technical prerequisite for an activation vote of Aave v3 Soneium.


Motivation

In order to be able to pass messages from Ethereum to Soneium via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → Soneium smart contract enabled in the system (native adapter).

The first case of message passing Ethereum → Soneium is the activation proposal for an Aave v3 Soneium pool, and consequently, to be able to execute on the Soneium 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 Soneium adapters (with the necessary configurations to communicate with the Soneium 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 → Soneium path.
The required confirmations on the path are 1 out of 1.

Network Soneium Native Adapter
Ethereum 0xe66973c4571F733CafEb1BDE1fa58Ff35416d901
Soneium 0x5698e43Ef1be85C68Dec568B5925dD5DB7903e39

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

Contract Address
CrossChainController 0xD92b37a5114b33F668D274Fb48f23b726a854d6E
Granular Guardian 0xD8E6956718784B914740267b7A50B952fb516656


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

Contract Address
PayloadsController 0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf
Executor Lvl 1 0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A
Governance Guardian 0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6
BGD Labs Guardian 0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A
84

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

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=309

85

Due to an unintended creation of the proposal using Ethereum as the voting network instead of the standard Polygon, we have cancelled 309 and re-created it with voting to be performed as usual on Polygon.

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=312

86

Reserves’ configuration maintenance


Simple Summary

This proposal aims to fix inconsistent/suboptimal configurations of different reserves across various pools.


Motivation

eModes

When Aave v3.2 went live, the existing eModes were just migrated to liquid eModes. What this means is that if an asset was flagged as e.g. eMode 1 on v3.2 it was enabled as borrowable and as collateral on eMode 1. This was done to not disrupt existing positions and also to isolate the upgrade from any configuration changes.

As some time has passed now, it is a good idea to disable unintended eMode configurations, namely, we propose to:

  • Deprecate stablecoin eModes by disabling all borrowable assets
  • Deprecated LSTs from being borrowable in the “correlated” eModes category

This will not have any effects on existing positions, but will prevent increased borrows of the disabled assets within the eMode.


Borrowable

Some assets that were originally listed as borrowable have later been “disabled” by setting their borrowCap to 1 via risk stewards.
While this workaround suits the needs, the “correct” thing to do is to disable borrowing, and later on, decide case by case if re-enabling them. Therefore, this proposal disables borrowing for:

  • FRAX, SNX, LBTC, and rsETH on Mainnet
  • sUSD on Optimism
  • MaticX on Polygon
  • FRAX on Arbitrum
  • FRAX on Avalanche

v2 Rates

In AIP 261, the rates for v2 assets were aligned to standardize interest rates.
This resulted in some unintended increase in interest rate on renFil, which has close to zero secondary market liquidity and thus makes it almost impossible for borrowers to repay their debt.
Therefore, we recommend reverting to the previous ZeroInterestRateStrategy to cut growth.


Specification

The proposal uses the Aave config engine to implement the described changes.

Description Borrowable before Borrowable after
Arbitrum: Stablecoins DAI, USDC, USD₮0, EURS, USDC
Arbitrum: ETH correlated WETH, wstETH, weETH WETH
Avalanche: Stablecoins DAI.e, USDC, USDt, FRAX, MAI
Avalanche: AVAX correlated WAVAX, sAVAX WAVAX
Base: ETH correlated WETH, cbETH, wstETH, weETH WETH
Ethereum: ETH correlated WETH, wstETH, cbETH, rETH, weETH, osETH, ETHx WETH
Gnosis: ETH correlated WETH, wstETH WETH
Optimism:Stablecoins DAI, USDC, USDT, sUSD, USDC
Optimism: ETH correlated WETH, wstETH, rETH WETH
Polygon: Matic correlated WPOL, stMATIC, MaticX WPOL
Polygon: ETH correlated WETH, wstETH WETH
Scroll: ETH correlated WETH, wstETH, weETH WETH
ZkSync: ETH correlated WETH, wstETH WETH

In addition, it calls to revert the interest rate on Aave V2 Ethereum:

AaveV2Ethereum.POOL_CONFIGURATOR.setReserveInterestRateStrategyAddress(
      AaveV2EthereumAssets.renFIL_UNDERLYING,
      0x311C866D55456e465e314A3E9830276B438A73f0
);
1 Like
87

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

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=313

88

Will stablecoin borrowing be re-enabled on Aave? If yes, will the LTV ratios in E-mode return to their previous levels? I’m developing a product that depends on these features, so clarity on the expected timeline and changes would be very helpful for planning and development.

Thanks!

89

Hello @MiguelSanchez.eth. Stablecoins’ emodes require high-level adjustment strategy and risk parameters-wise, so the re-enabling of them and potential parameters is pretty uncertain for now.
We recommend following risk updates on this forum by the providers (Chaos and Llamarisk) for visibility during the next weeks/months.

2 Likes
90

We have created the proposal for this pending update.
Important. There is a typo on the AIP description, and the maxYearlyRatioGrowthPercent is 9.69% on the contracts as expected from the previous post, not 16%.

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=316

91

Fire drill proposal Ethereum VotingMachine


Simple summary

Do a fire drill voting flow with a mock governance proposal using Ethereum as the voting network instead of Polygon as usual, to test that all peripheral systems are properly functioning.


Motivation

One of the design principles of the currently running Aave Governance v3 system is to inherit Ethereum’s security at its core, delegating the voting stage to more cost-efficient networks (currently Polygon PoS and Avalanche C-Chain), while avoiding full dependency on them.

Partially, this is achieved by replicating the same voting infrastructure on Ethereum itself: if, for any reason, all the more optimal voting networks would not be operative, a governance proposal can still be created and voted on (even if more expensive) directly on Ethereum itself.

Given that this flow is only to be used in some very edge emergency scenario, we think it is healthy to make a fire drill: creating a proposal executing a payload without any meaningful content, but using the Ethereum voting infrastructure.


Specification

The governance proposal will be created using the Ethereum → Ethereum Voting Portal so that voting will happen on the Ethereum network.

The payload executed will just contain an empty execute() function, as the purpose of this fire drill is testing the full flow, and not any execution content.

4 Likes
92

Fire drill proposal Avalanche VotingMachine

Simple summary

Do a fire drill voting flow with a mock governance proposal using Avalanche as the voting network instead of Polygon as usual, to test that all peripheral systems are properly functioning.

Motivation

Following the same rationale as the previous proposed fire drill using Ethereum as voting network, we think it is beneficial to do the same with Avalanche, the other available network in production, but that has never been used, given that Polygon has worked properly.

Specification

The governance proposal will be created using the Ethereum → Avalanche Voting Portal so that voting will happen on the Avalanche network.

The payload executed will just contain an empty execute() function, as the purpose of this fire drill is testing the full flow, and not any execution content.

1 Like
93

AGRS (Risk Stewards) maintenance proposal


Simple Summary

This proposal activates the automated Aave Generalised Risk Stewards (AGRS) system on the Ethereum core instance to perform automated discount rate updates on Pendle PT feeds. It also updates the manual AGRS to the most up-to-date iteration (already active on Ethereum), which allows for e-Mode category updates across all instances.


Motivation


Automated AGRS for PT discount rate Risk Oracle

Currently, the discount rate on PT feeds requires manual updates through the manual AGRS on the core instance, creating operational inefficiencies, including:

  • Additional delays in risk parameter adjustments
  • Increased workload and suboptimal response times on manual AGRS due to the high volume of risk updates

To optimize this, and following the same approach as with other risk parameters, this proposal extends the automated AGRS system using Edge Risk Oracles to update the discount rate on the Pendle PT feeds.


Manual AGRS

Following the successful activation of the new version of manual AGRS as part of Proposal 299 on the Ethereum core instance, we propose extending this same implementation to all other instances.
The new version enables constrained updates to eMode category collateral parameters (LT, LTV, and LB) and allows modification of Pendle PT feed discount rates.


Specification

Automated AGRS for PT discount rate Risk Oracle

This new discount rate AGRS will mirror the same infrastructure as the currently active for other automated AGRS, but a summary of specifications is the following:

  • The AGRS will have only one configurable parameter: discount rate on PT feeds.
  • 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 AaveStewardInjectorDiscountRate, with the following logic:
    • Takes recommendations from the Edge Risk Oracle side and propagates them to the AGRS contract.
    • Enforce that only the whitelisted Pendle PT feeds 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 AaveStewardInjectorDiscountRate will be part of the Aave Robot infrastructure, running on Chainlink Automation and consuming LINK from the Aave Collector.
  • The new AGRS contract will be given RISK_ADMIN role.

The following feeds for Pendle PT assets on core instance will be automated: PT_sUSDE_31JUL2025, PT_USDe_31JUL2025, PT_eUSDE_14AUG2025.


Constraints on the discount rate update of the Pendle PT feeds will be as follow: maximum 1% absolute increase/decrease per 2 days.

To be more precise, the price of Pendle PT assets on Aave is calculated as follows: priceOfAsset * (100% - (timeLeftForMaturity * discountRate) / 100%) What this means in practice is that, for ex. a 1% increase of the discount rate per year, the price of the PT asset would reduce by 1% if the time to reach maturity of the PT asset is 1 year. This is never the case on Aave, as maturities are shorter, so the practical impact of the change is ever lower, 0.5% if 6 months are left, 0.25% if 3 months are left, and so on.


Manual AGRS

The new manual AGRS will be activated on all instances and will be given the RISK_ADMIN role via: ACL_MANAGER.addRiskAdmin(RISK_STEWARD); and the RISK_ADMIN role of the previous manual AGRS along with other legacy contracts like FREEZING_STEWARD and CAPS_PLUS_RISK_STEWARD will be revoked.

Please note: GHO asset will be set as restricted on the new manual stewards as the asset is to be updated via the gho stewards.


The following risk configuration will be set on the new manual AGRS for all instances:

Parameter Percent change allowed minimumDelay
EMode LTV 0.5% absolute change 3 days
EMode LiquidationThreshold 0.1% absolute change 3 days
EMode LiquidationBonus 0.5% absolute change 3 days
Pendle PT Feed Discount Rate 2.5% absolute change 2 days
4 Likes
94

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

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=332

1 Like
96

Aave Robot maintenance proposal


Simple Summary

Maintenance proposal to update the Aave Robot automations related with governance voting machines and Stata Tokens rewards accounting.


Motivation

Due to the update of the VotingMachine addresses on the voting machine/portal improvements proposal, it is required to update the voting chain Aave Robot performing automations on the voting machine contracts, and also registering storage roots for voting.
Additionally, with newer instances of Stata Tokens (used on Umbrella) having been deployed recently, it is also needed to register new robots for refreshing liquidity mining rewards and cancel the old ones that were previously activated via this proposal.


Specification

The old Stata Token refresh liquidity mining robots and the voting chain robots will be cancelled by calling the cancel() method on the Aave Robot operator contract, and after the delay has passed anyone could call the permissionless method withdrawLink() to withdraw the unused funds on the previous robots to the Collector.

For the new Stata Token and voting chain Robots, the payload will call the register() method on the robot operator to register them.

The RootsConsumer contracts, which are triggered by voting chain robots to register storage roots for voting, are also redeployed, and new instances are used on the new voting chain robots. The LINK balances from the old RootsConsumer are also migrated to the new RootsConsumer contract by calling the emergencyTokenTransfer() method.

Note: This proposal only updates Robots on Chainlink automation. Robots using Gelato automation on networks where Chainlink automation is not available will be updated manually

Below you can find the changelog of deployed contracts for each instance:

StataRefreshRewardRobot:

Old Contract New Contract
Core 0xda82148a3944BBe442116f41cDb329b0edF11d41 0x892B74CD3703B427CD90e7f140F358A1DE1EA703
Prime - 0x858f50cB70e6476d37543275aF4c738Ae8a27893
Arbitrum 0x0451f67bA61966C346daBAbB50a30Cc6A9A67C69 0xF01281a6DfDe5506C5049c9BBf8C7E087b9bD4bF
Avalanche 0x8aD3f00e91F0a3Ad8b0dF897c19EC345EaB761c4 0x43C6b39669355AF93DdEdc70e8eB44c226f09BFB
Polygon 0x855FbD0D57fF5B1e8263e3cCDf3384545fbaF863 0x1d8347B427964fad8a742e7f9442a4E89346400a
Base 0xad87684D27e6e58F055E6878A9F11F8c52A5b0F5 0x97CB9e81d480A2AB03299760654C1DDC0C16bE07
BNB 0x020E452b463568f55BAc6Dc5aFC8F0B62Ea5f0f3 0x9062F78b631f33D24Ed058cBc116A653452ea82A
Optimism 0x861Be72d464b6F1C99880B9bE476D40e8F9b5Bce 0x365d47ceD3D7Eb6a9bdB3814aA23cc06B2D33Ef8

VotingChainRobot:

Old Contract New Contract
Mainnet 0x7Ed0A6A294Cf085c90917c0ee1aa34e795932558 0xbC3210bfff692a5bbDBB068D42Ab4eAF28b01Ee0
Avalanche 0x10E49034306EaA663646773C04b7B67E81eD0D52 0x2cf0fA5b36F0f89a5EA18F835d1375974a7720B8
Polygon 0xbe7998712402B6A63975515A532Ce503437998b7 0x1180eE41eC15Dd0accC13a1e646B3152bECFf8F6
2 Likes
97

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

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=340

1 Like
98

Caps AGRS activation on Optimism, BNB, Gnosis, Polygon


Simple Summary

Following the successful operation of the automated cap risk stewards (AGRS) on Aave v3 Arbitrum, Base, and Avalanche, this proposal enables the same constraint system on Optimism, Gnosis, BNB, and Polygon instances.


Motivation

Proposal 253 and 292 approved by governance enabled an automated AGRS (Aave Generalised Risk Stewards) system to allow modification of supply and borrow caps in Aave v3 Arbitrum, Base and Avalanche, in order 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, Base and Avalanche. So following the plan it is reasonable to continue optimizing by introducing the same on other networks, more precisely Optimism, Gnosis, BNB and Polygon.


Specification

These new instances of AGRS on Optimism, Gnosis, BNB, and Polygon will mirror the same infrastructure as the currently active on the previous networks like Arbitrum, Base, and Avalanche, 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. Please note: on Gnosis network, the injector robot will be running on Gelato Automation
  • The new AGRS contract will be given RISK_ADMIN role.
  • Constraints on the new instances will be the same as on the system currently live: maximum 30% increase/decrease every 3 days
  • The off-chain caps methodology description can be found on the Aave governance forum here

The following assets have been whitelisted for the automated AGRS system, enforced on the AaveStewardCapsInjector contract:

Optimism

Contract Address
EdgeRiskStewardCaps 0x14a6801DBEBbd6CBE009c10eCFDA98C1c7B89012
AaveStewardInjectorCaps 0x54714FAc85b0bf627288CC3a186dE81A42f1D635
RiskOracle 0x9f6aA2aB14bFF53e4b79A81ce1554F1DFdbb6608

Gnosis

Contract Address
EdgeRiskStewardCaps 0x655252250f4A453854040A49E8280951A76f3033
AaveStewardInjectorCaps 0x394aDC8772DDD076BD3c5C545c4Edd3617C7d5e6
RiskOracle 0x7BD97DD6C199532d11Cf5f55E13a120dB6dd0F4F

BNB

Contract Address
EdgeRiskStewardCaps 0x655252250f4A453854040A49E8280951A76f3033
AaveStewardInjectorCaps 0x54714FAc85b0bf627288CC3a186dE81A42f1D635
RiskOracle 0x239d3Bc5fa247337287cb03f53B8bc63DBBc332D

Polygon

Contract Address
EdgeRiskStewardCaps 0x35b09a414f6003346ca2e2553b3ea91cd3524af3
AaveStewardInjectorCaps 0x54714fac85b0bf627288cc3a186de81a42f1d635
RiskOracle 0x9f6aA2aB14bFF53e4b79A81ce1554F1DFdbb6608
1 Like
99

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

Voting will start in approximately 24 hours, participate :ghost:

3 Likes
100

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

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=351

3 Likes
101

@ChaosLabs @bgdlabs can you please clarify what is the max value which the LT can be amended in a single adjustement? The above conversation suggests its 0.1%, however, the actual code and historical changes (PT-sUSDe July on 25 May) allow a whole 1% change in absolute LT value in a single update.

This is critical for max loopers to understand how much can the value of their collateral be reduced in a single day, so they can maintain a sufficient buffer from liquidation levels.

102

Hello @Benji533.

Aside from changes made via governance proposals, there are two different stewards flows to modify LT on the case you mentioned of Liquid eModes, including those with Pendle PTs. The constraints on those are the following:

  • Manual Stewards: maximum 0.1% absolute change from the previous LT value, and can be done at most once every 3 days.
  • AGRS (Automated Risk Stewards based on the Edge Chaos Oracle): maximum 0.5% absolute change from the previous LT value, can also can only be done at most once every 3 days.

Mind that maybe you are checking historical updates on the Edge oracle, which technically are decoupled from updates actually applied into Aave: the oracle may recommend a value above the constraints, but that value will not be “injected” into Aave

1 Like
104

LBTC and eBTC price feeds update (post LBTC yield accrual)


Simple Summary

AIP for updating the price feeds of LBTC and eBTC, ensuring accurate prices for both assets that will be upgraded to yield-bearing tokens.


Motivation

Lombard is upgrading LBTC into a yield-bearing asset launching on August 11th, 2025, with the asset starting to accrue BABY rewards from Babylon. Therefore, even if underpricing the asset slightly doesn’t cause any issue on Aave, the LBTC price strategy should reflect the value accrual after the upgrade.

Currently, LBTC has been priced with the BTC / USD price feed as previously recommended in the LBTC analysis. In the price strategy section, it was mentioned that in the future, the asset would start generating yield from Babylon stake rewards and would need to upgrade the price strategy.

eBTC is an LRT that is mainly backed by LBTC. We also highlight in the eBTC technical analysis that the price cap adapter must be updated as soon as restaking rewards start accruing.


Specification

The table below illustrates the configuration parameters recommended by Chaos Labs:


Price feed details


LBTC

Parameter (Mainnet) Value
Oracle Capped LBTC / BTC / USD
Ratio Provider StakedLBTCOracle
Underlying Feed Chainlink SVR BTC/USD
Oracle Latest Answer (Aug-11-2025) USD 119,667.05332541
Snapshot Ratio 1.00
Snapshot Timestamp Jun-15-2025
maxYearlyRatioGrowthPercent 2.00%
Parameter (Base) Value
Oracle Capped LBTC / BTC / USD
Ratio Provider StakedLBTCOracle
Underlying Feed Chainlink BTC/USD
Oracle Latest Answer (Aug-11-2025) USD 119,714.02384483
Snapshot Ratio 1.00
Snapshot Timestamp Jun-15-2025
maxYearlyRatioGrowthPercent 2.00%

eBTC

Parameter (Mainnet) Value
Oracle Capped eBTC / BTC / USD
Ratio Provider AccountantWithRateProviders
Underlying Feed Chainlink SVR BTC/USD
Oracle Latest Answer (Aug-11-2025) USD 119,665.73000000
Snapshot Ratio 1.00
Snapshot Timestamp Jul-12-2025
maxYearlyRatioGrowthPercent 1.90%