# \[TEMP CHECK\] GHO Cross-Chain Strategy **URL:** \ **Category:** Governance\ **Created:** [January 17, 2024, 3:45pm UTC](https://governance.aave.com/t/temp-check-gho-cross-chain-strategy/16291 "2024-01-17T15:45:16Z")\ **Posts on this page:** 1\ **Showing post:** 18
**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:** [February 2, 2024, 9:17am UTC](https://governance.aave.com/t/temp-check-gho-cross-chain-strategy/16291/18 "2024-02-02T09:17:34Z")
First of all, we really support the cross-chain GHO initiative, as the Facilitators architecture already enables by default for GHO to be multi-chain. Seamless communication between those chains is the natural next step. It also seems organic that having developed GHO, @AaveLabs will lead the effort of cross-chain. The following is our feedback. **Control by the Aave DAO** We have a strong opinion that the Aave DAO should **always** have a “super-admin” role on all its systems, only delegating partially certain responsibilities and minimizing those. From our understanding, the architecture of Facilitators enables this by granting a bucket capacity to bridged GHO on each network, which seems reasonable, even if we don’t have visibility on all design details. **Bridging provider** Being the first integrating CCIP into a.DI, we also have full confidence in the solidity of CCIP’s infrastructure. However, we tend to agree with the point raised by the community: the maximum security achievable in **certain** networks are with their native messaging bridge, so the most natural choice is to do the underlying bridging of minting messages via them. Of course, speed should be a consideration, as depending on the direction of communication (e.g. Ethereum → Optimism vs Optimism → Ethereum), there are pretty big differences. For this reason, we think the following model should be considered: - In communication directions like Ethereum → Arbitrum, where the network security is the same as the bridge security, use the native bridge to pass minting messages. - In communication directions like Optimism → Ethereum where the sacrifices in speed are significant (and if there is no desire to have a more sophisticated system, which we think makes sense on this initial phase), use a third-party provider like Chainlink CCIP, chosen as **official provider** from the community. In our opinion, _there is not much doubt that Chainlink should be such partner, given the history and synergies between the communities_. - Still, use any additional non-core features like relayers from Chainlink if that was evaluated as the most appropriate solution. This would be “built on top” of the bridging communication, so should not be a problem. From our perspective, if having that kind of hybrid model of different providers depending on the type of network and direction of communication, it probably makes sense to re-use a.DI, just with different configurations compared with the a.DI Governance instances (e.g. just 1-of-1 consensus). The advantages are the following: - High-level, a.DI has been developed in an Aave-centric way, by Aave service providers. - If Aave expands to another network, a.DI will support that network and the native bridges **before the expansion**. That means full synchronization for any future network for cross-chain GHO on day 0, if desired by the community. - Duplication of work doesn’t seem optimal. a.DI is fully integrated with CCIP message passing, so no extra development would be required in that layer. This means that the focus of @AaveLabs can go fully into the Facilitator smart contract/features layer, which seems the most optimal outcome. --- _[View the full topic](https://governance.aave.com/t/temp-check-gho-cross-chain-strategy/16291)._