Technical maintenance proposals

Development
105

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=356

106

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=357

107

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) 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:


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.

1 Like
BGD. Aave <> BGD Labs. Phase 5 recap
108

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
Ink 0xC2cD4F76B7a77AEaE3C04A9B6B105EC1Ad28e984

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

Contract Address
CrossChainController 0x990B75fD1a2345D905a385dBC6e17BEe0Cb2f505
Granular Guardian 0xa2bDB2335Faf1940c99654c592B1a80618d79Fc9

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

Contract Address
PayloadsController 0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf
Executor Lvl 1 0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A
Governance Guardian 0x1bBcC6F0BB563067Ca45450023a13E34fa963Fa9
BGD Labs Guardian 0x81D251dA015A0C7bD882918Ca1ec6B7B8E094585

References

109

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=362

1 Like
110

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.

Certora - Monthly Update
111

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=369

112

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 0xBA0Ee375e9d0c815097D9eB7EB9Db20b59c06792 0x352C71092fB60ce2f94DFF4ACda330DdffD946B0
Plasma 0x13Dc9eBb19bb1A14aa56215b443B2703A07ba2D5 0x99950E7C7eB320A8551916e8676a42b90b058d5D 0x719e23D7B48Fc5AEa65Cff1bc58865C2b8d89A34

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

Contract Address
CrossChainController 0x643441742f73e270e565619be6DE5f4D55E08cd6
Granular Guardian 0x60665b4F4FF7073C5fed2656852dCa271DfE2684
Chainlink Emergency Oracle 0xF61FE74Ec1cFbd9Ee8Bd27592D2EDEe0E2aA85Cf

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

Contract Address
PayloadsController 0xe76EB348E65eF163d85ce282125FF5a7F5712A1d
Executor Lvl 1 0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A
Governance Guardian 0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6
BGD Labs Guardian 0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A
113

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=377

1 Like
114

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
Bob 0x2171E8AD4045342AF92DdC1227ADC659f2a00535

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

Contract Address
CrossChainController 0xf630C8A7bC033FD20fcc45d8B43bFe92dE73154F
Granular Guardian 0xb2C672931Bd1Da226e29997Ec8cEB60Fb1DA3959

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

Contract Address
PayloadsController 0x17fa87007bfF1dC7e6b3a36ED936E6355e37237C
Executor Lvl 1 0x90800d1F54384523723eD3962c7Cd59d7866c83d
Governance Guardian 0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6
BGD Labs Guardian 0xdc62E0e65b2251Dc66404ca717FD32dcC365Be3A
115

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 Queue Payload: Contract calling queueTransaction() to queue the execution on Governance V2 Short Executor
  • PART 2 Execute Payload: Contract calling executeTransaction() to execute the queued transaction via Governance V2 Short Executor
116

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=381

117

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=387

118

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

This new component of AGRS follows the same example of interest rate updates for WETH on v3 Prime Ethereum (this proposal), 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, 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 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:


Enforced constraints. The automated AGRS system will be configured with the following constraints:

Parameter Maximum Change (Absolute) minimumDelay
Slope2 4% 8 Hours
119

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=395

120

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
X Layer 0xEbc2c80073E4752e9A1D2e9A9bC98e8F4EeE9Be9

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

Contract Address
CrossChainController 0xFdd46155fD3DA5B907AD3B9f9395366290f58097
Granular Guardian 0xD6727ec503A8d0C10a0EAA4e76eAf9A628188b25

The new Aave Governance deployments on X Layer network are as follows:

Contract Address
PayloadsController 0x80e11cB895a23C901a990239E5534054C66476B5
Executor Lvl 1 0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19
Governance Guardian 0xeB55A63bf9993d80c86D47f819B5eC958c7C127B
BGD Labs Guardian 0x734c3fF8DE95c3745770df69053A31FDC92F2526
3 Likes
121

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=422

2 Likes
122

AGRS (Risk Stewards) migration to Risk Agents


Simple Summary

Following the approval of Risk Agents, 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.

More detailed specifications can be found on the chaos-agents-migration repo.

Security

Chaos Risk Agent contracts is independently audited by Zellic and Hexens. 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, 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.

3 Likes
[ARFC] Chaos Risk Agents
123

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=432

1 Like
124

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
MegaEth 0x9Ec11a4c2fEc289Db81D75eF31140c358CB93CC6

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

Contract Address
CrossChainController 0x5EE63ACb37AeCDc7e23ACA283098f8ffD9677BBe
Granular Guardian 0x8Fa22D09b13486A40cd6b04398b948AA8bD5853A

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

Contract Address
PayloadsController 0x80e11cB895a23C901a990239E5534054C66476B5
Executor Lvl 1 0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19
Governance Guardian 0x5a578ee1dA2c798Be60036AdDD223Ac164d948Af
BGD Labs Guardian 0x58528Cd7B8E84520df4D3395249D24543f431c21