[ARFC] GHO Cross-Chain Launch


This ARFC proposes initiating the cross-chain strategy for the GHO stablecoin, the native asset of the Aave Protocol, beginning with the initial expansion to the Arbitrum network. This expansion will utilize Chainlink’s Cross-Chain Interoperability Protocol (CCIP). After extensive discussions concerning the cross-chain token model, the bridge, and potential networks, we are presenting a detailed post that encapsulates all pertinent information regarding this strategy.


The current accessibility of GHO, primarily through minting on the Ethereum mainnet or via secondary markets, significantly limits its potential reach and utility within the DeFi landscape. Transitioning to a cross-chain model will enhance GHO’s accessibility and liquidity, appealing to a broader user base. Additionally, integrating with alternative chains could greatly improve the overall user experience by offering faster transactions and reduced costs, thus making GHO a more attractive financial tool. This shift also presents new opportunities within the ecosystem of each network, allowing access to a wide array of integrations with other protocols and tools, further enriching GHO’s utility and appeal.


Cross-Chain Token Model

The minting of newly issued GHO is exclusively governed on the Ethereum blockchain, with all liquidity of GHO on other chains originating from Ethereum. This design choice is strategically influenced by the DAO’s goal to minimize security risks and reduce the attack surface. This approach leverages Ethereum’s strong security features to ensure GHO remains secure and reliable across different platforms.

Using the lock-and-mint model, GHO tokens are managed via a locking and releasing mechanism on Ethereum, while a corresponding mint-and-burn process occurs on other chains. Specifically, when a user wishes to transfer GHO tokens from Ethereum to XYZ chain, the tokens are locked on the Ethereum blockchain. Simultaneously, an equivalent number of tokens are minted on the XYZ chain at a 1:1 ratio and then transferred to the user. Conversely, transferring GHO tokens from the XYZ chain back to Ethereum involves burning the tokens on the XYZ chain, followed by the release of an equal number of tokens on the Ethereum chain. Bridging GHO tokens between non-Ethereum chains is conducted through mint-and-burn operations on both ends, with no effect on the amount of GHO locked on Ethereum chain.

Cross-Chain Token Model

Figure 1. Cross-Chain Token Model

Each network hosting GHO will have a canonical version of the stablecoin, governed by Aave Governance. GHO Facilitator entities enable the onboarding of GHO liquidity from Ethereum to the respective chain. Bridges, acting as facilitators, get assigned a credit limit (e.g. bucket capacity) which limits the amount of liquidity to onboard. This structure allows a correlation between the issuance and removal of GHO liquidity on each chain directly with the reserves maintained on Ethereum. By linking the issuance mechanics directly to Ethereum’s backing, this setup ensures that all GHO tokens across the different networks are fully backed by reserves. This maintains GHO’s integrity and stability as a trusted multichain stablecoin.

Building on the outlined architecture, specifically the decision to mint newly issued GHO exclusively on Ethereum, does not constrain GHO functionality. If the need arises to initiate native minting of GHO on another chain, the process can be accommodated by transferring an equivalent amount of GHO tokens from Ethereum. These tokens would match the corresponding bucket capacity of the new Facilitator designated for that chain. This method ensures that the minting on the new chain is supported by sufficient liquidity and operates seamlessly, maintaining the integrity and balance of GHO distribution across networks.

Chainlink CCIP as The First Bridge

Chainlink Cross-Chain Interoperability Protocol (CCIP)

Chainlink’s CCIP is a standard for cross-chain communication that enables different blockchain networks to interact securely and efficiently. This design allows smart contracts on one blockchain to send messages and execute actions on another blockchain. 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.

CCIP is highly regarded for its adherence to stringent risk mitigation, security, and user experience standards, which are in alignment with the principles and values of the DAO. Here are some of the most relevant characteristics and features of CCIP:

  • Programmable Token Transfers: CCIP token transfers can carry additional instructions for the receiving smart contract on a different blockchain for their intended use, allowing actions such as swapping or staking GHO upon arrival at the destination chain. The transfer of tokens and data take place in one atomic cross-chain transaction, meaning the tokens can always be assumed available when the instructions passed are executed at the destination.
  • No Vendor Lock-in: CCIP does not restrict GHO to adopt additional bridge solutions as needed in the future, preserving its autonomy and ability to adapt and integrate within the evolving landscape of blockchain interoperability.
  • Rate Limits: configurable restrictions on both the quantity of tokens and the value transferred per lane over a period of time, ensuring that the bridge remains protected, as well as allowing for the modulation of bridging activity that can be managed by the DAO.
  • Flexible Billing Mechanism: the costs CCIP incurs for a transaction to be executed on the destination chain are covered by users when they make a transaction on the source chain. CCIP reduces friction for users by supporting various tokens to pay this fee, including the native currency of the source chain (e.g. gas tokens) and in LINK.
  • Highly-Audited Codebase: Both the CCIP onchain and offchain code, including the token pools, have been extensively audited by 14 leading security firms.
  • Built-in Relayers: CCIP’s decentralized Executing DONs improve the user experience by automatically relaying transactions to destination chains and attempting to re-execute transactions under extreme network conditions (such as spikes in gas prices). Additionally, Chainlink offers a portal through which users can permissionlessly execute the transaction again (overriding the gas limit) on the destination chain.
  • Risk Management Network: There is a separate, independent network that continuously monitors and validates the behavior of the primary CCIP network, providing an additional layer of security by independently verifying cross-chain operations. For token transfers specifically, the network has access to additional transaction information (e.g. token, amount) that enables it to perform additional risk management policies that cannot be implemented for arbitrary messaging.

