[TEMP CHECK] GHO Cross-Chain Strategy

[AaveLabs]

Author: Aave Labs

Date: Jan 17, 2024

Summary

The TEMP CHECK proposes a strategy for integrating the GHO stablecoin, the native Aave Protocol asset, across multiple blockchain networks. The objective is to enhance GHO liquidity, accessibility, and interoperability while maintaining security and stability. After thorough evaluation of Chainlink’s Cross-Chain Interoperability Protocol (CCIP), we believe it is possible to deploy GHO cross-chain. Aave and Chainlink have maintained a longstanding partnership, consistently aligning on the principles of security, stability, and the advancement of the Protocol.

Motivation

The current limitation of GHO, which is primarily accessible only via minting on the Ethereum mainnet or through secondary markets, represents a significant constraint in its potential reach and utility across DeFi. We believe the future of GHO is to become a multichain asset where users can interact across various networks using GHO. Moving cross-chain increases the accessibility and liquidity of GHO for a larger spectrum of users. For instance, operating on networks with lower transaction fees can make GHO more cost-effective for users, particularly for smaller transactions. Additionally, faster transaction speeds on alternative chains can enhance the user experience, making GHO a more attractive option for time-sensitive operations.

After thorough technical analysis and evaluation of technical solutions available on the market, Aave Labs suggest implementing a canonical, unified cross-chain strategy for GHO using Chainlink’s CCIP.

CCIP stood up against alternatives thanks to:

• A strong network of decentralized oracle operators (DON), enhancing security on cross- chain messaging
• A ready-made, audited and secure infrastructure for bridging tokens
• A flexible relayer mode with the possibility to pay transaction fees in a variety of tokens (including LINK, and possibly in the future, with GHO)
• Ability for the system to have some critical components controlled by the Aave DAO
• An impeccable track record over multiple years of collaboration with the Aave DAO

Specification

Chainlink’s CCIP is a standard for cross-chain communication that enables different blockchain networks to interact with each other securely and efficiently. It allows smart contracts on one blockchain to send messages and execute actions on another blockchain.

Aave Labs proposes using Chainlink’s CCIP infrastructure to move GHO across blockchain networks. This will allow the seamless transfer of the GHO token between source and destination networks. By “transferring tokens,” CCIP tokens are not technically transferred, but locked/burned on the source chain and then released/minted on the destination network. Cross-chain GHO uses a combination of lock/release and mint/burn models, backing the aggregated liquidity across chains with locked GHO on Ethereum. Every destination chain will have a canonical version of the GHO token and an Aave Governance controlled facilitator with a specific bucket capacity.

• Transfering GHO from Ethereum to another chain: GHO tokens get locked in a vault contract on Ethereum, GHO tokens get minted via Facilitator on the destination chain.
• Transfering GHO from another chain to Ethereum: GHO tokens get burned via Facilitator on the other chain, GHO tokens get released from the vault contract on Ethereum.
• Transfering GHO from one chain to another (none of them are Ethereum): GHO tokens get burned via Facilitator on source chain, minted via Facilitator on destination chain.

Lines in blue show the bridging from the upper domain to the lower domain. Lines in green show the opposite direction. A simulated transaction between Sepolia and Arbitrum Testnet is available to see here.

Each network will have a canonical version of GHO and a facilitator, controlled by Aave Governance, that will manage facilitator buckets and onboard GHO liquidity from Ethereum. The liquidity on each network will depend on the bucket capacity of the Facilitator and CCIP configuration (e.g. rate limit (CCIP Architecture | Chainlink Documentation)). The total amount of liquidity across chains is always less than or equal to the amount of GHO tokens locked on Ethereum. Our approach includes providing a technical assessment of the suitable supported networks and equips the DAO with the opportunity to decide which network(s) to deploy.

Upon approval, we plan to deploy the GHO token on the destination network(s) where GHO will be supported by the Aave DAO. We will implement a custom CCIP token pool contract to facilitate the transfer of GHO between mainnet and destination networks. Chainlink will allow this contract, which is part of the CCIP infrastructure, to be fully controlled by Aave Governance. Additionally, Aave Labs will support a UI integration where users can seamlessly bridge assets to and from supported networks.

Conclusion & Next Steps

