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.