GHO Cross-Chain - Part 1
01Summary
This AIP proposes deploying GHO stablecoin across chains starting with Arbitrum using Chainlink CCIP. It includes deployment of upgradeable GHO token on Arbitrum, CCIP lock-release pool on Ethereum to back liquidity, CCIP burn-mint pool on Arbitrum to manage minting/burning, and transfer of ownership of these contracts to the DAO. Code has been reviewed by BGD Labs and Certora.
- Type
- protocol addition
Key changes
- Deployment of upgradeable GHO token contract on Arbitrum network(high)
- Deployment of CCIP LockReleaseTokenPool on Ethereum to back liquidity across chains with bridge limit controls(high)
- Deployment of CCIP BurnMintTokenPool on Arbitrum to handle minting and burning of GHO based on Ethereum-backed liquidity(high)
- Transfer of ownership of CCIP token pool contracts to the DAO for control over configuration and rate limits(high)
- Disabling token pool rate limits on both Ethereum and Arbitrum pools(medium)
Notable concerns
- This is Part 1 of a two-part proposal; Part 2 will follow for risk parameter configuration on Arbitrum Aave Pool
- Cross-chain implementation introduces dependencies on Chainlink CCIP infrastructure
- Bridge limit and outbound/inbound rate limit controls require ongoing DAO management
Generated by Kvorum
02Description
Simple Summary
This AIP proposes the cross-chain implementation for the GHO stablecoin, the native asset of the Aave Protocol, beginning with the initial expansion to the Arbitrum network utilizing the Chainlink Cross-Chain Interoperability Protocol (CCIP).
The smart contracts have been refined through multiple stages of design, development, testing, and implementation. For security validations, collaborations with DAO service providers Certora and BGD Labs were established to conduct code reviews.
Following extensive community discussion, this AIP proposes the deployment of cross-chain GHO. This proposal was split into two separate AIPs, whereby, subject to approval of this proposal by the DAO, there will be a second AIP (“Part 2”) for configuration of GHO on Arbitrum Aave Pool adopting risk parameters formulated by Chaos Labs.
Motivation
Transitioning to a cross-chain model beyond Ethereum Mainnet enhances GHO's accessibility and the overall user experience with faster transactions and reduced costs. 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, enriching GHO's utility potential.
Specification
This AIP addresses the implementation of the GHO cross-chain strategy. The following smart contracts have been developed:
- Upgradable GHO Token: This contract version allows the DAO to adjust the logic of the token.
- Modified CCIP Contracts: Tailored versions of the Chainlink Cross-Chain Interoperability Protocol (CCIP) contracts, designed to support the GHO cross-chain implementation.
All smart contracts, including the code for this AIP, have been reviewed by BGD Labs for alignment with the Aave Protocol and by Certora for security aspects, including both manual and formal verification.
Proposed implementation actions are the following:
Ethereum:
- Deployment of CCIP LockReleaseTokenPool Contract: GHO reserve contract backs up liquidity across different chains. A "bridge limit" control enables the DAO to regulate the outflow of GHO liquidity to other networks. The limit is set at the minimum bucket capacity of the bridges across networks to ensure proper validation of GHO transfers on the source chain to facilitate transfers between chains.
- Transfer of ownership of the CCIP LockReleaseTokenPool contract to the DAO: The DAO controls and owns the contract logic and configuration parameters, including the outbound/inbound rate limit and the bridge limit.
- Configuration of CCIP LockReleaseTokenPool contract: token pool rate limit will be disabled.
Arbitrum:
- Deployment of UpgradeableGHO: The contract is configured to be deployed by the DAO upon passing of this AIP.
- Deployment of CCIP BurnMintTokenPool contract: The contract handles the minting and burning processes, based on the liquidity backed from Ethereum.
- Transfer of ownership of the CCIP BurnMintTokenPool contract to the DAO: The DAO will take control of the contract logic and configuration of outbound/inbound rate limit.
- Configuration of CCIP BurnMintTokenPool contract: token pool rate limit will be disabled.
References
- Implementation: AaveV3Ethereum, AaveV3Arbitrum
- Tests: AaveV3Ethereum, AaveV3Arbitrum
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description lists many granular, concrete actions across two networks (Ethereum: deploy LockReleaseTokenPool, transfer ownership, disable rate limit; Arbitrum: deploy UpgradeableGHO, deploy BurnMintTokenPool, transfer ownership, disable rate limit). However, the decoded on-chain data contains only a single top-level action: a call to execute() (decoded as a generic fallback with no arguments) on one Ethereum address. This is the standard architecture for Aave Governance V2/V3 proposals, where the on-chain proposal simply invokes a payload contract's execute() function, and all the granular logic (including any cross-chain CCIP messaging to Arbitrum) is encoded inside that payload contract's bytecode rather than appearing as separate decoded calldata entries in this action list. Because the decoded action provides no visibility into the internal logic executed by execute(), it is not possible to verify whether the specific parameters (bridge limits, ownership transfers, rate-limit toggles) match the prose. There is no evidence of contradiction — the single execute() call is fully compatible with the described scope of work — but the granularity needed to confirm exact parameter matches (e.g., bridge limit values, specific addresses receiving ownership) is unavailable from this data alone. Given this, I mark confidence as low rather than asserting a discrepancy, since flagging a mismatch would require speculation about the contents of the execute() call that we cannot verify from the given data. No numeric mismatches, target mismatches, or extra/omitted actions can be confirmed at the top level, so overall the proposal is treated as consistent pending deeper trace-level verification of the execute() call's internal effects.
Generated by Kvorum
04Actions
- Target
- 0xa6d1…f749
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedGHO Cross-Chain - Part 291%
- aaveexecutedGHO Gnosis Launch89%
- aaveexecutedGHO Base Launch88%
- aaveexecutedGHO Avalanche Launch86%
- aaveexecutedGho X-Layer Activation84%
- aaveexecutedGHO Mainnet Launch84%
- aaveexecutedGHO Ink Launch83%
- aaveexecutedGHO Funding80%
- aaveexecutedGho Plasma Launch79%
- aaveexecutedAave Liquidity Committee Funding Phase IV79%