The TEMP CHECK’s proposal to integrate the GHO stablecoin across multiple blockchain networks is the first step towards enhancing the utility and expansion of GHO. By leveraging Chainlink’s Cross-Chain Interoperability Protocol (CCIP), users will be able to bridge GHO in a secure and easy way. Following a positive evaluation of this proposal, our actions will include:

1. Initiating the technical implementation process.
2. Conducting an in-depth technical analysis to identify the most suitable networks for deployment.
3. Presenting options to the DAO for selecting the initial network for deployment and configuring Facilitator buckets accordingly.

We encourage community feedback on this strategy.

Aave Labs

[Nandy.eth]

Hi @AaveLabs, I’m in favor of this proposal.
My LFGHO Hackathon team have start building a similar CCIP multichain GHO.
Happy to share our repo at the end of the hackackathon if it can help.

Question: What’s the considération behind locking GHO on Ethereum instead of burn them ?

[Nandy.eth]

Deployment of GHO smart-contract on other EVM chain instead of a wrap-version also gives possibility for gouvernance to propose new Aave V3 market as GHO facilitator. In this scenario, on a EVM chain, there is no distinction between cross and GHO witch facilitate adoption.

[EzR3aL]

Finally CCIP being used in production. It was a long time, but thinking about security, it was needed and is always the main argument for using Aave.
Will there be several networks deployed at the same time or one by one?
If all then its quite easy and only BNB chain would be missing maybe for now, as the market is not established yet.
If it has to be one by one, then i would definitely go with Arbitrum or Optimism even before Polygon. TVL is rising on those chains and fees are quite low making these chains perfect for a multichain GHO start.

GHO token on ETH mainnet will always back GHO on other chains. This means the total bucket of all facilitator has to be the biggest.
Can there be any case where this isn’t the case? Why is this needed overall, as GHO is backed by all assets its being minted against on the protocol?

Thanks

[WintermuteGovernance]

We support Chainlink’s CCIP integration as GHO’s unified cross-chain strategy. The rate-limiting and capacity features are great!

For each destination and source chain will their facilitator buckets be set to some arbitrary large number? For now, it’s constrained by GHO’s minting capacity on mainnet but once GHO minting is available on multiple networks this number can become rather large.

[oneski22]

While I am extremely excited to see GHO planning to be available on multiple chains, I cannot help but be deeply disappointed in the apparent shortcuts this design takes with respect to security and vendor lock.

In the history of Aave, the DAO has historically only supported assets that are native to a given chain (ETH, BAL, DAI etc), canonical assets issued by the same bridge secured by the chain’s consensus (DAI on OP, AAVE on PoS), “RWA” issued tokens (WBTC, USDC, USDT). There are a few times when we have deviated from this for strategic reasons as a DAO, such as the Avax deployments, where the SGX bridge is “essentially” canonical and thus we accept WETH.e, DAI.e, and the Harmony & Fantom markets, which have been deprecated, one due to a painful exploit the other due to lack of usage and the risk of the bridge.

I am disappointed to see the use of a singular external bridging provider such, when for nearly all markets, current and passing temp check - Optimism, Arbitrum, Polygon, Base, Gnosis Chain, Metis, Scroll, Linea, zkEVM, zkSync + more, a Native Canonical Messaging Bridge exists.

To be clear this is not a knock on Chainlink, they are Aave DAO’s longest and oldest partner and their feeds and automation have secured the DAO and its logic since inception. I would advocate strongly for multichain GHO to be written using the xERC-20 standard, which allows for the use of multiple bridges on routes (similar to how A.DI works) with Canonical Bridges used for L2s and other chains that have them, and Chainlink CCIP used for chains that do not have a canonical bridge, such as BNB, Avax, Kava & Celo. The DAO has a history of taking the conservative path when it comes to security, in a way that has only been beneficial as we have seen others move recklessly and end up rekt. I would hope we continue this tradition of security with the GHO stablecoin.

[SaucyBlock]

We supportive of GHO Cross-Chain Strategy.

Formulating the GHO Cross-Chain Strategy for the post-improvement of GHO depeg is highly beneficial. Also, the use of CCIP enables the safe deployment of GHO on many chains.

However, it is advisable to further refine this strategy from the perspective of liquidity and other considerations. Therefore, I recommend changing the status of this proposal from ARFC to TEMP CHECK.

[0xkeyrock.eth]

We’re excited to see this deployment in action!
We do have the same question around facilitator buckets and the strategy there?