GHO Integration

Contracts provided by CCIP encompass all the technical necessities for GHO token transfers. The TokenPool contract, integral to this infrastructure, supports the lock-and-release functionality required for Ethereum and the mint-and-burn mechanism for remote networks.

For networks requiring mint and burn capabilities, the CCIP TokenPool contract functions as a GHO Facilitator with a designated bucket capacity that regulates the amount of GHO tokens transferable from other networks. Conversely, on the Ethereum network, the TokenPool contract acts as a reserve, locking or releasing GHO based on user transactions to ensure a constant and secure token supply across networks.

GHO CCIP Integration

Figure 2. CCIP GHO Integration

Transferring GHO between chains involves several key actions:

  • From Ethereum to another Non-Ethereum chain:
    • GHO tokens are locked in the TokenPool contract’s reserve on Ethereum.
    • CCIP forwards a token-bridging message to the Facilitator on the destination chain. Rate limit controls are applied to restrict the amount transferred.
    • An equivalent amount of GHO tokens is minted on the destination chain through its Facilitator. The total amount of GHO minted must not exceed the specified bucket capacity.
  • From Non-Ethereum chain to Ethereum:
    • GHO tokens are burned on the non-Ethereum chain via its Facilitator. The amount of GHO tokens burned must not surpass the current bucket level.
    • CCIP forwards a token-bridging message to the TokenPool contract’s reserve on Ethereum. Rate limit controls are applied to restrict the amount transferred.
    • The same amount of GHO tokens is then released from the TokenPool contract’s reserve on Ethereum. There are always sufficient reserves, as all circulating liquidity on other chains is backed by this reserve.
  • Between Non-Ethereum chains:
    • GHO tokens are burned on the source chain and minted on the destination chain, both actions facilitated by their respective Facilitators. Bucket configurations limit the liquidity adjustments on each chain.
    • CCIP forwards the token-bridging message between chains, restricting the amount transferred based on lane’s rate limits.
    • The overall backing of the assets remains on the Ethereum chain to maintain integrity and security across networks.


Figure 3. Alice sends 1000 GHO tokens to Bob on Arbitrum. 1000 GHO remains on ETH as a backing for 1000 GHO on Arbitrum.


Figure 4. Bob sends 500 GHO tokens to Charlie on Avalanche. 1000 GHO remains on ETH as a backing for 500 GHO on Arbitrum and 500 GHO on Avalanche.

CCIP Rate Limits

The liquidity available on each network is determined by the bucket capacity of the Facilitator and the CCIP configuration, involving two kinds of rate limits:

  • TokenPool Rate Limit

This controls the total number of tokens that can be transferred per lane (e.g., between two chains) in a specific direction within a given time. It is defined by the maximum amount of tokens that can be transferred per transaction (capacity) and the rate at which the available capacity gets replenished (refill rate).

For example, a Token Pool Rate Limit with a capacity of 1M GHO and a refill rate of 10 GHO per second for the Ethereum-Arbitrum lane implies that after a user transfers 1M GHO to Arbitrum, the next user must wait at least 1 second to transfer 10 GHO.

Adjustments to this limit can be made as needed via the Aave DAO’s standard governance processes or through more agile mechanisms like RiskStewards. It is also possible not to set a specific limit and rely on other restrictions, such as the Facilitator bucket capacity.

  • Aggregate Rate Limit

This controls the overall USD value that can be transferred on a lane across all supported tokens in a specific direction. Similar to the TokenPool Rate Limit, it involves a capacity and a refill rate, but calculated in USD terms.

For instance, an aggregate rate limit with a capacity of 1M USD and a refill rate of 10 USD per second for the Ethereum-Arbitrum lane where GHO and USDC are supported would mean that a combined transfer of 500 USDC and 500 GHO (assuming each is valued at 1 USD) would deplete the capacity, requiring users to wait at least 1 second to transfer an additional 10 USD worth of tokens.

