title: [ARFC] Launch sGHO Cross-Chain
author: @TokenLogic
created: 2026-06-24
Summary
This proposal defines the cross-chain deployment strategy for sGHO, extending the savings product introduced in the sGHO Launch Configuration ARFC to Layer 2 networks. The design maintains a single ERC-4626 vault on Ethereum mainnet as the sole source of truth, using Chainlink CCIP to enable cross-chain deposit and withdrawal flows.
The architecture introduces two complementary paths:
- Fast Path: Pre-provisioned sGHO liquidity on destination chains enables instant GHO-to-sGHO (and vice versa) swaps for retail-sized deposits, modelled on the Direct Staking pattern used by Lido for wstETH cross-chain distribution.
- Slow Path: Larger deposits route GHO cross-chain to the mainnet vault via CCIP, with sGHO bridged back to the user on the origin chain (and vice versa).
Initial deployment targets Arbitrum, with subsequent expansion to CEX-aligned networks to support retail onboarding via the Aave App and Earn integrations.
Motivation
Introducing Cross-chain sGHO
sGHO is an interest-compounding ERC4626 token that accrues yield at the Aave Savings Rate (ASR) on Ethereum. Upon implementation, this proposal expands the sGHO offering to other networks, allowing users to access the sGHO savings product locally from each network. This approach continues the strategy of bringing the product to users and promoting a streamlined user experience through a universal savings vault.
By maintaining a single sGHO vault on Ethereum and distributing the sGHO token across other networks, every user enjoys the same universal savings rate. To enhance the user experience, the cross-chain sGHO implementation uses a Fast lane and a Slow lane for different transaction sizes. The Fast lane allows users to instantly exchange GHO ↔ sGHO without bridging between networks, whilst larger transactions route via the Slow lane, facilitating bridging, depositing, and bridging back transactions on the user’s behalf. We expect the dual-lane approach to deliver an improved user experience for retail-sized user positions (Aave App) via the Fast lane and for larger integrations to route via the Slow lane, reducing the need for secondary-market liquidity.
To support the Fast lane functionality, the Aave DAO will provide working capital that rotates between GHO and sGHO whilst fulfilling users’ orders. The amount of working capital supporting the sGHO liquidity pool locally on each network depends on the user’s position-size profiles and the volume of flows.
A non-exhaustive list of the advantages of having a single sGHO vault on Ethereum is presented below:
-
Centralised accounting.
Single source-of-truth vault. There is only one instance of the sGho vault where GHO can be deposited. -
Supply cap governance is simplified.
The DAO manages one cap parameter rather than coordinating caps across multiple deployments.
-
Liquidity is consolidated.
GHO backing is never fragmented across chains, ensuring withdrawals are always serviced from a single deep pool.
This is the same architectural approach used by Lido for wstETH, where the staking vault exists on the Ethereum with the receipt token distributed cross-chain.
Cross-Chain Demand Drivers
Several near-term integrations require sGHO availability on L2 networks:
Aave App. The Aave App deposits user funds into a vault that allocates across yield sources. sGHO is a primary allocation target. The App requires programmatic deposit and withdrawal flows that work cross-chain without requiring users to interact directly with the Ethereum mainnet.
CEX-Chain Integrations. Partnerships with centralized exchanges operating on dedicated chains need sGHO access for earn products. These integrations are expected to generate predominantly retail-sized inflows, well-suited to the Fast path mechanism.
GhoRouter Composability. The GhoRouter enables atomic swaps between stablecoins (USDC, USDT) and stataTokens to sGHO via the GSM. Extending this flow cross-chain requires sGHO to be bridgeable while preserving atomicity for the Fast path.
Precedent
This architecture follows the pattern established by Lido for wstETH cross-chain distribution, as documented in Chainlink’s Cross-Chain Staking reference architecture. The approach has been validated at scale with wstETH and is adapted here to sGHO’s specific characteristics: ERC-4626 mechanics, GHO’s status as a CCIP fee token, and supply cap constraints.
Specification
Architecture Overview
The cross-chain sGHO system consists of a few core components deployed across the supported chains, plus the existing mainnet sGHO vault and CCIP infrastructure.
The cross-chain sGHO system consists of a few core components deployed across the supported chains, plus the existing mainnet sGHO vault and CCIP infrastructure.
Instant Swap System (L2): Enables instant swapping between GHO and sGHO at the same deposit/redemption rate as the sGHO vault on mainnet. Maintains a balance of pre-provisioned sGHO and GHO liquidity, rebalanced over CCIP. Consists of a Price Oracle, Oracle Pool, and CCIP Sender contracts.
Cross Chain Vault Adapter Contract (Mainnet): Receives GHO from L2 deposits, interacts with the sGHO vault, and sends sGHO back to users via CCIP; vis-versa for redemptions. Used for large deposits and Instant Swap liquidity rebalancing.
Chainlink CRE Workflow. Automates the sweep-and-replenish cycle that keeps the fast path liquidity pool balanced.
CCIP Router (L2): Core CCIP contract where cross chain sGHO deposits and redemptions are initiated by users.
Fast Path (Instant Delivery)
Pre-provisioned sGHO and GHO liquidity sits on the destination chain, enabling atomic swaps:
- User deposits GHO into the Sender Contract on the L2.
- If sufficient sGHO liquidity is available, the user receives sGHO instantly at the current exchange rate.
- Accumulated GHO in the Sender Contract is periodically swept back to mainnet via CCIP and deposited into the sGHO vault.
- Minted sGHO is bridged back to the L2 to replenish the liquidity pool.
This path is optimised for retail-sized deposits where the provisioned liquidity can absorb demand. The DAO provisions sGHO liquidity as part of its ongoing GHO distribution operations, which already involve bridging GHO to fund the vault.
Rebalancing. A Chainlink CRE workflow automates the sweep-and-replenish cycle. When the GHO balance in the Sender Contract exceeds a configurable threshold (or a time interval elapses), the workflow triggers a batch transfer to mainnet, deposits the resulting sGHO into the vault, and bridges it back to the L2.
Exchange Rate. The sGHO share price (assets per share) must be available on destination chains to enable the fast path for executing swaps at the correct rate. A Chainlink Data Feed publishing the sGHO exchange rate (share price in GHO terms) cross-chain is the preferred mechanism, and it should ensure that third-party integrators also have access to the rate.
Initial Fast Path Working Capital
For the initial Arbitrum deployment, the Fast Path is proposed to be provisioned with USD 1.2M of total local liquidity, split between a USD 400k GHO working buffer and a USD 800k sGHO reserve. The Fast Path maintains liquidity on both sides of the swap: local sGHO liquidity enables instant GHO → sGHO deposits, while local GHO liquidity enables instant sGHO → GHO redemptions. This sizing is intended to support typical retail-sized usage.
The sizing is based on empirical analysis of comparable stablecoin savings flows on Arbitrum. The launch configuration is calibrated around the smaller-ticket flow profile that the Fast Path is primarily intended to serve. Larger transactions are not prevented from using the Fast Path if sufficient liquidity is available, but when local liquidity is insufficient, they can route through the Slow Path.
The proposed 2:1 sGHO-to-GHO split reflects the expected launch flow profile. Deposits into the Fast Path consume local sGHO liquidity and increase the local GHO balance, while redemptions consume local GHO liquidity and increase the local sGHO balance. A larger sGHO reserve provides additional headroom for expected early deposit demand.
At launch, each liquidity leg uses a conservative ±30% inventory band around its own target balance. Balances are allowed to drift within their respective bands to avoid unnecessary rebalancing from the normal two-sided user flow. If a leg falls below the lower bound, that leg is replenished back to the target. If a leg rises above the upper bound, excess inventory from that leg may be swept or rebalanced back toward its target balance. These parameters should be recalibrated once live sGHO Fast Path data is available.
Subsequent chains will be sized separately at activation based on observed flows, and the Arbitrum allocation may be increased earlier if launch demand materially exceeds the provisioned liquidity.
Slow Path (Cross-Chain Deposit)
For deposits exceeding available fast path liquidity, the full cross-chain flow executes:
- User initiates a cross-chain transaction to the Cross Chain Vault Adapter contract via the L2 CCIP Router.
- GHO is bridged to Ethereum mainnet via CCIP along with instructions for the vault interaction.
- The Cross Chain Vault Adapter contract on mainnet deposits GHO into the sGHO vault.
- Minted sGHO is bridged back to the user on the origin chain via CCIP.
Latency. Under CCIP v1, this round trip takes approximately 40 minutes due to finality wait times on both chains. CCIP v2.0, rolling out for major lanes in Q2 2026, introduces the Fast Confirmation Rule, reducing the Ethereum finality lag to approximately 13 seconds and bringing the total round trip closer to 5 minutes. The initial deployment will use CCIP v1, with a planned upgrade to v2.0 once live. The optimal migration timing is being discussed with Chainlink and Aave Labs, as the faster finality introduces trade-offs between user experience and security assumptions that require careful evaluation.
User Experience. For users on the slow path, CCIP has an explorer that enables real-time tracking of cross-chain transfers for end-users. Integrators can also use the CCIP API to surface this status in their UI so users understand their deposit is in-flight and secure, even if delivery is not yet complete.
Withdrawal Flow
Withdrawals follow the reverse pattern:
- User initiates a cross chain transaction to the Cross Chain Vault Adapter contract via the L2 CCIP Router.
- sGHO is bridged to Ethereum mainnet via CCIP along with instructions for the redemption.
- The Cross Chain Vault Adapter contract on mainnet redeems GHO from the sGHO vault.
- Redeemed GHO is bridged back to the user on the origin chain via CCIP.
For the fast path, if GHO liquidity is available in the Sender Contract (from recent deposits that have not yet been swept), the user can receive GHO instantly without waiting for the cross-chain round trip.
Fee Handling
CCIP message fees must be covered for each cross-chain transfer. The architecture handles fees differently on each leg:
User-initiated leg (L2 to mainnet). The user pays the CCIP fee on the origin chain. Because GHO is a supported CCIP fee token, users can pay fees directly in GHO without needing to hold a separate token (such as LINK or the native gas token). This is a significant UX advantage specific to GHO.
Return leg (mainnet to L2). The Receiver Contract must hold a balance of the fee token (ETH on mainnet) to pay for the CCIP message sending sGHO back to the user. Two mechanisms ensure this balance is maintained:
- A small fixed fee can be configured to be collected from each deposit in GHO. The contract admin periodically converts accumulated GHO fees to ETH to replenish the fee buffer. The fee can also be set to zero with the DAO covering bridging costs.
- Alternatively, since GHO passes through the Receiver Contract during both deposits and redemptions, a portion of the GHO can be directly used as the CCIP fee token if the contract is configured accordingly, eliminating the need for ETH buffer management entirely.
The final fee treatment will be determined during implementation based on gas cost analysis and UX trade-offs.
Supply Cap Management
sGHO has a maximum supply cap governed by the sGHO steward. Cross-chain deposits via the slow path introduce a potential race condition: between when GHO leaves the L2 and arrives on mainnet, other deposits may consume the remaining cap capacity, causing the deposit to fail.
Mitigation strategy:
- Pre-flight check. UI queries the remaining sGHO supply cap before initiating a cross-chain deposit. If the remaining capacity is insufficient for the requested amount, the transaction reverts with a descriptive error rather than sending GHO into a potentially stuck state.
- Fast path immunity. Pre-minted sGHO already counts against the supply cap at provisioning time, so there is no race condition for fast-path swaps.
- Defensive receiver logic. If a deposit arrives on mainnet but the vault cannot accept it (the cap has been reached between send and receive), the Receiver Contract holds the GHO and waits for three retries. If it still cannot be fulfilled, a manual request has to be triggered to refund the GHO to the origin chain.
- Safety margin. Large deposits via the slow path can be restricted when the remaining cap falls below a configurable threshold at the front-end level (e.g., only Fast-path swaps allowed when less than 10% of the cap remains). This reduces the probability of the race condition occurring while allowing small deposits to continue.
- Proactive monitoring. Alerts trigger when the remaining supply cap falls below 10% of its maximum, enabling proactive governance action (e.g., a cap increase via the sGHO Steward).
Specifically for the Aave App integration, funds flow into an intermediary vault before being allocated to sGHO. The supply cap check occurs at the vault level, not the individual user level, providing an additional buffer against the race condition.
GhoRouter Cross-Chain Extension
The GhoRouter currently enables atomic swaps from stablecoins to sGHO on mainnet. Cross-chain integration requires the following modifications:
- Fast path compatibility. On L2s with fast path liquidity, the GhoRouter can be extended to support atomic flows: user sends USDC, the router swaps to GHO via the local GSM, and deposits into the sGHO fast path pool in a single transaction.
- Slow path limitation. Cross-chain deposits via the slow path cannot be atomic by nature. The slow path will not be supported by the GhoRouter.
Bridge Configuration
Target Chains and Rollout
Audits
Audit plan. All new contracts (Sender, Receiver, CRE workflow configuration, GhoRouter cross-chain extensions) will undergo independent security review before deployment.
The current infrastructure Chainlink offers for its Lido solution needs some modifications to better suit Aave. The current L2 solution only flows in one direction (staking/depositing) and can be withdrawn only on Mainnet. The proposed solution for sGho allows an L2 position to be swapped in either direction, giving users a much better experience. As previously mentioned, the proposed solution will also have the ability to upgrade to CCIP 2.0 where faster confirmations will be available.
The original auditor of the Chainlink contracts was Trail of Bits, and we have already secured them to audit our updated contracts, with the audit currently ongoing. The cost of the audit was $50K USD.
Disclosure
TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.
TokenLogic supports and maintains an independent delegate voting platform within the Aave community.
TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.
Next Steps
- Gather feedback from the community.
- If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
- If the Snapshot outcome is YAE, escalate this proposal to the AIP stage.
Copyright
Copyright and related rights waived via CC0.