[AaveLabs]

Thank you all for the valuable feedback, with special appreciation to @Nandy.eth, @EzR3aL, @oneski22, @WintermuteGovernance and @SaucyBlock for your insightful questions and comments. Our initial intention was to present this post as a TEMP CHECK (edited now). It is crucial for the DAO to reach consensus on this matter, and a TEMP CHECK is the appropriate format for this post to gather feedback and encourage discussions around this topic.

The decision to lock GHO on Ethereum instead of burning it is a deliberate design choice. As outlined in the GHO technical paper, GHO can be minted through various strategies by Facilitators, with these entities able to mint up to a specified limit (bucket capacity) and to burn up to the amount of tokens they have minted (bucket level). Since a Facilitator cannot burn tokens they haven’t minted, GHO tokens must be locked rather than burned. Importantly, this technical detail does not affect the usability or security of GHO, as the tokens are not in circulation in either case.

As highlighted earlier, GHO on Ethereum serves as the backbone for aggregated liquidity across chains. This assurance is only upheld if native minting of newly issued GHO is exclusively supported on Ethereum and not on other chains (e.g., all GHO liquidity on X chain originates from the Ethereum chain). The decision to mint newly issued GHO solely on Ethereum is driven by the DAO’s objective to mitigate security risks and minimize the attack surface. In our perspective, this approach aligns with leveraging the robust security provided by the Ethereum ecosystem.

It’s important to note that the decision to mint newly issued GHO exclusively on Ethereum does not constrain GHO functionality. Should there be a requirement to establish native minting of newly issued GHO on another chain, an equivalent amount of GHO tokens, matching the corresponding bucket capacity of the new Facilitator, can be made accessible from Ethereum through the bridge. This approach ensures that the new minting strategy operates seamlessly on the designated chain.

In the context of security considerations, it’s crucial to emphasize that liquidity on a chain is influenced by various factors:

1. The amount of GHO tokens bridged to that chain: This is capped at the GHO total supply (the technical one, locked and unlocked).
2. The bucket capacity of the CCIP TokenPool Facilitator on the destination chain: This sets a limit on the amount of GHO tokens that can be minted on the destination chain.
3. Rate limits on CCIP configuration: This includes the token pool rate limit (number of tokens transferred per second) and the aggregate rate limit (overall USD value transferred per second) for the lane.

In our perspective, the optimal strategy involves implementing a phased rollout plan, initially supporting one network, thoroughly assessing the process, and gradually expanding to others over time. We are actively identifying the most suitable networks for the initial phase and are open to collaborative ideas with networks. This collaborative approach aims to foster mutual growth, ensuring that both GHO and the selected networks thrive together.

[AaveLabs]

Regarding the choice of CCIP as the bridge solution, Aave Labs believes that using CCIP is the optimal choice in terms of security, usability, and growth for the DAO to enable GHO to move seamlessly across chains.

Historically, the DAO has favored using native bridges to harness the highest security levels, primarily for governance actions. While this approach is not without drawbacks, it was deemed the best solution until a.DI emerged. Although a.DI is seen as the optimal solution for Aave Governance and a viable option for GHO cross-chain, CCIP offers a more cost-effective and faster alternative.

We are of the opinion that the current moment is ideal for GHO to venture into new frontiers, and to facilitate this, it is essential to employ a solution that empowers users and stimulates growth. CCIP stands out for its high-speed and cost-effective token bridging, extensible compatibility to both EVM and non-EVM networks, ease of integration, and robust risk mechanisms. Importantly, opting for CCIP does not impose any limitations on GHO (no vendor lock-in), allowing for the flexibility to explore adding other interoperability solutions in the future.

Furthermore, the Chainlink Labs team has been exceptionally collaborative, providing support and key insights for the integration. Notably, they are open to accommodate a non-standard change in the permissions model of the bridge, allowing Aave Governance to exercise control over the TokenPool (which acts as GHO Facilitator) and the configurable rate limits. This adjustment is crucial, providing an additional layer of security that the DAO can leverage in emergencies. Such an option is typically not available when using other bridges, highlighting the unique security benefits of this integration.

Ultimately, CCIP delivers an improved user experience and standardized security guarantees for users. We appreciate your feedback and we look forward to supporting GHO cross-chain vision while upholding the highest level of security and protocol sovereignty.

[Kene_StableLab]