This limit is governed by the CCIP governance, which can adjust this parameter in collaboration with the Aave DAO based on the activity of GHO. It is possible to exempt GHO from the aggregate rate limit of a lane, thus avoiding any limitation based on the overall USD value transferred.

It’s important to note that changes to the TokenPool Rate Limit can also affect the Aggregate Rate Limit. Any increase in the Token Rate Limit should correspondingly lead to an increase in the Aggregate Rate Limit to ensure that it adequately supports the higher volume of transactions.

Proper configuration of these parameters is essential not only for maintaining the security of the bridge but also for ensuring a positive user experience. Incorrectly set limits can hinder transactions, impacting the bridge’s usability by potentially causing delays when limits are reached. We encourage Risk providers to contribute with their expertise and provide insights on setting appropriate parameters that balance security needs with optimal user experience. This collaboration will help ensure that the bridging functions smoothly and efficiently, while still adhering to necessary risk controls.

Billing Mechanism

Using the CCIP involves two types of costs: gas costs and CCIP fees. Gas costs are paid in the native token of the originating chain (e.g. ETH on the Ethereum chain). CCIP fees, on the other hand, are paid in a specified fee token that is indicated in the bridging message. Notably, all fees are paid on the source chain, and the CCIP fee is designed to cover any gas costs associated with the transaction on the destination chain, safeguarding against fluctuations such as gas spikes.

Chainlink CCIP operates on a flat-fee billing model, where the fee charged is determined by the specific token model and use case. Currently, only LINK and the respective gas token of each chain are accepted as fee tokens within the CCIP system (e.g., LINK and WETH on Ethereum).

For the GHO use case, the fee structure is as follows:

To Non-Ethereum To Ethereum
From Non-Ethereum 0.25 USD in Gas Token
0.225 USD in LINK
5.00 USD in Gas Token
4.50 USD in LINK
From Ethereum 0.50 USD in Gas Token
0.45 USD in LINK

Arbitrum as First Network

Arbitrum GHO

Figure 5. GHO on Arbitrum

As described in earlier posts, the optimal approach for implementing CCIP, is a phased rollout plan, initially launching support on a single network, rigorously evaluating the process, and progressively extending to additional networks over time. Reflecting the preferences expressed in community discussions and recent snapshot votes, the DAO has selected Arbitrum as the inaugural network for implementing the cross-chain strategy for GHO.

To facilitate the launch of GHO on Arbitrum, the Aave DAO has been allocated a total of 750,000 ARB through the Long-Term Incentives Pilot Program (LTIPP). The Aave Liquidity Committee (ALC), in collaboration with DAO service provider ACI, will plan the strategic introduction of GHO to the Arbitrum chain. This effort aims to optimize the potential of GHO, making it an attractive asset on the network and stimulating broader activity. This initiative will focus on leveraging Arbitrum’s ecosystem to enhance GHO’s utility and appeal, thereby fostering increased usage and engagement.

GHO on Arbitrum Aave Pool

The integration of GHO into the Arbitrum Aave pool as a borrowable asset marks a significant initial step for GHO on this network. For the Aave DAO, adding GHO as a new stablecoin option in the Arbitrum pool aligns naturally with its goals, establishing the first practical use case for the native stablecoin on Arbitrum.

Introducing GHO as a borrowable asset in the Arbitrum Aave pool provides a dual benefit: it allows users to supply GHO in exchange for yield, fostering initial demand, and it gives all Arbitrum users access to a new stablecoin option for borrowing. This not only aids in diversifying the risk across different assets but also lays the groundwork for the development of additional products and features.

We strongly encourage Risk providers to participate actively by providing their expertise and strategic advice for the integration of GHO in the Arbitrum Aave Pool. While simply listing GHO as a borrowable asset carries minimal risk and requires less effort, conducting a comprehensive analysis of the risk parameters and exploring other listing options are crucial for its successful integration. This thorough approach will ensure that GHO is introduced in a manner that maximizes its potential benefits while maintaining the overall integrity and stability of the pool.


Aave Labs has been working in close collaboration with the Chainlink CCIP team to ensure the smooth launch of GHO across multiple chains, meticulously preparing all the required technical documentation and artifacts for deployment.

In terms of smart contracts, while the original CCIP contracts were fully compatible with GHO, slight modifications have been introduced to enhance the Aave DAO’s control over the contract logic and enable future upgrades. This strategic adjustment empowers the DAO with more robust risk mitigation and security levers, allowing for swift, independent responses to any risks associated with the bridge’s operation. These changes are currently undergoing a security review by the DAO’s security service providers, @Certora.

