[ARFC] GHO Cross-Chain Launch

Governance
1

Summary

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.

Motivation

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.

Specification

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.

cross-chain-token-model-top

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

cross-chain-token-model-bottom

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.

Implementation

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.

References

[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

11 Likes
2

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?

3

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

4

Summary

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

Analysis

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 13.00%
Slope2 65.00%
Reserve Factor 10.00%
LTV NA
LT NA
Liquidation Bonus NA
Liquidation Protocol Fee NA
Flashloanable YES

GHO Pricing

We recommend using a fixed price to 1 USD, consistent with GHO’s pricing on Ethereum.
This recommendation will be reconsidered if, in the future, there is an intention to use GHO as collateral.

GSM

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.

5 Likes
5

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.

6 Likes
6

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

1 Like
7

This ARFC has now progressed to Snapshot

2 Likes
8

In preperation for the AIP, we have updated the risk parameters in the table in the comment above.
We have reduced the slope1 recommendation from 14% to 13% following the reduction in GHO borrow rates.

3 Likes
9

BGD. Technical high-level review of cross-chain GHO



Introduction

The following is an analysis/review of cross-chain GHO, from a high-level point of view focusing on architectural points, to complement the more low-level security reviews performed by security contributors to the DAO like Certora.

Given that software architecture can be pretty subjective, we try to present our conclusions in a neutral manner, with the following goals:

  • How well the architecture of the new system fits into all existing Aave infrastructure.
  • Finding any potential high-level problems, from bugs, to problematic usage flows of the system in both DAO and user operations.
  • Provide our subjective opinion as experts on all-Aave, while being constructive to the main contributor of this project (Aave Labs).

Props to the @AaveLabs team for sharing the necessary resources used in this analysis and answering all our questions.



Analysis


Ethereum ↔ non-Ethereum: lock/release ↔ mint/burn

The approach of using Ethereum as a “custody” network for bridged GHO is elegant in our opinion, and following similar architecture as other multi-chain systems of the Aave DAO, like its governance: Ethereum is the core where more security assumptions are deposited, while the other networks connected to Ethereum act as additional environments to more optimal use cases.

It is also good to have Ethereum as “source-of-truth” from where the aggregated size of minted GHO can be queried any time.


Implementation-wise:

  • Evaluation of the third-party technology used (CCIP) is outside of this analysis, but the usage of the UpgradeableLockReleaseTokenPool and UpgradeableBurnMintTokenPool seems correct.
  • Adding upgradeability to the pool contracts is a reasonable choice, and our recommendations are:
    • Disable initialisation of the implementation (if not creating any problem to CCIP, which should not) on the constructor of the pool contracts.
    • Given the contracts have at least a proxy admin and owner roles, set as proxy admin the ProxyAdmin contracts already in use for the other systems of the Aave DAO. They can be found on https://search.onaave.com/?q=proxy_admin
  • We did some minor recommendations on the code pull request.


non-Ethereum ↔ non-Ethereum: burn/mint ↔ mint/burn

While to transfer GHO from/to Ethereum the lock/release ↔ mint/burn model is used, the current cross-chain GHO architecture also covers the case of non-Ethereum to non-Ethereum transfer, even if initially only Ethereum and Arbitrum will be deployed.
In this case, the flow of funds happen via pure burn/mint ↔mint/burn: to hypothetically bridge 100 GHO from Arbitrum to Optimism, the 100 GHO would get burnt on Arbitrum and minted on Optimism.

Similar as with the approach on Ethereum ↔ non-Ethereum, this is perfectly legitimate. The pool contract used in this case will be limited to UpgradeableBurnMintTokenPool, and our previous implementation recommendations apply the same.



GHO token contract on non-Ethereum networks

Given that non-Ethereum networks (e.g. rollups) are by general rule more prone to changes, we agree with Aave Labs that making the GHO token smart contracts upgradeable is a perfectly reasonable decision, with upgradeability being managed by the Aave governance.

As a small suggestion, we recommend to expand the documentation (potentially with code diffs) about the differences between Ethereum’s GHO and non-Ethereum’s, complementing the PR.



The non-rollback problem and bridge-limit

In the presented cross-chain GHO architecture, there are mainly 2 entities with different types of permissions in the system:

  • Aave DAO, via its governance contracts. Acting as “super-admin” of the system, capable of giving/revoking permissions, update GHO token configurations (e.g. bucket-sizes) or of cross-chain GHO infrastructure (e.g. rate limit, bridge limit)
  • Chainlink CCIP infrastructure. Whenever an user “signals” a bridging by locking or burning GHO in one network, the CCIP infrastructure handles listens/verifies the action, and processes the minting/release on the destination network.
    To do that, the CCIP infrastructure itself has appropriate permissions on the token pools.

This architecture is completely legitimate, following an Actor model approach: the Aave DAO and CCIP act asynchronously and independently. We will not go into the theoretical details of the model or its application in networking, but the cross-chain GHO system, similar as others like a.DI, follows a fire-and-forget principle approach on the surface: once tokens are locked/burnt to “send” to a different destination, it is assumed that or 1) they will “arrive” somehow (will get minted/released to the user) or 2) it is responsibility of the underlying bridging infrastructure (CCIP) to manage retries.