This proposal takes a valuable step towards enabling cross-chain distribution for the GHO Stablecoin, by getting GHO into the hands of users through various Protocols across multiple chains, we can ensure that the economic research used to set the parameters for GHO is backed up by user fueled demand for the stablecoin.

[CL_Michael]

Thank you @AaveLabs for publishing this proposal! At Chainlink Labs, we’re excited to collaborate on accelerating GHO’s adoption by making the stablecoin widely available across the cross-chain ecosystem.

Given the historical amount of value exploited by insecure cross-chain bridge protocols ($2.8B+), with the most recent happening only a few weeks ago, Aave requires the most secure cross-chain interoperability protocol. Together with Aave Labs, we have collaborated on a solution that uses Chainlink CCIP to make GHO available across the cross-chain ecosystem via canonical deployments with Aave DAO-controlled token pools.

Given that Aave already uses numerous Chainlink services (Price Feeds, Data Feeds, Proof of Reserve, Automation, CCIP messaging), expanding Aave’s usage of Chainlink with CCIP token transfers for GHO means there are little-to-no additional trust assumptions being introduced into the Aave ecosystem with this proposal.

To provide additional context on this proposal, I’ll expand on Chainlink’s long-standing partnership with the Aave community and how Chainlink’s Cross-Chain Interoperability Protocol (CCIP) is the optimal solution for Aave and GHO.

Chainlink Aave

Aave has a strong track record of pioneering innovation in DeFi, consistently pushing the boundaries of blockchain technology and bringing real value to Web3 users. Aave has also pioneered how DeFi and oracles can work together to maximize utility and security, being the first DeFi lending protocol to integrate Chainlink’s decentralized price oracle networks.

The collaboration began back in January 2020 with Aave’s integration of 16 Chainlink Price Feeds as part of its v1 lending market on Ethereum. Four years and multiple version upgrades later, the Aave protocol has consumed data from over a hundred Chainlink Price Feeds, now operates across ten blockchain and layer-2 networks, and uses additional solutions such as Proof of Reserve feeds and Chainlink Automation to support the protocol. Chainlink has been instrumental in helping Aave weather extreme market volatility events and maintain strong tamper-resistance of its external data, even in the presence of advanced adversarial actors and extreme blockchain network congestion on networks like Ethereum.

In July 2023, Chainlink CCIP was officially launched on mainnet with Aave and @bgdlabs as key launch partners, where CCIP was integrated to help secure the protocol’s Governance V3 cross-chain voting mechanism. Since the integration, CCIP has operated without issue, including zero downtime or security incidents.

Chainlink CCIP

Chainlink CCIP serves as an interoperability standard for transferring both tokens and/or data between any public or private blockchain network. CCIP currently supports Ethereum, Polygon, Avalanche, Arbitrum, Optimism, BNB Chain, and Base, with support for more layer-1 and layer-2 chains planned to be added over time. Over 80 DeFi protocols have integrated or are integrating CCIP for cross-chain token transfers and/or cross-chain messaging. This includes Synthetix’s use of CCIP for cross-chain transfer of sUSD via the Synthetix Teleporter (Burn and Mint) and Swell’s upgrade to CCIP for cross-chain transfers of their liquid staking swETH token.

CCIP for Capital Markets & Tokenized Assets

Beyond DeFi, Chainlink Labs has collaborated with some of the world’s largest financial institutions, market infrastructure providers, and enterprises on how CCIP can securely facilitate the cross-chain settlement of tokenized assets across public/private chains. This includes work with Swift (interbank messaging standard for 11,000+ global banks), DTCC (settles $2+ quadrillion in securities volume annually), ANZ ($1T+ assets under management), and Vodafone DAB (IoT-enabled global trade platform).

Knowing that tokenized assets have been a major area of interest for the Aave DAO, Chainlink CCIP can help set the stage for connecting the worlds of TradFi & DeFi with Aave.

Security

Developed with security and reliability as the primary focus by some of the industry’s leading academic researchers, CCIP operates at the highest level of cross-chain security. CCIP’s defense-in-depth security and suitability for the Aave ecosystem can be broken down across multiple categories:

Multiple Layers of Decentralization

