# Technical maintenance proposals **URL:** \ **Category:** Development\ **Created:** [October 30, 2023, 3:04pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274 "2023-10-30T15:04:01Z")\ **Posts on this page:** 20\ **Page:** 6
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 13, 2025, 7:21am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/105 "2025-08-13T07:21:36Z")
> [@bgdlabs](#): > > Fire drill proposal Ethereum VotingMachine We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=356](https://vote.onaave.com/proposal/?proposalId=356) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 13, 2025, 9:45am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/106 "2025-08-13T09:45:21Z")
> [@bgdlabs](#): > > LBTC and eBTC price feeds update (post LBTC yield accrual) We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=357](https://vote.onaave.com/proposal/?proposalId=357) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 25, 2025, 8:22am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/107 "2025-08-25T08:22:24Z")
# Re-configuration of Core’s GhoDirectMinter ## Simple Summary This proposal outlines the re-configuration/migration of the current `CoreGhoDirectMinter` to a new instance. This is necessary because upon its activation, the existing facilitator was misconfigured with a redundant layer of `ProxyAdmin`, which prevents future upgrades. _Being a totally internal component of infrastructure, this doesn’t carry any effect on users or the GHO ecosystem overall. Also, the misconfiguration is not in any way dangerous, but necessary to upgrade the system if required in the future._ ## Motivation During the Aave V3.4 upgrade, the model of GHO on the v3 Core Ethereum pool was changed, for the DAO to mint GHO to borrow via a Direct Minter facilitator, same as on v3 Prime Ethereum. However, this `CoreGhoDirectMinter` facilitator was configured wrongly ([here](https://github.com/bgd-labs/protocol-v3.4-upgrade/blob/main/src/UpgradePayloadMainnet.sol#L106-L110)) in what regards the ownership of the facilitator’s upgradeability: the ownership of the `ProxyAdmin` (`0xf02d4931e0d5c79af9094cd9dff16ea6e3d9acb8`) (proxy admin of the direct minter itself) was assigned to another `ProxyAdmin` contract (`0xD3cF979e676265e4f6379749DECe4708B9A22476`) controlled by the Governance Executor, instead of assigning it to the `GovernanceV3Ethereum.EXECUTOR_LVL_1` directly. Even if the ownership/admin-chain of the setup doesn’t create any type of security issue (all contracts are part the DAO or contracts controlled), this setup doesn’t allow for future upgrades of the `CoreGhoDirectMinter`: the `GovernanceV3Ethereum.EXECUTOR_LVL_1` owns the top-level `ProxyAdmin` but cannot use it to command the facilitator’s the `ProxyAdmin` below to perform an upgrade. This proposal resolves the issue by migrating the minted GHO and permissions from the old, non-upgradeable facilitator to a new, correctly configured `CoreGhoDirectMinter` instance. _This operation has no negative effect as the Direct Minter is internal infrastructure of the DAO, with end users not having any contact with it_. Addresses of the old facilitator: - `UpgradePayloadMainnet` contract (V3.4 upgrade payload for the Ethereum Core instance): [`0xC2584B9cA7759FE1ac48D8aE38aeAFE12dbC9876`](https://etherscan.io/address/0xC2584B9cA7759FE1ac48D8aE38aeAFE12dbC9876) - `GhoDirectMinter` implementation: [`0xe4c958de49303c9be571e00582cf9454586de76f`](https://etherscan.io/address/0xe4c958de49303c9be571e00582cf9454586de76f) - `GhoDirectMinter` proxy: [`0x593B09afc075B3c326CE2AD7750888645BA8943d`](https://etherscan.io/address/0x593B09afc075B3c326CE2AD7750888645BA8943d) - `GhoDirectMinter`’s `ProxyAdmin` contract: [`0xf02d4931e0d5c79af9094cd9dff16ea6e3d9acb8`](https://etherscan.io/address/0xf02d4931e0d5c79af9094cd9dff16ea6e3d9acb8) - `MiscEthereum.PROXY_ADMIN` contract (which itself is an owner of the `GhoDirectMinter`’s `ProxyAdmin` contract): [`0xD3cF979e676265e4f6379749DECe4708B9A22476`](https://etherscan.io/address/0xD3cF979e676265e4f6379749DECe4708B9A22476) - Owner of the `MiscEthereum.PROXY_ADMIN` contract (`GovernanceV3Ethereum.EXECUTOR_LVL_1`): [`0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A`](https://etherscan.io/address/0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A) ## Specification This proposal will execute a payload to perform the following migration steps: 1. _Transfer state to new Facilitator_ - The bucket capacity and current GHO level of the old facilitator (`0x593B09afc075B3c326CE2AD7750888645BA8943d`) are read. - The new facilitator (new `GhoDirectMinter` on `0x5513224daaEABCa31af5280727878d52097afA05`) is added to the `GhoToken` with the same bucket capacity as the previous one. - The new facilitator mints and supplies GHO to the Aave Pool, matching the GHO level of the old facilitator. 2. _Disable the old Facilitator:_ - After the mint and supply on step 1, there is now liquidity available on the pool for the old facilitator to withdraw its GHO from the pool and burn it.. - The old facilitator is removed from the `GhoToken`’s list of facilitators. 3. **Update permissions:** - The `RISK_ADMIN` role is granted to the new facilitator and revoked from the old one. - The `GhoBucketSteward` is updated to control the new facilitator and cease control of the old one. This ensures a seamless/exact transition of the facilitator’s role and funds (aGHO) while restoring the DAO’s ability to perform future upgrades. ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 25, 2025, 8:26am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/108 "2025-08-25T08:26:36Z")
# a.DI/Governance. Enable support for Ink (for GHO cross-chain support) ## Simple Summary Proposal to register the necessary Ink adapters on a.DI, a technical pre-requirement to have Aave Governance-controlled contracts on Ink, in this case, cross-chain GHO-related to be listed on the Aave \<\> Ink friendly fork. ## Motivation In order to be able to pass messages from Ethereum to Ink via a.DI (Aave Delivery Infrastructure), it is necessary to at least have three valid adapters Ethereum → Ink smart contracts enabled in the system. The first case of message passing Ethereum → Ink is the proposal for GHO CCIP configuration on Ink, and consequently, to be able to execute on the Ink 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 Base or Optimism. ## Specification The proposal payload simply registers pre-deployed Ink adapters (with the necessary configurations to communicate with the Ink 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 → Ink path. The required confirmations on the path are 1 out of 1. | Network | Ink Native Adapter | | --- | --- | | Ethereum | [0x98E78C2cD3013BF13a658E210e27C3732c8Dc48A](https://etherscan.io/address/0x98E78C2cD3013BF13a658E210e27C3732c8Dc48A) | | Ink | [0xC2cD4F76B7a77AEaE3C04A9B6B105EC1Ad28e984](https://57073.routescan.io/address/0xC2cD4F76B7a77AEaE3C04A9B6B105EC1Ad28e984) | The new a.DI deployments on Ink network are as follows: | Contract | Address | | --- | --- | | CrossChainController | [0x990B75fD1a2345D905a385dBC6e17BEe0Cb2f505](https://57073.routescan.io/address/0x990B75fD1a2345D905a385dBC6e17BEe0Cb2f505) | | Granular Guardian | [0xa2bDB2335Faf1940c99654c592B1a80618d79Fc9](https://57073.routescan.io/address/0xa2bDB2335Faf1940c99654c592B1a80618d79Fc9) | The new Aave Governance deployments on Ink network are as follows: | Contract | Address | | --- | --- | | PayloadsController | [0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf](https://57073.routescan.io/address/0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf) | | Executor Lvl 1 | [0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A](https://57073.routescan.io/address/0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A) | | Governance Guardian | [0x1bBcC6F0BB563067Ca45450023a13E34fa963Fa9](https://57073.routescan.io/address/0x1bBcC6F0BB563067Ca45450023a13E34fa963Fa9) | | BGD Labs Guardian | [0x81D251dA015A0C7bD882918Ca1ec6B7B8E094585](https://57073.routescan.io/address/0x81D251dA015A0C7bD882918Ca1ec6B7B8E094585) | ## References - Adapter Implementations: [Ink Native Adapters](https://github.com/bgd-labs/aave-delivery-infrastructure/blob/main/src/contracts/adapters/ink/InkAdapter.sol) - Payload Implementation: [Payload](https://github.com/bgd-labs/adi-deploy/blob/f56472b1557e7b638e0a63d009d9396869ce1968/scripts/payloads/adapters/ethereum/Ethereum_Activate_Ink_Bridge_Adapter_Payload.s.sol) - Payload Tests: [tests](https://github.com/bgd-labs/adi-deploy/blob/f56472b1557e7b638e0a63d009d9396869ce1968/tests/payloads/ethereum/AddInkPathTest.t.sol) - Diffs: [a.DI diffs](https://github.com/bgd-labs/adi-deploy/blob/f56472b1557e7b638e0a63d009d9396869ce1968/diffs/adi_add_ink_path_to_adiethereum_before_adi_add_ink_path_to_adiethereum_after.md) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 26, 2025, 9:56am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/109 "2025-08-26T09:56:55Z")
> [@bgdlabs](#): > > a.DI/Governance. Enable support for Ink (for GHO cross-chain support) We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=362](https://vote.onaave.com/proposal/?proposalId=362) ---
**Author:** ![Certora](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/certora/32/6230_2.png) [@Certora](https://governance.aave.com/u/Certora)\ **Post date:** [August 28, 2025, 4:27pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/110 "2025-08-28T16:27:34Z")
# Certora team security review **Certora confirms that this migration is safe and restores proper upgradeability of the CoreGhoDirectMinter.** - We confirm the issue with the redundant ProxyAdmin ownership in the old facilitator, which prevented upgrades but did not pose any direct security risk. - The migration payload correctly transfers the facilitator’s GHO balances, bucket capacity, and roles to the new instance in an **atomic** way, ensuring no window for inconsistent state or supply. - Permissions are updated as expected: the new facilitator is correctly integrated with the `GovernanceV3Ethereum.EXECUTOR_LVL_1` as admin, restoring the DAO’s ability to perform future upgrades. - As the Direct Minter is an internal DAO component, the change has no impact on end users or the GHO market. **Overall, we consider the proposal safe, well-implemented, and supportive of long-term protocol maintainability.** ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 10, 2025, 6:32am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/111 "2025-09-10T06:32:56Z")
> [@bgdlabs](#): > > Re-configuration of Core’s GhoDirectMinter We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=369](https://vote.onaave.com/proposal/?proposalId=369) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 12, 2025, 5:41am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/112 "2025-09-12T05:41:59Z")
# a.DI/Governance. Enable support for Plasma ## Simple Summary Proposal to register the necessary Plasma adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Plasma. ## Motivation In order to be able to pass messages from Ethereum to Plasma via a.DI (Aave Delivery Infrastructure), it is necessary to at least have three valid adapters Ethereum → Plasma smart contracts enabled in the system. The first case of message passing Ethereum → Plasma is the activation proposal for an Aave v3 Plasma pool, and, to be able to execute the payload on on the Plasma side, the Aave governance should approve in advance the a.DI adapters smart contracts. This procedure mirrors the requirements of previous networks like Sonic or Celo. ## Specification The proposal payload simply registers pre-deployed Plasma adapters (with the necessary configurations to communicate with the Plasma 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 optimal bandwidth on the Ethereum → Plasma path is set to 2 by calling `updateOptimalBandwidthByChain()`. The following are the configured adapters for the Ethereum → Plasma path. The required confirmations on the path are 2 out of 3. | Network | Hyperlane Adapter | LayerZero Adapter | CCIP Adapter | | --- | --- | --- | --- | | Ethereum | [0x6bda311748E6542d578b167d791A4130f3FbBc67](https://etherscan.io/address/0x6bda311748E6542d578b167d791A4130f3FbBc67) | [0xBA0Ee375e9d0c815097D9eB7EB9Db20b59c06792](https://etherscan.io/address/0xBA0Ee375e9d0c815097D9eB7EB9Db20b59c06792) | [0x352C71092fB60ce2f94DFF4ACda330DdffD946B0](https://etherscan.io/address/0x352C71092fB60ce2f94DFF4ACda330DdffD946B0) | | Plasma | [0x13Dc9eBb19bb1A14aa56215b443B2703A07ba2D5](https://plasmascan.to/address/0x13Dc9eBb19bb1A14aa56215b443B2703A07ba2D5) | [0x99950E7C7eB320A8551916e8676a42b90b058d5D](https://plasmascan.to/address/0x99950E7C7eB320A8551916e8676a42b90b058d5D) | [0x719e23D7B48Fc5AEa65Cff1bc58865C2b8d89A34](https://plasmascan.to/address/0x719e23D7B48Fc5AEa65Cff1bc58865C2b8d89A34) | The new a.DI deployments on Plasma network are as follows: | Contract | Address | | --- | --- | | CrossChainController | [0x643441742f73e270e565619be6DE5f4D55E08cd6](https://plasmascan.to/address/0x643441742f73e270e565619be6DE5f4D55E08cd6) | | Granular Guardian | [0x60665b4F4FF7073C5fed2656852dCa271DfE2684](https://plasmascan.to/address/0x60665b4F4FF7073C5fed2656852dCa271DfE2684) | | Chainlink Emergency Oracle | [0xF61FE74Ec1cFbd9Ee8Bd27592D2EDEe0E2aA85Cf](https://plasmascan.to/address/0xF61FE74Ec1cFbd9Ee8Bd27592D2EDEe0E2aA85Cf) | The new Aave Governance deployments on Plasma network are as follows: | Contract | Address | | --- | --- | | PayloadsController | [0xe76EB348E65eF163d85ce282125FF5a7F5712A1d](https://plasmascan.to/address/0xe76EB348E65eF163d85ce282125FF5a7F5712A1d) | | Executor Lvl 1 | [0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A](https://plasmascan.to/address/0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A) | | Governance Guardian | [0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6](https://plasmascan.to/address/0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6) | | BGD Labs Guardian | [0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A](https://plasmascan.to/address/0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A) | ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 13, 2025, 2:26pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/113 "2025-09-13T14:26:03Z")
> [@bgdlabs](#): > > a.DI/Governance. Enable support for Plasma We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=377](https://vote.onaave.com/proposal/?proposalId=377) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 30, 2025, 8:55am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/114 "2025-09-30T08:55:29Z")
# a.DI/Governance. Enable support for Bob ## Simple Summary Proposal to register the necessary Bob adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Bob. ## Motivation In order to be able to pass messages from Ethereum to Bob via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → Bob smart contract enabled in the system (native adapter). The first case of message passing Ethereum → Bob is the activation proposal for an Aave v3 Bob pool and consequently, to be able to execute on the Bob side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts. ## Specification The proposal payload simply registers pre-deployed Bob adapters (with the necessary configurations to communicate with the Bob 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 → Bob path. The required confirmations on the path are 1 out of 1. | Network | Bob Native Adapter | | --- | --- | | Ethereum | [0x1e2bFEF32EdAbf6b3EF8B674044DC00f082Addff](https://etherscan.io/address/0x1e2bFEF32EdAbf6b3EF8B674044DC00f082Addff) | | Bob | [0x2171E8AD4045342AF92DdC1227ADC659f2a00535](https://explorer.gobob.xyz/address/0x2171E8AD4045342AF92DdC1227ADC659f2a00535) | The new a.DI deployments on Bob network are as follows: | Contract | Address | | --- | --- | | CrossChainController | [0xf630C8A7bC033FD20fcc45d8B43bFe92dE73154F](https://explorer.gobob.xyz/address/0xf630C8A7bC033FD20fcc45d8B43bFe92dE73154F) | | Granular Guardian | [0xb2C672931Bd1Da226e29997Ec8cEB60Fb1DA3959](https://explorer.gobob.xyz/address/0xb2C672931Bd1Da226e29997Ec8cEB60Fb1DA3959) | The new Aave Governance deployments on Bob network are as follows: | Contract | Address | | --- | --- | | PayloadsController | [0x17fa87007bfF1dC7e6b3a36ED936E6355e37237C](https://explorer.gobob.xyz/address/0x17fa87007bfF1dC7e6b3a36ED936E6355e37237C) | | Executor Lvl 1 | [0x90800d1F54384523723eD3962c7Cd59d7866c83d](https://explorer.gobob.xyz/address/0x90800d1F54384523723eD3962c7Cd59d7866c83d) | | Governance Guardian | [0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6](https://explorer.gobob.xyz/address/0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6) | | BGD Labs Guardian | [0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A](https://explorer.gobob.xyz/address/0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A) | ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 30, 2025, 9:36am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/115 "2025-09-30T09:36:21Z")
# Claim Aave v2 stkAAVE rewards ## Simple Summary Maintenance proposal to claim unclaimed StkAave rewards from the Ethereum V2 Incentives Controller. ## Motivation During routine treasury analysis, @TokenLogic identified approximately ~560 StkAave tokens (~$150,000 at current market prices) sitting unclaimed in the Ethereum V2 Incentives Controller contract. These dormant rewards represent treasury assets that should be actively managed rather than left idle, making it prudent for the DAO to claim and transfer them to the Aave Collector for proper treasury optimization. ## Specification To claim the unclaimed StkAave reward, the payload: - Sets Claimer Authorization: Calls `setClaimer()` on the Ethereum V2 Incentives Controller to authorize the executor address as the claimer. - Executes Claim: Calls `claimRewardsOnBehalf()` to claim all pending StkAave rewards and transfer them directly to the Aave Collector. Since the `EMISSIONS_ADMIN` role resides with the legacy Aave V2 Governance Short Executor, the implementation requires two additional payload contracts on Ethereum, to be called by the Governance V3 Lvl 1 Executor: - [PART 1](https://github.com/bgd-labs/aave-proposals-v3/blob/main/src/20250930_AaveV2Ethereum_ClaimOldStkAaveRewards/AaveV2Ethereum_ClaimOldStkAaveRewards_20250930.sol#L42) Queue Payload: Contract calling `queueTransaction()` to queue the execution on Governance V2 Short Executor - [PART 2](https://github.com/bgd-labs/aave-proposals-v3/blob/main/src/20250930_AaveV2Ethereum_ClaimOldStkAaveRewards/AaveV2Ethereum_ClaimOldStkAaveRewards_20250930.sol#L74) Execute Payload: Contract calling `executeTransaction()` to execute the queued transaction via Governance V2 Short Executor ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 2, 2025, 9:32am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/116 "2025-10-02T09:32:50Z")
> [@bgdlabs](#): > > a.DI/Governance. Enable support for Bob We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=381](https://vote.onaave.com/proposal/?proposalId=381) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 3, 2025, 11:44am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/117 "2025-10-03T11:44:46Z")
> [@bgdlabs](#): > > Claim Aave v2 stkAAVE rewards We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=387](https://vote.onaave.com/proposal/?proposalId=387) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 19, 2025, 3:51pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/118 "2025-10-19T15:51:09Z")
# AGRS. Slope2 Risk Oracle activation (v3 Core Ethereum, Linea) ## Simple Summary This proposal activates the automated Aave Generalized Risk Stewards (AGRS) system on the Aave Ethereum Core and Linea Instance to perform automated slope2 interest rate updates for WETH, USDT, USDC, USDe assets; as proposed [HERE](https://governance.aave.com/t/chaos-labs-risk-stewards-slope2-parameter-adjustments-for-risk-oracle-deployment/23192). Under the hood, the AGRS consumes the Risk Oracle infrastructure by @chaoslabs. ## Motivation The slope2 risk oracle introduces a dynamic mechanism to address liquidity contraction in high-leverage lending markets. Unlike traditional piecewise-linear rate curves that produce abrupt APR spikes during supply shocks, the oracle stages its response by starting with a low baseline when utilization first crosses the kink, compounding convexly as stress persists, and decaying predictably once conditions normalize. This approach minimizes unnecessary preemptive shocks while providing transparent escalation and robust solvency protection for suppliers, with borrowers facing fair, time-aligned incentives that intensify only during sustained high utilization periods. Detailed methodology can be found [here](https://governance.aave.com/t/chaos-labs-risk-stewards-slope2-parameter-adjustments-for-risk-oracle-deployment/23192#p-59097-motivation-2). This new component of AGRS follows the same example of interest rate updates for WETH on v3 Prime Ethereum ([this proposal](https://vote.onaave.com/proposal/?proposalId=200)), in production for some time. ## Specification The automated AGRS will use another instance of AGRS (exactly the same codebase as the other model), with the following constraints: - This instance will only allow changes of one risk parameter: slope 2. - Recommendations of the parameter 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 very thin middleware [AaveStewardRatesInjector](https://github.com/aave-dao/aave-v3-risk-stewards/blob/ecbe493bb2c7799e58c44ebe907382ffd570e54b/src/contracts/AaveStewardInjectorRates.sol), which will have the following logic: - Will take recommendations from the Edge Risk Oracle side and propagate them to the AGRS contract. - Enforce that only the configured asset can be acted upon. - Given the protections (percentage constraints and time delay) on the AGRS side and that it is an assumption that risk recommendation will be timing correct updates on the Edge Risk Oracle, the propagation will be permissionless. **Automation**. The [AaveStewardRatesInjector](https://github.com/aave-dao/aave-v3-risk-stewards/blob/ecbe493bb2c7799e58c44ebe907382ffd570e54b/src/contracts/AaveStewardInjectorRates.sol) middleware, technically being part of the Aave Robot infrastructure, will run on Chainlink Automation and will be registered using the AaveCLRobotOperator contract with 250 LINK from the Ethereum Collector. Since Chainlink Automation is not available on Linea, the automation will be configured using Gelato’s infrastructure over there. **Roles from the Aave protocol**. The new instance of the RiskSteward will be given the `RiskAdmin` role with the following method: `ACL_MANAGER.addRiskAdmin()` **Whitelisted assets**. Only the following assets will be whitelisted for the automatic AGRS system, enforced strictly on the AaveStewardRatesInjector contract: - AaveV3Ethereum: [WETH](https://etherscan.io/address/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2), [USDC](https://etherscan.io/address/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48), [USDT](https://etherscan.io/address/0xdAC17F958D2ee523a2206206994597C13D831ec7), [USDe](https://etherscan.io/address/0x4c9EDD5852cd905f086C759E8383e09bff1E68B3) - AaveV3Linea: [WETH](https://lineascan.build/address/0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f), [USDC](https://lineascan.build/address/0x176211869cA2b568f2A7D4EE941E073a821EE1ff), [USDT](https://lineascan.build/address/0xA219439258ca9da29E9Cc4cE5596924745e12B93) **Enforced constraints**. The automated AGRS system will be configured with the following constraints: | Parameter | Maximum Change (Absolute) | minimumDelay | | --- | --- | --- | | Slope2 | 4% | 8 Hours | ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [October 21, 2025, 10:31am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/119 "2025-10-21T10:31:59Z")
> [@bgdlabs](#): > > AGRS. Slope2 Risk Oracle activation (v3 Core Ethereum, Linea) We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=395](https://vote.onaave.com/proposal/?proposalId=395) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [November 5, 2025, 12:48pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/120 "2025-11-05T12:48:05Z")
# a.DI/Governance. Enable support for X Layer ## Simple Summary Proposal to register the necessary X Layer adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 X Layer. ## Motivation In order to be able to pass messages from Ethereum to X Layer via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → X Layer smart contract enabled in the system (native adapter). The first case of message passing Ethereum → X Layer is the activation proposal for an Aave v3 X Layer pool and consequently, to be able to execute on the X Layer side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts. ## Specification The proposal payload simply registers pre-deployed X Layer adapters (with the necessary configurations to communicate with the X Layer 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 → X Layer path. The required confirmations on the path are 1 out of 1. | Network | X Layer Native Adapter | | --- | --- | | Ethereum | [0x9fD570da8fFe3384F1093833D44072ea79ABdEB0](https://etherscan.io/address/0x9fD570da8fFe3384F1093833D44072ea79ABdEB0) | | X Layer | [0xEbc2c80073E4752e9A1D2e9A9bC98e8F4EeE9Be9](https://www.oklink.com/x-layer/address/0xEbc2c80073E4752e9A1D2e9A9bC98e8F4EeE9Be9) | The new a.DI deployments on X Layer network are as follows: | Contract | Address | | --- | --- | | CrossChainController | [0xFdd46155fD3DA5B907AD3B9f9395366290f58097](https://www.oklink.com/x-layer/address/0xFdd46155fD3DA5B907AD3B9f9395366290f58097) | | Granular Guardian | [0xD6727ec503A8d0C10a0EAA4e76eAf9A628188b25](https://www.oklink.com/x-layer/address/0xD6727ec503A8d0C10a0EAA4e76eAf9A628188b25) | The new Aave Governance deployments on X Layer network are as follows: | Contract | Address | | --- | --- | | PayloadsController | [0x80e11cB895a23C901a990239E5534054C66476B5](https://www.oklink.com/x-layer/address/0x80e11cB895a23C901a990239E5534054C66476B5) | | Executor Lvl 1 | [0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19](https://www.oklink.com/x-layer/address/0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19) | | Governance Guardian | [0xeB55A63bf9993d80c86D47f819B5eC958c7C127B](https://www.oklink.com/x-layer/address/0xeB55A63bf9993d80c86D47f819B5eC958c7C127B) | | BGD Labs Guardian | [0x734c3fF8DE95c3745770df69053A31FDC92F2526](https://www.oklink.com/x-layer/address/0x734c3ff8de95c3745770df69053a31fdc92f2526) | ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [December 18, 2025, 4:53pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/121 "2025-12-18T16:53:53Z")
> [@bgdlabs](#): > > a.DI/Governance. Enable support for X Layer We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=422](https://vote.onaave.com/proposal/?proposalId=422) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [January 6, 2026, 9:32am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/122 "2026-01-06T09:32:48Z")
# AGRS (Risk Stewards) migration to Risk Agents ## Simple Summary Following the approval of [Risk Agents](https://governance.aave.com/t/arfc-chaos-risk-agents/23401), this proposal migrates all existing injector middleware infra used to perform automated risk updates to the new chaos agents system. ## Motivation Currently, the AGRS, in conjunction with the injector system, is responsible for processing highly constrained risk recommendations for a range of parameters, including supply and borrow caps, interest rates, pendle pt e-mode collateral params, and CAPO values across multiple assets and Aave instances. These updates are executed through the injector middleware, which consumes updates from the chaos risk oracles and injects updates onto the Aave protocol in real-time. While the existing system has served Aave more than well, several limitations exist: - Limited generalization: Almost every Risk Stewards activation requires ad-hoc replication of the entire architecture. This results in meaningful overhead for Aave SPs. - Limited infrastructure visibility: Tracking all active Risk Stewards, as well as their covered assets and constraints, can be challenging at times. The Chaos Risk Agents framework generalizes and modularizes the process of ingesting Risk Oracle data within Aave. It eliminates redundant deployments, centralizes validation logic, and improves visibility across all risk automation layers. The result is a cleaner, more maintainable architecture that allows Aave to expand real-time risk management capabilities, ensuring consistent, verifiable execution of parameter updates. ## Specification All the current automated risk param updates will be migrated from the old injector infra to the chaos-agent system, including the following: | Risk Param | Network Instance | Constrains | | --- | --- | --- | | Supply and Borrow Caps | Arbitrum, Avalanche, Base, BNB, Gnosis, Optimism, Polygon | max 30% relative change / 3 days | | Pendle EMode Collateral Param | EthereumCore, Plasma | max 0.5% absolute change / 3 days for LT, LTV, LB | | Pendle Discount Rate | EthereumCore, Plasma | max 1% absolute change / 2 days | | Interest Rate: Base, Slope1, Slope2, uOptimal | EthereumPrime | max 3% uOpt, 0.5% base, 0.5% slope1, 5% slope2 absolute change / 1 day | | Interest Rate: Slope2 | EthereumCore, Linea | max 4% absolute change / 8 hours | Whitelisted Assets / Markets configured by agent: | | Whitelisted Assets / Markets | | --- | --- | | Arbitrum Supply / Borrow Caps | WETH, USDC, USDT, WBTC, DAI, weETH, ARB, USDC.e, GHO, LINK, wstETH, LUSD, FRAX, rETH, AAVE | | Avalanche Supply / Borrow Caps | WETHe, USDCe, USDTe, WBTCe, DAIe, LINKe, AAVEe, WAVAX, sAVAX, FRAX, MAI, BTCb, AUSD | | Base Supply / Borrow Caps | WETH, cbETH, USDC, USDbC, weETH, GHO, wstETH, cbBTC, LBTC, EURC | | BNB Supply / Borrow Caps | ETH, wstETH, BTCB, USDC, USDT, WBNB | | Gnosis Supply / Borrow Caps | WETH, wstETH, USDCe, sDAI, EURe, GNO | | Optimism Supply / Borrow Caps | WETH, wstETH, rETH, WBTC, USDC, USDT, OP | | Polygon Supply / Borrow Caps | WETH, wstETH, WBTC, USDC, USDC.e, USDT, DAI, AAVE, LINK, WPOL | | EthereumCore Pendle EMode Collateral | EMode Ids: 8, 9, 10, 12, 13, 14, 17, 18, 19, 20, 24, 25, 27, 28, 29, 30, 31, 32 | | Plasma Pendle EMode Collateral | EMode Ids: 5, 6, 7, 8, 13, 14, 15, 16 | | EthereumCore Pendle Discount Rate | PT\_sUSDe\_31JUL25, PT\_USDe\_31JUL25, PT\_eUSDe\_14AUG25, PT\_sUSDe\_25SEP25, PT\_USDe\_25SEP25, PT\_sUSDe\_27NOV25, PT\_USDe\_27NOV25, PT\_sUSDe\_5FEB26, PT\_USDe\_5FEB26 | | Plasma Pendle Discount Rate | PT\_sUSDe\_15JAN26, PT\_USDe\_15JAN26, PT\_sUSDE\_9APR26, PT\_USDE\_9APR26 | | EthereumPrime Interest Rate | WETH | | EthereumCore Slope2 Interest Rate | WETH, USDC, USDT, USDe | | Linea Slope2 Interest Rate | WETH, USDC, USDT | _Please note: The whitelisted assets and the constraints are the same as previously on the AGRS injector infra. This proposal only migrates the existing automated AGRS system using injector infrastructure; there is no change to the manual AGRS system, and updates on it using the new infra will be applied at a different AIP._ The risk agent contracts have not been pre-configured during deployment, and all operations, will be done on the payload: - 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. - Give `RISK_ADMIN` role to the AgentContract which will be called by the Chaos Agent system to inject updates onto the Aave protocol. - Revoke `RISK_ADMIN` role from the previous injector contracts, as this system will be unused. - Cancel previous injector automation and register new ones on the AgentHub Automation wrapper contract. This is done only on networks where we use Chainlink automation, on Linea, Gnosis, and Plasma networks, this will be done off-chain using the DAO account on Gelato automation. - Reimburse BGD Labs with 120 LINK by withdrawing aLINK from Collector on Ethereum, which was used to fund chainlink automation on BNB, Base networks as Collector did not have LINK on those networks. All configurations used on the proposal payload could be found on the [AgentConfigLib](https://github.com/bgd-labs/chaos-agents-migration/blob/88bb6f3c4e043960f8cb42741ebe13c46c73b944/src/contracts/AgentConfigLib.sol). More detailed specifications can be found on the [chaos-agents-migration](https://github.com/bgd-labs/chaos-agents-migration) repo. ### Security Chaos Risk Agent contracts is independently audited by [Zellic](https://github.com/ChaosLabsInc/chaos-agents/blob/f02af714ef069e54bae577ac2d34bb3d57d6e1cd/audits/zellic/v1-zellic.pdf) and [Hexens](https://github.com/ChaosLabsInc/chaos-agents/blob/f02af714ef069e54bae577ac2d34bb3d57d6e1cd/audits/hexens/v1-hexens.pdf). In addition, the migration proposal payload and setup has been reviewed by Certora. ### Permissions Detailed permissions post payload execution of the Chaos Risk Agent could be found on the [permissions-book](https://github.com/aave-dao/aave-permissions-book/compare/47474555dcf6a3d5ce45a0bab7de7bb6d87c1690..33e2307e063e4e21db2408d606ff9bb7a7885ddf), but to summarize (for all networks): | Role | Entity | | --- | --- | | AgentHub Owner | Governance Executor Lvl 1 | | AgentHub ProxyAdmin owner | Governance Executor Lvl 1 | | Agent Admin | Governance Executor Lvl 1 | | RangeValidationModule Config Update | Governance Executor Lvl 1 | | `RISK_ADMIN` on ACL Manager | Each Agent contract | ### Addresses All Agents Hub addresses per network can be found on [Aave Address Book](https://search.onaave.com/?q=agent%20hub). ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [January 9, 2026, 7:51am UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/123 "2026-01-09T07:51:03Z")
> [@bgdlabs](#): > > AGRS (Risk Stewards) migration to Risk Agents We have created an on-chain AIP for this proposal. Voting will start in approximately 24 hours, participate 👻 [https://vote.onaave.com/proposal/?proposalId=432](https://vote.onaave.com/proposal/?proposalId=432) ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [January 20, 2026, 2:20pm UTC](https://governance.aave.com/t/technical-maintenance-proposals/15274/124 "2026-01-20T14:20:31Z")
# a.DI/Governance. Enable support for megaETH ## Simple Summary Proposal to register the necessary MegaEth adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 MegaEth. ## Motivation In order to be able to pass messages from Ethereum to MegaEth via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → MegaEth smart contract enabled in the system (native adapter). The first case of message passing Ethereum → MegaEth is the activation proposal for an Aave v3 MegaEth pool, and consequently, to be able to execute on the MegaEth side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts. ## Specification The proposal payload simply registers pre-deployed MegaEth adapters (with the necessary configurations to communicate with the MegaEth 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 → MegaEth path. The required confirmations on the path are 1 out of 1. | Network | MegaEth Native Adapter | | --- | --- | | Ethereum | [0xC88f3Ffa9923BfAA93681D62864a24d0D10D68d3](https://etherscan.io/address/0xC88f3Ffa9923BfAA93681D62864a24d0D10D68d3) | | MegaEth | [0x9Ec11a4c2fEc289Db81D75eF31140c358CB93CC6](https://megaeth.blockscout.com/address/0x9Ec11a4c2fEc289Db81D75eF31140c358CB93CC6) | The new a.DI deployments on megaETH network are as follows: | Contract | Address | | --- | --- | | CrossChainController | [0x5EE63ACb37AeCDc7e23ACA283098f8ffD9677BBe](https://megaeth.blockscout.com/address/0x5EE63ACb37AeCDc7e23ACA283098f8ffD9677BBe) | | Granular Guardian | [0x8Fa22D09b13486A40cd6b04398b948AA8bD5853A](https://megaeth.blockscout.com/address/0x8Fa22D09b13486A40cd6b04398b948AA8bD5853A) | The new Aave Governance deployments on megaETH network are as follows: | Contract | Address | | --- | --- | | PayloadsController | [0x80e11cB895a23C901a990239E5534054C66476B5](https://megaeth.blockscout.com/address/0x80e11cB895a23C901a990239E5534054C66476B5) | | Executor Lvl 1 | [0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19](https://megaeth.blockscout.com/address/0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19) | | Governance Guardian | [0x5a578ee1dA2c798Be60036AdDD223Ac164d948Af](https://megaeth.blockscout.com/address/0x5a578ee1dA2c798Be60036AdDD223Ac164d948Af) | | BGD Labs Guardian | [0x58528Cd7B8E84520df4D3395249D24543f431c21](https://megaeth.blockscout.com/address/0x58528Cd7B8E84520df4D3395249D24543f431c21) | [Previous page](https://governance.aave.com/t/technical-maintenance-proposals/15274.md?page=5) [Next page](https://governance.aave.com/t/technical-maintenance-proposals/15274.md?page=7)