Both ourselves during the review and the @AaveLabs team realised an architectural problem related with the (current) lack of a rollback mechanism on CCIP, which can be better illustrated with a practical example:

  • Let’s assume that bucket capacity of cross-chain GHO on Arbitrum is 1000 GHO and on Optimism another 1000 GHO, and both are filled.

  • Now, 2 actions happen at almost the same time by different actors:

    1. An user decides to bridge 500 GHO from Optimism to Arbitrum.
    2. The Aave DAO (on Ethereum) via governance executes a payload to reduce bucket size capacity of cross-chain GHO on Arbitrum to 500 GHO.

    Something very important in this scenario: the token pool contract on Optimism used by the user to bridge to Arbitrum has no knowledge at all that the bucket size of the recipient network (Arbitrum) is getting lowered.

  • Given that there is no sequentiality assurance on what action happen first, let’s assume the DAO “mandate” to lower the bucket size on Arbitrum arrives first, and gets executed.

  • CCIP has picked the 500 GHO bridge request from the user (tokens have been burnt on sender side) and should mint on Arbitrum 500 GHO. However, bucket size on Arbitrum at the moment is filled; there is no further capacity.

  • The problem (without the mitigation applied by Aave Labs that we explain afterwards) is that, from our understanding, CCIP has no mechanism to “rollback” the bridging from Optimism → Arbitrum. Meaning that most probably the correct behaviour would be: the user burns his tokens on Optimism → CCIP listens that “request” → CCIP understand that bucket capacity is full on Arbitrum → CCIP manages somehow the minting back of 500 GHO on Optimism, as Arbitrum is not an option.
    But without rollback management, that means the funds of the user trying to bridge could end temporarily locked, until retrying directly on CCIP (if the bucket size was raised), or worst case scenario, until the Aave DAO/CCIP manages the situation ad-hoc.

Roll-back management in systems like this is extremely important, and cases like the previous could be even more complex. For example, it could be the case that both Arbitrum and Optimism bucket sizes got reduced at the same time, but just before the user burnt tokens to bridge.
In that case, the 500 GHO “claim” would be in some type of limbo situation, as 1) Arbitrum can’t mint them and 2) Optimism can’t mint them back either.
This could be solvable for example by having Ethereum as last-resort fallback, given that by design there is always GHO backing there.



Trying to solve this problem, Aave Labs introduced the concept of a Bridge limit in Ethereum. Bridge Limit is a constraint applied on Ethereum whenever trying to bridge GHO to another network, which enforces amount to bridge + current total bridged amount <= bridge limit .