CCIP is underpinned by Chainlink’s proven decentralized oracle infrastructure, which has enabled over $9.3T in transaction value within DeFi. Rather than operating as a single monolithic network, CCIP is composed of multiple decentralized oracle networks (DONs) per chain lane, each consisting of a unique source chain and destination chain. This approach allows CCIP to be horizontally scalable, as additional DONs are added to CCIP for each additional blockchain network supported, versus funneling all cross-chain traffic through a single network.

The committing DON is a decentralized network of oracle nodes that monitor events on a given source chain, wait for source chain finality, bundle transactions to create a Merkle root, come to consensus on that Merkle root and finally commit that Merkle root to the destination chain. The executing DON is a decentralized network of oracle nodes that submit Merkle proofs on a destination chain, which is then verified onchain by ensuring the transactions were included in a previously committed Merkle root that has been validated by the Risk Management Network.

Risk Management Network

The Risk Management Network is a separate, independent network that continuously monitors and validates the behavior of CCIP, providing an additional layer of security by independently verifying cross-chain operations for anomalous activity. The Risk Management Network utilizes a separate, minimal implementation of the Chainlink node software, creating a form of client diversity for increased robustness while also minimizing external dependencies to prevent supply chain attacks.

More specifically, the Risk Management Network was written in a different programming language (Rust) than the primary CCIP system (Golang), developed by a different internal team, and uses a distinct non-overlapping set of node operators compared to the CCIP DONs. The Risk Management Network is a wholly unique concept in cross-chain interoperability that builds upon established engineering principles (N-version programming) seen in mission-critical systems in industries such as aviation, nuclear, and machine automation.

To increase the security and robustness of CCIP, the Risk Management Network engages in two types of activities:

• Secondary Approval: The Risk Management Network independently recreates Merkle roots based on transactions from the source chain, which are then published on the destination chain and compared against the Merkle roots published by the Committing DON. Cross-chain transactions can only be executed if the Merkle roots from the two networks match.
• Anomaly Detection: The Risk Management Network monitors for abnormal behavior from the CCIP network (e.g., committed transactions with no source chain equivalent) as well as the behavior of chains (e.g., deep block reorgs). If suspicious activity is detected, the Risk Management Network can trigger an emergency halt to pause all CCIP lanes and limit any losses.

Configurable Rate Limits

As an additional layer of security for cross-chain token transfers, CCIP implements configurable rate limits, established on a per-token and per-lane basis. For this proposal, the Aave DAO will have the ability to set up and directly manage these parameters. Furthermore, CCIP token transfers also benefit from the increased security provided by an aggregate rate limit (across token pools) on each lane, so even in a worst-case scenario, it would be impossible for every token’s limit to be maxed out before the aggregate rate limit on a lane is hit.

Audits and Source Code

Security is the number one priority for the Chainlink ecosystem, a value we do not and will not compromise upon. Chainlink Labs has put an immense amount of resources into developing the security model of CCIP, and as such, is the most audited Chainlink solution to date.

Both the onchain and offchain code for CCIP and the Risk Management Network was subjected to 14 independent audits by five leading security firms (Cure53, Dedaub, NCC Cryptography Services, Sigma Prime, and Trail of Bits) in preparation for the initial mainnet launch.

Additionally, two crowdsourced audits of CCIP and the Risk Management Network were conducted on the Code4rena (C4) platform:

• CCIP and Risk Management Network
• CCIP Administration Contracts

All valid findings were remediated and fixes confirmed with the respective auditors. In some cases, findings represented expected behaviors and were reviewed with auditors upon receipt of audit reports.

The source code for CCIP is publicly viewable on GitHub:

• Cross-Chain Interoperability Protocol
• Risk Management Network
• CCIP Owner Contracts

Conclusion

We are thrilled at the opportunity to support GHO’s cross-chain expansion. Chainlink CCIP offers best-in-class security for cross-chain GHO token transfers. Given Aave’s extensive usage of Chainlink services for multiple protocol functions, we believe this proposal would add little-to-no additional trust assumptions to the Aave protocol and significantly accelerate the growth and adoption of the GHO stablecoin.

LFGHO!

[Cross-chain-Alliance]

Good job in posting this @AaveLabs, it is a very exciting development for GHO and we fully support it!

Given how much this proposal has influenced the direction of our project, we wanted to take the opportunity to introduce FRAGOLA, a new framework designed to help building cross-chain Facilitators for GHO. It won the first prize - awarded by Aave - in the GHO Facilitators category at the ETHGlobal LFGHO hackathon last week, just a few days after this proposal was first published.