Furthermore, Aave Labs has integrated GHO token bridging functionality directly into the Aave UI, facilitating a seamless user experience by enabling users to bridge GHO without leaving the web application. The bridging feature for GHO tokens is already operational on testnets, and efforts are ongoing to launch this feature in the production environment as soon as it goes live.

Conclusion & Next Steps

Aave Labs initiated the discussion for a cross-chain GHO strategy early this year, receiving positive feedback from the DAO. After extensive deliberations regarding the choice of bridge and the network for initial expansion, the DAO has expressed a preference for using Chainlink’s CCIP as the first bridge and Arbitrum as the initial network.

In this final phase, the community is invited to engage in the discussion, offering feedback before the snapshot vote and the AIP. This phase also acts as a call to action for Risk providers (@Chaos Labs) to offer their risk assessment recommendations for the deployment of GHO on Arbitrum. Upon receiving risk parameters, we will proceed to submit a GHO Facilitator Application for CCIP on Arbitrum and then initiate the snapshot vote.


[1] Chainlink CCIP Documentation - Chainlink CCIP | Chainlink Documentation
[2] [TEMP CHECK] GHO Cross-Chain Strategy - [TEMP CHECK] GHO Cross-Chain Strategy
[3] [TEMP CHECK] Rollout plan for Cross-Chain GHO - [TEMP CHECK] Rollout plan for Cross-Chain GHO
[4] [Aave] LTIPP Application - Long Term Incentives Pilot Program - Arbitrum - [Aave] LTIPP Application - FINAL - Long Term Incentives Pilot Program - Arbitrum
[5] Aave UI Testnet for GHO CCIP Bridge - https://bridge-testnet.aave.com/

We are excited about the prospects of GHO-ing cross-chain and look forward to its successful implementation.

Aave Labs


Hi @AaveLabs :ghost:

We are very pleased to see steady progress being made towards the cross-chain deployment of GHO. Regarding CCIP, I have a question: Is there a possibility that the network fees or accepted tokens change? If changes are possible, who has the authority to make those changes?

The future of GHO is cross-chain. Can’t wait to see this proposal in action!


Chaos Labs supports the adoption of the Cross-Chain GHO Strategy and provides initial recommendation for the phased rollout strategy on Arbitrum.


Bucket Capacity for CCIP Bridge

We recommend a staggered deployment strategy that allows us to observe user behavior before there is significant growth in GHO on Arbitrum. This will ideally begin with a relatively small bucket capacity on Arbitrum of 1M. Following this tranche, and as liquidity develops, we recommend increasing the bucket capacity further.

Asset Chain Recommended Capacity Rec. Capacity Second Tranche Rec. Capacity Third Tranche
GHO Arbitrum 1,000,000 2,500,000 5,000,000

CCIP Rate Limits

Given the conservative initial Bucket Capacity, we don’t anticipate a significant impact from additional rate limiting. We will revisit this issue after the initial launch phase, at which point a more aggressive bucket capacity may be recommended.

Risk Parameters

As an initial use case, we would like to provide recommendations on listing GHO on Aave V3’s Arbitrum deployment. As liquidity develops, we recommend listing GHO as a borrowable asset only, not allowing it to be used as collateral given the difficulty with potentially liquidating positions.

We apply a similar methodology used across Aave, in which Slope1 on an Ethereum L2 is set 1 percentage point higher than on Ethereum; should GHO rates on Ethereum adjust, we recommend that these be adjusted in line.

Parameter Value
Isolation Mode No
Borrowable Yes
Collateral Enabled No
Supply Cap (GHO) 1,000,000
Borrow Cap (GHO) 900,000
UOptimal 90%
Slope1 14.00%
Slope2 65.00%
Reserve Factor 10.00%
Liquidation Bonus NA
Liquidation Protocol Fee NA


Given that the early use case for Arbitrum GHO will likely be lending and borrowing on Aave, there is limited need for an Arbitrum GSM at this time. However, as the market develops we will revisit this recommendation.


Network fees and accepted tokens are managed by the CCIP node operators. Chainlink Labs collaborates with the node operators to determine these parameters. Following extensive research by the Chainlink Labs team, the billing mechanism has shifted from a percentage-based system to a flat-fee model, positioning Chainlink as one of the most cost-effective bridge options in the space.

Currently, only LINK and the respective native tokens of each chain are accepted as fee tokens. On Ethereum and Arbitrum this is ETH and LINK. However, discussions are underway to include GHO as a fee token in the future. Enabling users to bridge using only GHO, without the need for other tokens to cover gas or other fees, could simplify transactions and significantly enhance the user experience.


That’s a good idea. We look forward to the discussions going well.

This ARFC has now progressed to Snapshot

1 Like