The objective is to have a way on Ethereum to control that the previous case of user funds getting locked simply can’t happen, and this is effectively achieved by introducing an strict procedure to always be respected: whenever the minimum bucket size on any network with cross-chain GHO is raised, the bridge limit should be raised to that value.

Even if this works works, it creates what we think it is a major consequence on the system:

  • Let’s assume cross-chain GHO Arbitrum starts with an hypothetical capacity of 1’000’000 GHO. That means that bridge limit needs to be configured to 1’000’000.
  • Progressively, the Aave DAO or some type of steward contract decides to increase it in multiple steps up to let’s say 20’000’000. Again, that means that bridge limit needs to be increased to 20’000’000 too.
  • Now, let’s assume that a new expansion of cross-chain GHO is decided to any other network, like Avalanche. Ideally, the approach would be to follow the approach of Arbitrum, and start with a relatively small bucket size, like 1 or 2 million GHO.
    However, the limitation of the bridge limit is there: amount to bridge + current total bridged amount <= bridge limit . With current 20’000’000 bridge limit configured, and as bridge limit can’t be reduced to not create lock-up problems, it means that only a 20’000’000 bucket size capacity can be configured initially to any new network.

If we imagine GHO working at scale, with some networks having bucket sizes of maybe 100 million, it is not really acceptable to be limited to only start on any new network with minimum of 100 million bucket size.



This is a complicated problem and we agree that the bridge limit solution proposed by Aave Labs at least solves the lock-up scenario for users, however the side effect operational-wise to the DAO is quite major.

Our recommendations are the following:

  • CCIP must have a roll-back mechanism. We don’t think it is an optional feature, we think it is mandatory on any system dealing with assets.
  • Not expand to any extra non-Ethereum network apart from Arbitrum until this is solved.
  • Most probably, remove the bridge limit constraint. Important to point that if not expanding to further networks, its presence will not “hurt” the DAO, only requiring to update the bridge limit just after the bucket capacity on Arbitrum is increased. From our discussions with them, Aave Labs is keeping that into account, but in our opinion, the back-and-forth behaviour required probably is not worth it to implement.
    Another option to study is to directly disabled non-Ethereum to non-Ethereum communication, which factually would remove any need to bridge limit and will make rollback management simpler (always rolling back to Ethereum).


GHO as non-payment currency for bridging

From the UX point of view, we believe that GHO should have been enabled as payment currency for bridging on day 0, for the following reasons:

  • GHO on Ethereum was appropriately implemented by Aave Labs with support for meta-transactions (permit()), envisioning use-cases of GHO as payment currency.
  • CCIP seems to support already both native and ERC20 payment methods.
  • It simply feels very strange that with cross-chain GHO having the goal of being an innovative cross-chain stablecoin, users can’t use the same stable-coin to pay for bridging costs.

This is purely a limitation of CCIP, not of the implementation of cross-chain GHO by Aave Labs.



Emergency procedures

For our understanding, the cross-chain GHO layer doesn’t provide any emergency mechanism similar to EMERGENCY_ADMIN-controlled actions in for example the Aave pools, apart from rate limiting on CCIP (not enabled initially) and probably some others internal to CCIP.

No matter the entity in control of those, we strongly recommend to have some type of emergency mechanism active at least during the release phase, and document the procedure on how to exercise it, both if on the cross-chain GHO contracts themselves, or in CCIP.


Additionally, some type of usage of Chainlink Proof-of-Reserve could be valuable security-wise to the system.



Activation proposal for cross-chain GHO

Same as with any other Aave governance proposal, we will review the activation payload for cross-chain GHO and Certora will do the same once on-chain.

Before that, we only recommend to map as much as possible permissions configuration, constraints (e.g. bucket size) and ordering of activation actions, given the multiple layers involved.

We will be adding coverage to cross-chain GHO on https://github.com/bgd-labs/aave-permissions-book, for total visibility of the community on the system.



Conclusion

