# Network Expansion Workgroup initiative: governance decision forwarding to non-L2 networks (LIP-24) **URL:** \ **Category:** The LIP - Lido Improvement Proposal - Process\ **Created:** [May 9, 2024, 5:52am UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446 "2024-05-09T05:52:51Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [May 9, 2024, 5:52am UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/1 "2024-05-09T05:52:51Z")
### Executive Summary - **Objective** : Implement a framework for executing Lido DAO’s on-chain governance voted-in actions forwarded from Ethereum to outer networks to minimize or exclude involvement of multisigs, committees, and intermediates. - **Context** : For the recognized wstETH deployments on Layer 2 (L2) networks, Lido DAO currently utilizes established processes that employ canonical bridges, ensuring security congruent with the underlying rollups. - **Proposal** : This discussion aims to explore the adaptation of the governance infrastructure ([a.DI](https://governance.aave.com/t/bgd-a-di-aave-delivery-infrastructure/13951)) developed by [BGD Labs](https://bgdlabs.com/) to forward Lido DAO governance decisions (originated from the [Lido DAO Agent](https://etherscan.io/address/0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c) contract on Ethereum) to external non-L2 networks, such as [BNB Chain](https://snapshot.org/#/lido-snapshot.eth/proposal/0xc12ae07242326a719cb6b6a5eb19cb77eb4515b4a5ebe58508f965a5b9abb27c), to mitigate risks of third-party bridge services misoperation by utilizing bridge aggregation for messages. ### Abstract The [a.DI](https://github.com/lidofinance/aave-delivery-infrastructure/blob/main/README.md) system by BGD Labs serves as a cross-chain communication layer designed to facilitate secure interactions across different blockchain networks with minimal exposure to bridge-related vulnerabilities. This system is instrumental in AAVE’s [governance v3](https://docs.aave.com/governance/master/aave-governance-v3) as a secure message bus and has undergone multiple security [audits and formal verification rounds](https://github.com/lidofinance/aave-delivery-infrastructure/tree/main/security). However, a.DI doesn’t contain a built-in execution module out of the box and requires one to be implemented supporting the interface needed. It’s suggested to derive [`BridgeExecutorBase`](https://github.com/lidofinance/governance-crosschain-bridges/blob/master/contracts/bridges/BridgeExecutorBase.sol) for the governance motion payload format to be compatible with the one [used](https://github.com/lidofinance/governance-crosschain-bridges) for L2 networks forwarding by the Lido DAO. ### Scope of pilot implementation **Immediate goals** - Extend Lido DAO governance functionalities to pass executable decisions on BNB Chain **Proposed Adapter Configurations** - Quorum Requirement: 3/4 - Proposed Bridges: CCIP, HyperLane, LayerZero, Wormhole ### Status The [proposed contractual solution](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-24.md) shaped as a LIP, tailored for Lido deployments, is under audit by [MixBytes()](https://mixbytes.io/). Lido contributors anticipate sharing the comprehensive audit report on this forum shortly. ### Testnet Testnet deployments connecting the [DAO Agent](https://sepolia.etherscan.io/address/0x32A0E5828B62AAb932362a4816ae03b860b65e83) on Ethereum Sepolia and [CrossChainExecutor](https://testnet.bscscan.com/address/0x69EE990d0AADEfcbbA0F2de94E0F26521ae680ff) on BNB Sepolia Testnet (Anchored to Sepolia) are available [here](https://github.com/lidofinance/aave-delivery-infrastructure/blob/2a883777c02487571adfc08fbf362d57134a493f/deployments/addresses.json). The deployments resemble the proposed adapter configurations. ### Next steps Should this proposal be considered favorably, [Network Expansion Workgroup](https://research.lido.fi/t/unofficial-guidelines-for-bridging-solutions-network-expansion-workgroup/5790) recommends to include a.DI to the scope of the follow-up [wstETH bridged to BNB](https://snapshot.org/#/lido-snapshot.eth/proposal/0xc12ae07242326a719cb6b6a5eb19cb77eb4515b4a5ebe58508f965a5b9abb27c) recognition proposal to avoid [msig-based administration of the token and its bridge endpoints](https://research.lido.fi/t/wormhole-x-axelar-lido-bridge-implementation-for-wsteth-on-bnb-chain/6012/7) for wstETH on BNB deployments on Mainnet as early as possible. Further details will be included in the corresponding snapshot proposal(s). ### Feedback Request Community feedback on the feasibility, security concerns, and any potential improvements to this framework to ensure robust and decentralized governance decision forwarding from Ethereum to diverse blockchain environments would be highly appreciated. ---
**Author:** ![eboadom](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/eboadom/32/3764_2.png) [@eboadom](https://research.lido.fi/u/eboadom)\ **Post date:** [May 10, 2024, 5:59pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/2 "2024-05-10T17:59:50Z")
Ernesto from BGD Labs here. Really exciting to see the proposal to adopt a.DI into Lido! As an update of the other active instance of of a.DI for Aave, it has been running in production for Aave since December without any problem, enabling all the stages of a quite advanced multi-chain governance, including the specific needs of Lido: forward governance decision to any destination network. Additionally, we have been doing continuous improvements to the infrastructure, like: - A monitoring dashboard, detailing the whole lifecycle of proposals [https://adi.onaave.com/](https://adi.onaave.com/). - Making a.DI compatible with extra underlying bridge providers, like Wormhole (and others in the pipeline). - Different minor updates on the smart contracts of the system. I really believe this will be a good solution for Lido, and a perfect example of adoption of technology between long-term partners like Aave and Lido. ---
**Author:** ![Tane](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tane/32/4083_2.png) [@Tane](https://research.lido.fi/u/Tane)\ **Post date:** [May 13, 2024, 2:04am UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/3 "2024-05-13T02:04:36Z")
Thank you @TheDZhon so much for your proposal. We generally agree with the the need of this kind of module to facilitate the governance execution to other chains and utilizing a.DI that has been running in production for Aave for a while makes sense as it reduces dependency on a single cross-chain protocol. However, we’d love to understand more on why those 4 protocols have been chosen as a component of the Lido version of a.DI; CCIP, HyperLane, LayerZero, and Wormhole. We suppose it is because of the original a.DI’s design, but would you consider adding more bridges in the future, or maybe replacing any of them? It’s very promising to see more flexible setups with additional considerations to which components Lido will apply once the continuous improvements by BGD Labs progresses. ---
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [May 13, 2024, 2:02pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/4 "2024-05-13T14:02:13Z")
Hey, @eboadom Thank you for chiming in! Really appreciate your input, and thank you for pointing out the monitoring dashboard; it looks pretty neat and super informative. 🤩 By the way, MixBytes() noted the uncompromised quality of the a.DI codebase during their audit. We will share the final report here and suggest attaching it to the cumulative portfolio of security checks. ---
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [May 13, 2024, 2:17pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/5 "2024-05-13T14:17:33Z")
GM, @Tane Thank you for the feedback! > [@Tane](#): > > We generally agree with the the need of this kind of module to facilitate the governance execution to other chains and utilizing a.DI that has been running in production for Aave for a while makes sense as it reduces dependency on a single cross-chain protocol. Yep, a battle-tested solution securing the cross-chain governance of the blue-chip DeFi protocol is what has inspired the NEW participants 🙂 > [@Tane](#): > > However, we’d love to understand more on why those 4 protocols have been chosen as a component of the Lido version of a.DI; CCIP, HyperLane, LayerZero, and Wormhole. The same three adapters (CCIP, LZ, HL) are used for the AAVE governance ([GitHub - bgd-labs/aave-delivery-infrastructure: Abstraction layer for cross-chain communication](https://github.com/bgd-labs/aave-delivery-infrastructure?tab=readme-ov-file#deployed-addresses)) for the BNB Smart Chain. Still, we enhanced it with the Wormhole bridge adapter that recently appeared in the original a.DI codebase, improving the quorum condition from 2/3 to 3/4. > [@Tane](#): > > We suppose it is because of the original a.DI’s design, but would you consider adding more bridges in the future, or maybe replacing any of them? It’s very promising to see more flexible setups with additional considerations to which components Lido will apply once the continuous improvements by BGD Labs progresses. In an ideal situation, the other adapter by Axelar might also be plugged in to get the quorum of 3/5; however, it wasn’t yet available at the time of the full-scope audit. Nevertheless, the setup allows for adding or replacing bridge adapters. That’s why I’d suggest considering it in the future based on the cross-chain governance demand, token standards adoption and upgrades, and bridge providers’ evolution. Worth noting that the governance forwarding is not for regular use but mostly for future-proofing the cross-chain token and protocol parts. ---
**Author:** ![Tane](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tane/32/4083_2.png) [@Tane](https://research.lido.fi/u/Tane)\ **Post date:** [May 14, 2024, 3:23pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/6 "2024-05-14T15:23:13Z")
Thank you so much for your clarification and we understand how you approach this initiative overall. Especially, > [@TheDZhon](#): > > Nevertheless, the setup allows for adding or replacing bridge adapters. That’s why I’d suggest considering it in the future based on the cross-chain governance demand, token standards adoption and upgrades, and bridge providers’ evolution. This is really crucial and great to have. > [@TheDZhon](#): > > Worth noting that the governance forwarding is not for regular use but mostly for future-proofing the cross-chain token and protocol parts. Do you have specific areas you are thinking of applying this implementation, other than governance forwarding yet? ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [July 4, 2024, 6:16pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/7 "2024-07-04T18:16:33Z")
The [MixBytes()](https://mixbytes.io/) audit **has been finalized and published** in the [audits repository](https://github.com/lidofinance/audits/blob/main/bsc/MixBytes%20Lido%20a.DI%20Security%20Audit%20Report%2007-2024.pdf). ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [July 4, 2024, 6:28pm UTC](https://research.lido.fi/t/network-expansion-workgroup-initiative-governance-decision-forwarding-to-non-l2-networks-lip-24/7446/8 "2024-07-04T18:28:13Z")
The a.DI setup for forwarding Lido DAO motions to BSC has been successfully deployed to the Mainnet. It connects the [DAO Agent](https://etherscan.io/address/0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c) on Ethereum with the [CrossChainExecutor](https://bscscan.com/address/0x8E5175D17f74d1D512de59b2f5d5A5d8177A123d) on BSC. The deployment uses the proposed adapter and quorum configurations. ## Deployed contracts **Ethereum** - `ProxyAdmin`: [`0xADD673dC6A655AFD6f38fB88301028fA31A6fDeE`](https://etherscan.io/address/0xADD673dC6A655AFD6f38fB88301028fA31A6fDeE) - `CrossChainController`: [`0x93559892D3C7F66DE4570132d68b69BD3c369A7C`](https://etherscan.io/address/0x93559892D3C7F66DE4570132d68b69BD3c369A7C) (proxy) - `CrossChainController`: [`0x5f456f29238F8d63b3ae69bCEF9e9d4E953f2c63`](https://etherscan.io/address/0x5f456f29238F8d63b3ae69bCEF9e9d4E953f2c63) (impl) - `CCIPAdapter`: [`0x29D4fA5FCC282ba2788A281860770c166F597d5d`](https://etherscan.io/address/0x29D4fA5FCC282ba2788A281860770c166F597d5d) - `HyperLaneAdapter`: [`0x8d374DF3de08b971777Aa091fA68BCE109b3a7F3`](https://etherscan.io/address/0x8d374DF3de08b971777Aa091fA68BCE109b3a7F3) - `LayerZeroAdapter`: [`0x742650E0441Be8503682965d601AD0Ba1fB54411`](https://etherscan.io/address/0x742650E0441Be8503682965d601AD0Ba1fB54411) - `WormholeAdapter`: [`0xEDc0D2cb2289BBa1587424dd42bDD1ca7eAbDF17`](https://etherscan.io/address/0xEDc0D2cb2289BBa1587424dd42bDD1ca7eAbDF17) **BSC contracts** - `ProxyAdmin`: [`0x29E6817db339795766244B96aEf5Dc534a98518d`](https://bscscan.com/address/0x29E6817db339795766244B96aEf5Dc534a98518d) - `CrossChainController`: [`0x40C4464fCa8caCd550C33B39d674fC257966022F`](https://bscscan.com/address/0x40C4464fCa8caCd550C33B39d674fC257966022F) (proxy) - `CrossChainController`: [`0xB7Ba81dd07885ae7BFD18452B36D3404d7EDD8Ee`](https://bscscan.com/address/0xB7Ba81dd07885ae7BFD18452B36D3404d7EDD8Ee) (impl) - `CrossChainExecutor`: [`0x8E5175D17f74d1D512de59b2f5d5A5d8177A123d`](https://bscscan.com/address/0x8E5175D17f74d1D512de59b2f5d5A5d8177A123d) - `CCIPAdapter`: [`0x15AD245133568c2498c7dA0cf2204A03b0e9b98A`](https://bscscan.com/address/0x15AD245133568c2498c7dA0cf2204A03b0e9b98A) - `HyperLaneAdapter`: [`0xCd867B440c726461e5fAbe8d3a050b2f8701C230`](https://bscscan.com/address/0xCd867B440c726461e5fAbe8d3a050b2f8701C230) - `LayerZeroAdapter`: [`0xc934433f4c433Cf80DE6fB65fd70C7a650D8a408`](https://bscscan.com/address/0xc934433f4c433Cf80DE6fB65fd70C7a650D8a408) - `WormholeAdapter`: [`0xBb1E43408BbF2C767Ff3Bd5bBC34E183CC1Ef119`](https://bscscan.com/address/0xBb1E43408BbF2C767Ff3Bd5bBC34E183CC1Ef119)