Why FRAGOLA?

• Interoperability on bridging: By configuring it to use CCIP, it ensures seamless and secure cross-chain transactions via Chainlink’s solution, in line with the proposal’s objectives.
• Flexibility on collaterals: With its adaptable architecture, FRAGOLA supports a wide range of collateral types, enabling GHO to expand its reach and utility if desired.
• Governance adaptability: Given Hashi’s use, any governance module can be easily plugged in to keep consistent governance trust assumptions across the GHO protocol.
• Modularity: Separating concerns into smaller and simpler components could facilitate auditing activities and reuse, aligning perfectly with Aave’s ethos of continuous step-by-step improvements and expansion.

Aligning with Aave’s Goals

FRAGOLA is in line with Aave’s vision for GHO, focusing on interoperability, security, modularity and community-driven growth. It can be configured to use CCIP as described in the original proposal and we believe it could be an effective foundational block on which to build the codebase for this GHO Cross-chain Strategy proposal.

A Journey in the Making

The existing implementation of FRAGOLA, built in the hackathon context, is meant to be just a first step. Your insights and feedback are crucial to shaping FRAGOLA’s future efforts.

If you are interested in diving deeper you can have a look at the ETHGlobal hackathon showcase page which includes a video, the initial codebase and some additional resources.

Thanks for your time in providing feedback and considering the use of FRAGOLA,

the Cross-chain Alliance

[Jommi]

Very sad to see this.

So all GHO on non-ethereum chains is now basically controlled by whatever node configuration Chainlink has in its PoS system at a current time.

Like an earlier commenter expressed, one MIGHT be ok with this in regards to chains where a more secure bridge is not possible (Solana, Sui, Cosmos etc.), but to use this for rollups were the security of the native bridge is indisputable?

Why? Why not isntead do some kind of liquidity network with liquidity partly funded by the DAO and the message passing for that can be done via CCIP.

[oneski22]

@CL_Michael

Chainlink CCIP offers best-in-class security for cross-chain GHO token transfers.

I would directly push back against this. For any network with a canonical bridge - such as OP Mainnet, Arbitrum One, Base, Polygon PoS, Metis, Scroll, Polygon zkEVM, zkSync - CCIP will be “best-in class” compared to any other external bridge or oracle system, but will always be a level below the canonical solution.

@CL_Michael

expanding Aave’s usage of Chainlink with CCIP token transfers for GHO means there are little-to-no additional trust assumptions being introduced into the Aave ecosystem with this proposal.

I would pose the question to the DAO on if we view GHO & Aave as the same system. Presently with the Aave V3 Market being the only facilitator this is a fair assertion, however as new facilitators are spun up such as the GSM or RWA or other exotic concepts, the amount of issued GHO via these means may eclipse the V3 Market - at that point with GHO tied into many other systems, shouldn’t we consider solutions with zero trust assumptions (such as canonical bridges, where “trusting the network” is the real question) where available.

[Cross-chain-Alliance]

Regarding the discussion points on using CCIP vs native bridges, we’d like to expand on how FRAGOLA would be a good fit there, given the time we have dedicated on addressing this very point.

Under the hood the FRAGOLA framework uses Hashi for cross-chain communications, a very thin and credibly neutral oracle aggregator already integrated with 15+ bridges including CCIP and canonical bridges. This is a highly flexible, forward compatible and efficient solution as it enables the GHO community to seamlessly integrate CCIP for optimal scenarios and effortlessly switch to canonical bridges when they are deemed a better choice. This abstraction helps to avoid vendor lock-ins and complexities related with the integration of multiple solutions on multiple routes.

[bgdlabs]

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.

[ChaosLabs]

Chaos Labs supports the Cross-Chain GHO Strategy through the CCIP integration. However, we agree with the strategy proposed by BGD through a.DI, i.e., leveraging an aggregate approach following the canonical bridge implementation, aiming to maximize security while minimizing latency.

Aave DAO Permissions:

In the context of governance permissions pertaining to GHO facilitator capacity and rate limiting parameterization, the alignment of such parameters must be continuously considered from the relative lens of GHO circulating supply. The fragmentation of GHO liquidity must be concentrated around Ethereum itself in percent terms rather than distributed across multiple chains due to the GHO liquidity contingency in the event of a market downturn. As GHO is only mintable on Ethereum itself, GHO liquidity incentives tailored to utilization on external chains should reflect an adequate buffer in maintaining most GHO activity on Ethereum. This buffer is essential to ensure targeted liquidity distribution and enhance resilience in the face of potential market fluctuations.