In summary, from our analysis:

  • The basic lock/release/mint/burn architecture by Aave Labs is sound, and aligned with other Aave DAO projects.
  • GHO upgradeable in non-Ethereum networks is a good decision. Same applies for token pools on all networks.
  • A proper rollback management mechanism must be implemented by the bridge provider (CCIP). Highly recommended to not expand to any other network apart from Arbitrum until then, or not enable non-Ethereum to non-Ethereum communication. Potentially deprecate the bridge limit mechanism.
  • Not a blocker from our perspective, but GHO should have been prioritised as payment currency for bridging.
  • Add or/and document the emergency mechanism/procedures of cross-chain GHO.

None of the previous items are technical/security blockers on the current status, but not addressing them could create some technical debt for future upgrades. We really think that any further expansion apart from Arbitrum should only be done after the rollback problematic is addressed.

9 Likes
10

Thank you @bgdlabs for this extensive analysis.

I really want to highlight and echo these two points towards @AaveLabs and Chainlink.

As always security is highly important to me and to Aave user, we should follow this ethos here.
And GHO has been around for quite a while and it was clear that CCIP will be used to bridge GHO. So in my opinion it only makes sense to implement GHO from the beginning.

2 Likes
11

We are grateful to @bgdlabs for their review of the code and their efforts to review the proposed GHO cross-chain system for alignment with other technical areas of the Aave Protocol. We concur with the findings and points addressed in the review and would like to offer some insights regarding some of the issues raised.

Firstly, a new section dedicated to the GHO cross-chain implementation is being developed to be included in the GHO docs. The purpose is to include a guide to developers, covering a range of topics including governance updates, bridge limits, and emergency procedures for a comprehensive understanding of the system.

Secondly, in relation to the GHO integration with the Chainlink Cross-Chain Interoperability Protocol (CCIP), a limit mechanism on Ethereum is included as a first step solution to limit compromising the user experience. Nevertheless, the DAO and the CCIP team should consider having the ability to rollback operations for token transfers. We recommend that the CCIP team prioritizes the support for this feature, allowing GHO to fully leverage it.

We wish to share information about the input received from the CCIP team during the process. We also invite the CCIP team to contribute with further details:

  1. Proof-of-Reserves Oracle: Considering the design and model of cross-chain GHO, setting up an oracle to monitor and verify the backing of GHO’s remote liquidity is feasible. This oracle would not only enhance the security of the Aave Protocol by guarding against potential bridge-related attacks but would also foster collaboration with other protocols. Implementing such an oracle would offer an added layer of security for protocols integrating GHO on remote chains.
  2. GHO as a CCIP Fee Token: Facilitating the use of GHO as a universal fee token across chains is crucial for its adoption as a payment currency. We request that the CCIP team reconsider integrating GHO as an acceptable fee token. This would eliminate the need for users to hold other assets for bridging GHO across chains, streamlining transactions and enhancing user experience.

We are actively engaged in discussions with the CCIP team to explore ideas that could improve the system’s utility, security, and user experience.

The AIP will be submitted, following the implementation of all recommended fixes from the reviews conducted by BGD Labs and Cetora. We want to express our gratitude once again for their diligent efforts in reviewing the proposal by the community and DAO service providers.

If the vote is successful, GHO cross-chain functionality will be enabled from the Aave DAO perspective. However, further configuration will be required on the CCIP side to activate the Ethereum-Arbitrum lane, which is expected to take some additional time for the system to be operational.

Updates on the progress will be shared here. Please stay tuned for updates, GHO is on its way to going live cross-chain.

3 Likes
12

That’s fantastic to witness the on-chain proposal finally going live!

Could you just clarify if the feedback from BGD Labs was incorporated into the final version?

1 Like
13

All suggestions related to CCIP and GHO contracts have been applied, including their activation via AIP. Regarding the integration of GHO with Chainlink CCIP, we are in ongoing discussions and exploration with the team to enhance funcionality and UX of GHO cross-chain. We will provide insights as soon as there is progress.

4 Likes