Current GHO Liquidity Distribution:

Following the introduction of the stkGHO incentive plan (marked by the red line), there’s a noticeable reduction in GHO availability in liquidity pools. This decrease, influenced by peg corrections and improved yields for liquidity pool depositors, has reached 50% over the past week and a half.

Currently, around 40% of all minted GHO, which amounts to 14 million, has been placed in stkGHO, serving as “idle” liquidity. With the anticipated increase in the GHO minting cap, stkGHO is expected to expand, driven by its current yield of 11% APR.

GHO Liquidations:

With the passing of this proposal, GHO will functionally become the only cross-chain collateralized debt position (CDP) stablecoin that employs a first-come-first-serve fixed liquidation bonus as an incentive for liquidators while only allowing new issuance on Ethereum. CDP stablecoins such as MIM and MAI may employ fixed LBs while cross-chain, however minting occurs on any given chain, leveraging the underlying liquidity on said chain in the context of liquidations. DAI, LUSD, and crvUSD, on the other hand, while only issued on Ethereum, do not employ traditional liquidation mechanisms but rather some iteration with respect to time, or an idle “stability pool” in LUSD’s case. Thus, the carefully crafted allocation of liquidity incentives is crucial, especially in the genesis stage.

In a swift market downturn, the expectation is for GHO minters, irrespective of the source chain, to repay debts on native Ethereum concurrent with active liquidation by liquidators and withdrawal of GHO by liquidity providers. Insufficient liquidity on Ethereum, stemming from the uneven distribution of GHO across various chains and/or potentially misaligned incentives on Ethereum itself, can be exacerbated. Large GHO debt distributed on other chains may necessitate tapping into Ethereum’s GHO liquidity for rapid debt repayment or pose a theoretical challenge for liquidators attempting to liquidate from a more extensive, effectively cross-chain debt pool. This could result in a lack of an incentive to liquidate positions due to the upward market price deviation from the underlying price of $1 within the protocol.

The current distribution of “GHO at Risk,” collateralized by non-stablecoins, is presently within reasonable bounds concerning GHO’s existing liquidity. However, the risk associated with “GHO at Risk” may intensify due to the increasing cumulative exposure alongside the relative stagnation of GHO liquidity on Ethereum. Monitoring and addressing this trend becomes crucial to mitigate any adverse effects on the overall stability and risk profile of the GHO system.

Ethereum → Other Chains:

We suggest flexibly adjusting facilitator caps based on the cumulative distribution of GHO CDPs and the targeted Ethereum liquidity ratio, including the GSM, with respect to the total GHO circulation.

Rate limiting for transfers from Ethereum to other chains should consider GHO interest rates. High interest rates, generally indicating GHO’s value is below $1, suggest ample GHO liquidity, warranting a more lenient rate-limiting strategy. On the other hand, low interest rates, aiming to boost GHO demand and indicating its value is likely above $1, call for tighter rate limits to prevent excess supply in the market.

Other Chains → Ethereum:

When managing rate limits from other chains to Ethereum, the approach should be more permissive, especially during market downturns where settling GHO debt swiftly is crucial. In such situations, easing rate limits poses few risks since Ethereum acts as the central hub for managing GHO debt, ensuring an optimal balance between user experience and protocol security.

[MarcZeller]

The ACI has two opinions on this topic:

Crosschain GHO is a short-term strategic product for the Aave protocol, and the @AaveLabs solution is a “good enough” solution to implement in the immediate term. Delays are too costly from a strategic PoV.

We have full confidence in both the CCIP infrastructure & the Avara implementation.

That being said, we echo also in full the remarks of @bgdlabs. especially on using native bridges when they’re trustless and available.

This support is for the future of crosschain GHO & mid-term implementation.

to put it simply, the ACI will cast a YAE vote on this TEMP CHECK but will support initiatives in the future to upgrade & optimize the cross-chain GHO infrastructure mid-term.

[PennBlockchain]

We support giving GHO cross-chain functionality and implementing CCIP as the mechanism to facilitate this! This is a great opportunity, especially with GHO back at peg.