#Introduction

This report is co-authored by TokenLogic and LlamaRisk.

In this report, we will analyze Aave GHO as a potential pegkeeper asset for crvUSD. The objective of this analysis is to comprehensively assess the risks associated with GHO to determine its suitability for pegkeeper onboarding. Our evaluation will employ both quantitative and qualitative methods to provide insights into the safety of integrating GHO and to recommend any necessary exposure restrictions.

We will categorize the assessment into three main areas:

• Performance Analytics - Concerns related to stablecoin adoption, market liquidity, and volatility.
• On-chain Management - Considerations pertaining to smart contracts, dependencies, and other technology components.
• Regulation and Compliance - Aspects concerning reserves management, centralization potential, and legal/regulatory factors.

This review will include a comparative analysis of existing crvUSD pegkeepers in the final section of this report, providing Curve stakeholders with valuable information to inform decisions on integrating GHO and establishing appropriate parameters.

#Section 1: Stablecoin Fundamentals

This section addresses the fundamentals of the proposed pegkeeper asset. It is essential to convey (1) the value proposition/utility of the stablecoin, and (2) an overview of the on-chain technical architecture. This section contains descriptive elements that cannot be quantified and serves as a descriptive introduction to the stablecoin.

This section is divided into 2 sub-sections:

• 1.1: Description of the Stablecoin
• 1.2: System Overview

#1.1 Description of the Stablecoin

#1.1.1 User Flow

Users can acquire GHO through several pathways:

#Primary Minting (Aave V3 Markets)

Core Market (Ethereum Mainnet) The primary method for minting GHO is through Aave V3's Core Market on Ethereum. Users can deposit approved collateral assets (ETH, wstETH, WBTC, cbBTC, etc.) and borrow GHO against them at variable interest rates set by Aave governance. The process follows standard Aave lending mechanics:

1. User deposits collateral into Aave V3
2. User borrows GHO up to their available borrowing power
3. GHO is minted directly to the user's wallet
4. User pays borrow interest (accrues to Aave DAO treasury)
5. To close the position, the user repays GHO debt + interest, and GHO is burned

Prime Market A curated market with a more conservative set of high-quality collateral assets, designed for users seeking lower-risk borrowing conditions.

Horizon Market (RWA Facilitator) Was Launched in August 2025 and enables institutional borrowers to mint GHO against Real World Asset (RWA) collateral, expanding GHO's backing beyond crypto-native assets.

#GHO Stability Module (GSM)

The GSM enables direct 1:1 swaps between GHO and approved stablecoins (USDC, USDT), serving as a critical mechanism to maintain peg stability.

Current GSM Status:

Source: GHO stability Module (05-02-2026)

Peg Mechanism:

The GSM functions as a two-sided automated market maker with configurable fees that create price boundaries for GHO:

Source: GSM Contract Status (05-02-2026)

• Price Ceiling: When GHO > $1, arbitrageurs mint GHO via GSM and sell on the market. Effective ceiling: $1.000 (USDC) / $1.000 (USDT)
• Price Floor: When GHO < $1, arbitrageurs buy GHO on the market and redeem at GSM for stablecoins. Effective floor: $1.0008 (USDC) / $1.0010 (USDT)

Yield-Bearing Architecture:

The GSM uses stata tokens (stataUSDC, stataUSDT) rather than native stablecoins. These wrapper tokens deposit the underlying USDC/USDT into Aave V3 to earn lending yield (~3-5% APY), generating additional revenue for the DAO while maintaining full redemption capability.

#Secondary Markets

Users can also acquire GHO through decentralized exchanges (Balancer, Curve, Fluid, Uniswap) or centralized exchanges without interacting with Aave directly.

• Fluid
• Balancer
• Uniswap

Source: TokenLogic (05-02-2026)

#1.1.2 Reserves Overview

GHO employs a hybrid collateralization model combining overcollateralized crypto lending with direct stablecoin backing.

#Collateralization

Source: TokenLogic (05-02-2026)

Collateral Composition (Aave V3 Core Market):

The top collateral assets backing GHO borrowing positions include:

• wstETH (Lido Wrapped Staked ETH)
• WETH (Wrapped Ether)
• weETH (ether.fi Wrapped ETH)
• cbETH (Coinbase Staked ETH)
• rETH (Rocket Pool ETH)
• WBTC (Wrapped Bitcoin)
• AAVE (Aave governance token)

This collateral diversity across liquid staking tokens, native ETH, and Bitcoin derivatives provides robust backing for GHO.

#GSM Reserves (1:1 Stablecoin Backing)

Source: GSM Contract Status (05-02-2026)

30% of all GHO is directly backed 1:1 by USDC and USDT held in the GSM, providing exceptional peg stability reserves.

#Secondary Market Liquidity

GHO maintains deep liquidity across major DEX platforms:

Ethereum Mainnet:

Cross-Chain:

Total Liquidity Summary:

• GSM Reserves (underlying stablecoin holdings): $138.8M
• Secondary Market Liquidity: ~$124M
• Total Accessible Liquidity: ~$262.8M

#1.1.3 Fees and Business Model

GHO generates revenue for the Aave DAO through multiple streams:

#Revenue Sources

#Revenue Metrics

#GHO Borrow Rates

GHO borrow rates are set by Aave governance (GHO stewards) rather than algorithmically. Current rates vary by market:

• Core Market: Variable rate set by governance
• Prime Market: Generally lower rates for high-quality collateral

#GSM Fee Revenue

Source: TokenLogic (05-02-2026)

#1.1.4 Organizational Structure

#GHO Stewards

The GHO Stewards is a multisig with delegated authority to make rapid parameter adjustments within predefined boundaries. This enables faster response to market conditions without requiring full governance votes; they take all significant decisions, including:

• GHO borrow rate adjustments
• GSM bucket capacity changes
• New facilitator approvals
• Risk parameter updates
• Cross-chain deployments

Steward Signers:

• ACI (Aave Chan Initiative)
• Chaos Labs
• TokenLogic
• LlamaRisk

Source: Forum Post (05-02-2026)

#Aave Liquidity Committee (ALC)

The ALC manages GHO liquidity incentives and partnerships with DEX protocols. Established in October 2023, the ALC deploys DAO resources to maintain deep GHO liquidity across key trading venues.

ALC Signers:

• ACI (Aave Chan Initiative)
• Chaos Labs
• TokenLogic
• LlamaRisk

#1.1.5 Third Party Relations

#Oracle Provider: Chainlink

GHO uses Chainlink as its primary oracle infrastructure:

• Price Feeds: Chainlink oracles provide collateral price data for Aave V3 markets
• GHO Fixed Price: GHO uses a fixed $1.00 oracle price within Aave (not market-based)
• CCIP (Cross-Chain Interoperability Protocol): GHO cross-chain transfers are secured by Chainlink CCIP

#Cross-Chain Infrastructure

GHO is deployed across multiple chains using Chainlink's Cross-Chain Token (CCT) standard:

Source: Cross-Chain Dashboard (05-02-2026)

#DEX Partners

Balancer: Primary DEX partner for GHO liquidity. Balancer's Composable Stable Pools are the main venue for GHO/stablecoin trading with over $50M in combined liquidity across chains.

Curve Finance: GHO is integrated into Curve pools, including crvUSD/GHO, USDe/GHO, fxUSD/GHO, and a Tricrypto pool. The proposed PegKeeper integration would deepen this relationship.

Fluid Protocol:

Fluid represents one of GHO's most significant DeFi integrations, with over $40M in combined GHO exposure across its unified liquidity architecture, peaking at around $90M TVL.

#1.1.6 History

#Timeline

#Growth Metrics

GHO has demonstrated consistent growth since launch, expanding from a single-chain stablecoin to a multi-chain asset with diversified minting mechanisms and deep liquidity across DeFi.

Importantly, the GSM facilitators (stataUSDC + stataUSDT) have minted roughly 160.7M GHO (~46% of the 347.8M circulating supply), with $138.8M in underlying stablecoin holdings, materially reducing GHO's risk profile.

Source: TokenLogic (04-02-2026)

#1.2 System Architecture

#1.2.1 Stablecoin Overview

GHO operates on a Facilitator model where approved smart contracts can mint and burn GHO up to their allocated bucket capacity. This modular architecture enables flexible expansion of GHO's use cases while maintaining risk isolation.

#Facilitators

#Minting/Burning Process

Collateralized Minting (Aave V3):

1. User deposits collateral → Collateral locked in Aave
2. User borrows GHO → GHO minted to user's wallet
3. Debt position created → Interest accrues to DAO

GSM Minting:

1. User deposits USDC/USDT → Converted to stata tokens
2. GHO minted 1:1 → stata tokens earn yield

GSM Redemption:

1. User deposits GHO → GHO burned
2. stata tokens unwrapped → USDC/USDT returned to user

#Cross-Chain Architecture

GHO uses Chainlink's Cross-Chain Token (CCIP) standard for multi-chain deployment:

• Ethereum: Native GHO (can be minted/burned)
• L2s/Sidechains: Bridged GHO via CCIP (burn on source, mint on destination)
• Canonical Bridging: Only the CCIP-bridged GHO is recognized as canonical

#1.2.2 Architecture Diagram

#1.2.3 Key Components

#GHO Token Contract

The GHO token is an ERC-20 with additional functionality:

• Facilitator Management: Only approved facilitators can mint/burn
• Bucket System: Each facilitator has a maximum mint capacity

#Fixed Price Oracle

Within Aave V3, GHO uses a fixed $1.00 price oracle rather than market-based pricing. This design choice:

• Simplifies borrowing calculations
• Prevents Oracle manipulation attacks
• Relies on GSM arbitrage for actual price stability

#GHO Stability Module (GSM)

The GSM smart contracts enable:

• 1:1 swaps between GHO and approved stablecoins
• Configurable buy/sell fees (set by governance/stewards)
• Exposure caps per underlying asset
• Integration with Aave V3 yield via stata tokens

#sGHO (Savings GHO)

sGHO is the yield-bearing version of GHO, integrated with Aave's Savings Rate mechanism:

• Users deposit GHO to receive sGHO
• sGHO accrues yield from a portion of the GHO borrow interest
• Provides passive yield for GHO holders

#Umbrella Safety Module

The Umbrella Safety Module provides backstop protection for GHO:

• Stakers deposit assets GHO as reserve
• In case of shortfall events, staked assets can be slashed
• Provides an additional security layer for GHO holders

#Cross-Chain (CCIP) Standard

GHO's cross-chain implementation follows Chainlink's CCIP standard:

• Lock & Mint: GHO locked on Ethereum, minted on destination
• Burn & Unlock: GHO burned on L2, unlocked on Ethereum
• Rate Limiting: Configurable limits per chain for security
• Message Verification: CCIP's decentralized oracle network validates transfers

#1.3 Summary Statistics

#Section 2: Performance Analytics

This section evaluates the pegkeeper candidate from a quantitative perspective. It analyzes stablecoin performance metrics in terms of market adoption, peg stability, and liquidity.

This section is divided into 3 sub-sections:

• 2.1: Market Performance
• 2.2: Peg Stability Metrics
• 2.3: Liquidity

#2.1 Market Performance

#2.1.1 Outstanding and Free-Float Supply

• Outstanding Supply: Total amount of stablecoins in circulation over time
• Free-Float Supply: The methodology, developed by CoinMetrics, applies a standardized criterion for which units of supply to exclude from free float. (source: Coinmetrics formula)

Total Outstanding Supply

Source: TokenLogic (04-02-2026)

Free-Float Supply of GHO on Ethereum: To calculate the Free-Float Supply of GHO on Ethereum, we exclude the GHO CCIP Token Pool 0x06179f7C1be40863405f374E7f5F8806c728660A and the Aave Collector 0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c from the Circulating Supply.

Source: Dune-TokenLogic (04-02-2026)

#2.1.2 Market Share in the Overall Stablecoin Supply

According to TokenLogic (04-02-2026), GHO's market cap is $341.21M. Using DefiLlama statistics for other stablecoin market caps, GHO ranks 27th. Stablecoins with similar market caps include Resolve USD (USR) ($390.32M), Solstice USX ($302.3M), and crvUSD (crvUSD) (288.88m).

#2.1.3 Supply Distribution

The supply distribution of a stablecoin can help us understand how it is used. If it is used only on a few exchanges with little other activity, most of the supply will be concentrated in a few addresses. On the contrary, if it's used by many exchanges and users, it will be more broadly distributed. (Coinmetrics)

Supply Distribution Across Chains

Source: TokenLogic (04-02-2026)

Source: Etherscan (04-02-2026)

#2.1.4 Transaction Count and Volume

With overall volume increasing over the past 90 days, GHO usage has also increased, consistent with its market cap.

Source: Dune-TokenLogic (04-02-2026)

#2.1.5 Transfer Value Distribution

If stablecoins are used as a means of payment for retail users, we should see that the majority of transfer value falls below $100 (PayPal's average transaction value in Q1 2020 was around $58). On the other hand, if one sees stablecoins as liquidity rails for traders, then most payments should be high-value.

The transfer value distribution shows that GHO is dominated by large capital holders.

Source: Dune-TokenLogic (04-02-2026)

#2.1.6 Stablecoin Velocity

Stablecoin velocity measures the rate at which the stablecoin changes hands on-chain. The GHO stablecoin velocity for the past 30 days has averaged around 20%. This indicates a high amount of transaction volume relative to its outstanding supply.

Source: Dune-TokenLogic (04-02-2026)

#2.1.7 Active Users

Over the past 7 days, there were almost 1400 active users of GHO. The small number of active users may be partially due to users staking GHO for sGHO and then leaving it to accrue passive yield.

Source: Dune-TokenLogic (04-02-2026)

#2.1.8 User Growth

The unique user addresses that utilize GHO have seen steady growth since its inception.

Source: Dune-TokenLogic (04-02-2026)

#2.1.9 Activity Distribution

The top 5% of active addresses account for over 86% of on-chain transactions involving GHO, suggesting a limited use of the token outside a few venues.

Source: Dune-TokenLogic (04-02-2026)

#2.2 Peg Stability Metrics

#2.2.1 Peg Deviation Frequency

The price of GHO on the Uniswap V3 GHO/USDC 0.05% pool (which, while not the most liquid GHO venue, provides unsmoothed swap-driven pricing) shows no hourly deviations exceeding 50 bps over the past 12 months. Besides this, the GHO peg generally stayed within a ±10 bps range. Notably, over the past 3 months, only 5.9% of hours deviated by more than 10 bps.

Source: TokenLogic (06-02-2026)

#2.2.2 Maximum Peg Deviation

Cross-referencing the Uniswap V3 GHO/USDC 0.05% pool on an hourly basis, the maximum peg deviation over the past 12 months was $0.0037. On a daily close basis, the maximum deviation was $0.0024, indicating that intraday deviations consistently recover within the same day.

Source: TokenLogic (06-02-2026)

#2.2.3 Standard Deviation of Pegged Value

Over the past 12 months on the Uniswap V3 GHO/USDC 0.05% pool, the GHO peg has had an hourly standard deviation of $0.00050, a daily log-return standard deviation of 0.0307%, and an annualized volatility of 0.59%.

Source: TokenLogic (06-02-2026)

#2.2.4 Market Depth at Pegged Value

GHO -> USDC

Source: Defillama (04-02-2026)

USDC -> GHO

Source: Defillama (04-02-2026)

#2.2.5 Peg Recovery Time

Using 10 bps as a threshold for being properly pegged, GHO recorded 105 depeg events over the past 12 months with a median recovery time of 3 hours. In the past 3 months, only 14 depeg events occurred. Here are the largest depeg events by peak deviation over the past 12 months:

It should be noted that the two largest events were prolonged mild drifts (~$0.997–0.998) rather than sharp depegs. Over the past three months, peak deviations have not exceeded 18.4 bps, and most events recover within a few hours.

#2.3 Liquidity

#2.3.1 Supported CEXs and DEXs

Currently, GHO is traded on:

CEXs - Bitget, Gate DEXs - Fluid, Curve, Uniswap, Blackhole, Balancer, Quickswap, Velodrome, Oku Trade, Maverick

#2.3.2 On-chain Liquidity TVL and Depth

Source: GHO liquidity on Ethereum ODOS (04-02-2026)

#2.3.3 Liquidity Pool Distribution

Total GHO in liquidity pools is ~28.67M, the largest balances sit on Fluid (Ethereum) (~9.23M GHO/USDC + ~4.35 GHO/sUSDe) and Balancer (Ethereum ~4.33M Aave GHO/USDT/USDC), with meaningful additional depth on Base (~6.65M) and Arbitrum (~1.78M).

Source: TokenLogic (06-02-2026)

#2.3.4 Liquidity Incentives and Yield

Nearly all of the GHO circulating supply is in sGHO. As seen in the table in the previous section, many of the pools hover between a base APY of 2-5%.

#2.3.5 DEX Trading Volume

Over the past 7 days, GHO has seen approximately $639M in trading volume. Over the last 30 days, the volume reached $2,331M, and over the past 90 days, it totaled $4,495M. 2.3.6 Liquidity Utilization Rate

Source: TokenLogic (04-02-2026)

Over the past 7 days, GHO liquidity utilization on Ethereum has averaged 97.0%. Over the last 30 days, liquidity utilization averaged 81.4%; over the last 90 days, it averaged 51.2%.

Source: TokenLogic (06-02-2026)

Source: TokenLogic (06-02-2026)

#2.3.7 Liquidity Pool Resilience

Pool resilience is assessed over the past 12 months across stablecoin-paired GHO pools on Balancer, Fluid, Curve, and Uniswap (Ethereum) by measuring average execution slippage on trades >$10K, plotted against daily BTC volatility as a proxy for market stress. The following pools were analyzed:

Balancer: GHO-PYUSD, GHO-USDC, GHO-USDT Fluid: GHO-USDC, GHO-USDe, GHO-sUSDe Curve: GHO-USDe, GHO-USR, crvUSD-GHO, fxUSD-GHO Uniswap: GHO-USDC, GHO-USDT

Trade sizes are binned as small ($10K–$50K), mid ($50K–$250K), large ($250K–$1M), and whale ($1M+). Whale trades ($1M+) average only -0.060% slippage, and no visible relationship exists between BTC volatility and slippage magnitude. GHO pools maintain consistent execution quality regardless of market conditions.

Source: TokenLogic

By protocol, Fluid shows the tightest execution (+0.004%), followed by Curve (-0.016%), Balancer (+0.032%), and Uniswap (-0.054%).

Source: TokenLogic (06-02-2026)

#2.3.8 Stablecoin Usage in DeFi

The highest base APY comes from staking GHO into sGHO. The majority of yield-generating venues for GHO on Ethereum come from incentivized liquidity pools.

Source: Defillama (04-02-2026)

#2.3.9 Net Cross-Chain Flow

Source: TokenLogic (04-02-2026)

Cross-chain GHO supply currently totals 15.6M across six networks, representing roughly 4.5% of the 347.8M circulating supply. The vast majority of GHO remains on Ethereum.

#Section 3: On-chain Management

This section addresses the technological properties of the stablecoin. It aims to convey (1) how the on-chain system is architected and where technological risk can arise, and (2) historical performance metrics involving the stablecoin's development and security.

This section is divided into 3 sub-sections:

• 3.1: Operational Overview
• 3.2: Development and Security Metrics

#3.1 Operational Overview

#3.1.1 Smart Contracts

GHO is architected as an ERC‑20 token with a "facilitator" issuance model: the token contract defines privileged roles to add/remove approved "facilitators" and to set each facilitator's minting limit ("bucket capacity"). The token exposes mint/burn entrypoints intended for facilitators; minting is bounded by (bucketLevel + mintAmount) ≤ bucketCapacity, and a facilitator can only be removed once its bucketLevel is zero.

The primary on-chain issuance path is the Aave v3 mainnet market acting as a facilitator: users mint GHO by supplying approved collateral into the lending protocol and borrowing GHO (over‑collateralised), with governance-set parameters (e.g., borrower rate, borrow caps) governing supply dynamics. A key design nuance documented by Aave is that GHO minting is not limited by "available pool liquidity" in the same way as borrowed reserve assets, because the facilitator mints up to its configured cap rather than drawing down existing liquidity.

GHO includes two additional, separately deployed "facilitator-style" components on mainnet that are explicitly intended to support liquidity/peg operations:

• Flash minting via a dedicated GhoFlashMinter contract (a specialised facilitator enabling flashmint/flashloan-like flows for GHO as described in the docs).
• A Peg Stability Module variant called the GHO Stability Module (GSM): a suite of contracts enabling conversions between GHO and governance-approved "exogenous" tokens via GSM instances registered in a GSMRegistry, with separate price and fee strategy contracts, exposure caps, and a "freeze role" mechanism intended to halt conversions if oracle conditions indicate a material deviation of the exogenous token from its intended ratio.

GHO is also deployed cross-chain using a cross-chain messaging and token-pool design. Aave's docs specify (i) all GHO "originates" on mainnet, (ii) cross-chain transfers use lock-or-burn on the source chain and release-or-mint on the destination after message validation, and (iii) the messaging bridge used for these transfers is Chainlink CCIP, approved via Aave governance.

Supported chains and key contract deployments

The deployments below consolidate Aave's documentation and executed governance proposals into a "key contracts" registry for GHO's stablecoin system (token, CCIP token pools, and steward/control contracts where published).

Immutability and upgradeability properties

GHO's on-chain system is composed of a largely non-upgradeable monetary core and role-gated, parameterized modules, with proxy upgradeability used only where operational flexibility is required. The core GhoToken is deployed as a standard (non-proxy) ERC-20 contract and maintains the global facilitator registry (_facilitators, _facilitatorsList). Governance-controlled roles (FACILITATOR_MANAGER_ROLE, BUCKET_MANAGER_ROLE) determine who can add/remove facilitators and adjust bucket capacities, while safety constraints (e.g., facilitators removable only when bucketLevel = 0) prevent orphaned supply exposure. The GhoFlashMinter is also non-upgradeable, but hard-codes key dependencies as immutables (e.g., GHO_TOKEN, ADDRESSES_PROVIDER, ACL_MANAGER) and allows only Pool Admins (via the Aave ACL) to update operational parameters such as the flash fee and treasury recipient.

In contrast, the GHO Stability Module (GSM) is explicitly designed for upgradeability: it includes immutable references to GHO_TOKEN, UNDERLYING_ASSET, and PRICE_STRATEGY, but its operational state (exposure caps, fee strategy, treasury, freeze/seize flags, accrued fees, signature nonces) is initialized via an initialize function and intended to live behind an ERC1967-compatible admin proxy, enabling implementation upgrades without changing addresses or state. Finally, the steward contracts (GhoAaveSteward, GhoBucketSteward, GhoCcipSteward) are immutable deployments (no proxy), but structured as modular controllers with immutable address wiring and bounded, timelocked parameter changes (typically a 1-day minimum delay plus "max change" constraints). This yields a layered design: an immutable core issuance registry and governance controllers, non-upgradeable utility facilitators, and upgradeable stability/bridge modules where evolving operational logic is most likely to occur.

#3.1.2 Dependencies

The stablecoin's safety and peg behaviour inherit critical dependencies from three external-component classes:

1. Oracle dependencies: the Aave protocol relies on third-party price oracles for market operations, and Aave's oracle documentation describes Chainlink price feeds as a primary oracle type used on production markets. In GHO specifically, the GSM's OracleSwapFreezer is documented as consuming Chainlink oracles and governance-defined price bounds to freeze/unfreeze conversions when the exogenous asset deviates from expected ratios, introducing a dependency on oracle correctness, liveness, and on-chain feed update behaviour.
2. Cross-chain messaging dependencies: cross-chain GHO depends on Chainlink CCIP as the messaging layer (explicitly documented as governance-approved for GHO transfers), plus the correctness/security of the token pool contracts and their configuration (rate limits, bridge limits). The CCIP token directory indicates a "Lock/Release" pool on the origin chain and "Burn/Mint" pools on remote chains, which introduces the typical trust assumptions of an off-chain message validation network and its on-chain verification contracts.
3. Exogenous-asset dependencies in the GSM: the GSM converts between GHO and governance-approved external tokens (documented today as USDC/USDT GSM instances on mainnet), so the module is exposed to external asset risks (issuer/blacklist risk for centrally issued stablecoins; depegs; liquidity fragmentation). The "last resort liquidation" and "freeze" features are explicitly framed as responses to exogenous-token risk, but their existence also formalises an operational reliance on privileged actors to intervene under stress.

A further system-level dependency is Aave governance and its cross-chain execution infrastructure. Aave's governance help documentation makes clear that protocol changes are executed through on-chain governance proposals (metadata stored as an IPFS hash plus executable payload), with time-delayed execution (e.g., "short" vs "long" executor delays) and cross-chain payload execution via Aave's delivery infrastructure for multi-chain changes. For GHO, this governance machinery is not just "admin": it is part of normal operations (e.g., adding/removing facilitators, updating caps, steward permissions, and configuring CCIP lanes).

#3.1.3 Access Control

Privileged roles in the GhoToken and facilitator system. Aave documents two core roles in the GHO token contract:

• FACILITATOR_MANAGER_ROLE: adding/removing facilitators.
• BUCKET_MANAGER_ROLE: setting bucket capacity for facilitators.

Facilitators themselves are "contract addresses approved by Aave governance" and are described as the entities that mint/burn GHO under bucket constraints. This makes facilitator admission and cap-setting a principal control plane for supply and risk.

Privileged roles in the GSM system Aave documents the registry and freezer control plane as follows:

• GSMRegistry ownership is held by the Aave governance short executor (i.e., a governance-controlled timelock/executor account).
• Each GSM instance has configurable price/fee strategies and an "exposure cap" parameter set by governance, and the "freeze role" can be used by the DAO (or delegated to an entity) to halt conversions when oracle bounds are hit.

Delegated operational control via GHO Stewards

Aave documents a specialised "GHO Stewards" entity as an additional operational layer, created to adjust GHO market parameters within governance-approved thresholds, using a 3-of-4 multisig comprising service providers across growth, risk, and finance functions.

An executed on-chain governance proposal ("Activate Gho Stewards") specifies concrete role grants to the steward system, including: granting the steward (i) Pool Admin role via the ACL_MANAGER, (ii) Bucket Manager role on the GHO token, and (iii) Configurator role on GSM_USDC and GSM_USDT, plus whitelisting facilitators so the steward can update bucket capacity. The proposal also publishes the steward SAFE and steward contract addresses.

Cross-chain administration of token pools

The initial cross-chain implementation proposal specifies that the DAO takes ownership of token pool contracts (both the origin-chain lock/release pool and remote-chain burn/mint pools) to control configuration parameters such as bridge limits and rate limits. This makes the DAO (and any delegated stewards, if empowered) the ultimate administrator for bridge configuration.

#3.1.4 Operational Security Practices

Aave's published security posture for GHO emphasizes layered preventative and detective controls:

The protocol advertises extensive third-party review coverage, including a dedicated section listing multiple GHO audit and verification reports from independent security firms, as well as formal verification work; these are published under Aave's "Security" resources.

Aave also operates a public bug bounty programme via Immunefi that explicitly includes "sub-systems of GHO" in scope (GHO token(s), Aave pool reserve components underpinning GHO, flash minter, GSM components, CCIP bridge components, stewards, and remote facilitators). The bounty page enumerates prior audits (including upgradeable token and modular steward reviews) and clarifies scope boundaries for CCIP-derived contracts (Chainlink CCIP components covered by the Chainlink programme except for GHO-specific modifications).

For emergency operations specifically tied to peg mechanisms, Aave documents two "circuit-breaker" style controls in GSM design:

• Oracle-bound conversion freezes via the freezer role (OracleSwapFreezer using Chainlink oracles and governance-set bounds).
• Last resort liquidation capability allowing the DAO to pause GSM functionality and liquidate underlying exogenous token balances in worst-case risk scenarios.

Beyond the circuit-breaker mechanism, conventional growth & risk management levers are available like Price Strategy, Fee Strategy, and Exposure Caps.

For protocol upgrade and change management, Aave's governance documentation describes the lifecycle of upgrades as on-chain proposals with time delays (short vs long executor timelocks) and cross-chain execution via delivery infrastructure where required; the GHO cross-chain proposals themselves explicitly mention security validation and review by service providers BGD Labs, Certora as part of the deployment process.

Finally, Aave's own technical documentation for core market operations indicates concrete emergency levers at the lending-market layer (e.g., reserve freezing via the PoolConfigurator, which blocks new supply/borrow while still permitting repayments, liquidations, and withdrawals). While not GHO-specific, this matters for GHO operational management because the primary minting channel is the mainnet lending market; freezing/pausing the GHO reserve is therefore an available containment measure via standard Aave admin pathways.

#3.1.5 Contracts Architecture Diagram

#3.2 Development and Security Metrics

#3.2.1 Development Activity

Development across GHO-related repositories under Aave is moderate and concentrated primarily in the gho-core repository, which shows consistent but not high-frequency commits, while most auxiliary repos (SDKs, wrappers, integrations) exhibit minimal or near-zero recent activity, and several are archived.

GHO development is maintained and stable, but activity is focused on the core contracts with limited ongoing expansion elsewhere.

#3.2.2 Number of Active Developers

TokenLogic estimates that approximately 5–10 developers are actively working on GHO-related components. While the gho-core repository is publicly archived — suggesting that the base token implementation is largely finalized — ongoing development continues in adjacent modules and infrastructure. Recent work (e.g., new chain deployments, sGHO upgrades, GSM improvements) has primarily been led by TokenLogic, with technical validation and review conducted by Aave Labs and BGD. In addition, several other public GHO-related repositories remain active. More broadly, GHO development benefits from Aave's established and well-resourced developer ecosystem.

#3.2.3 Documentation Quality

Aave's GHO is well documented. A general comprehensive introduction to GHO can be found under Ecosystem->GHO. In addition, Aave has an address book which allows for easy identification of GHO-related Addresses.

#3.2.4 Smart Contract Audits

From the aave/gho-core audits index, there are 12 third-party security review artifacts covering core GHO, GhoSteward / GhoStewardV2, the GHO Stability Module (GSM), and later UpgradeableGHO / modular steward workstreams.

#3.2.5 Known Vulnerabilities Count

Across the 12 audits directly related to GHO findings can be summarised as follows:

Across all third-party GHO audits, 168 findings were reported, including 1 high-severity, 12 medium-severity, 32 low-severity, and 123 informational issues, indicating broad review coverage with limited critical exposure.

#3.2.6 Bug Bounty Program Size

Aave runs an ongoing bug bounty through Immunefi. The program covers smart contracts and related attack surfaces and offers rewards of up to $1,000,000 for critical vulnerabilities, with tiers for lower severities. KYC and a proof of concept are typically required.

#Section 4: Regulation and Compliance

This section addresses the extent of consumer protections from a regulatory perspective. The reader should get a clear idea of (1) the solvency and transparency assurances provided by reserves management requirements, and (2) the current state and historical track record of the issuer's regulatory compliance.

This section is divided into 2 subsections:

• 4.1: Reserves Management
• 4.2: Regulations

#4.1 Reserves Management

#4.1.1 Reserve Assets

GHO is described in official materials as a decentralised, overcollateralised stablecoin minted by users against collateral supplied into the Aave Protocol — not an issuer-managed, off-chain reserve portfolio. The "backing" is therefore constituted by (i) user-posted collateral assets in the Aave V3 market(s) supporting GHO minting (via the standard Aave supply/borrow flow) and (ii) any governance-approved facilitator modules (e.g., Stability Module/GSM instances) that can hold specific exogenous tokens subject to governance-set parameters such as exposure caps and freeze mechanisms.

Management is primarily parameter-based and governance-controlled: facilitators are approved by Aave Governance, and each has a governance-defined mint cap ("bucketCapacity"), while user minting remains constrained by collateralisation requirements determined by collateral composition and Aave risk parameters. Risk parameter recommendations are provided by professional service providers who publish their analyses through the Aave governance forum.

"Segregation" is not described as legal or operational segregation of issuer reserve accounts (as in fiat-backed stablecoins); instead, assets remain on-chain within Aave smart contract systems, with risk controls expressed through protocol accounting, role-based permissions, facilitator caps, and module-specific limits. Each borrower's collateral position is tracked individually on-chain, and the protocol's smart contracts enforce separation programmatically — collateral can only be withdrawn when the borrower's health factor permits it.

While the on-chain framework is well-documented through smart contract code and governance parameters, no single formal "Reserve Policy" document analogous to those published by traditional stablecoin issuers was identified. The framework is instead encoded in smart contract logic and governance decisions.

No explicit "reserve investment policy" (in the sense used for issuer-managed reserve portfolios) was found in the reviewed official materials for GHO. The closest analogues are protocol-level risk parameters and controls: collateral eligibility within Aave markets, collateral factors and liquidation thresholds as applied through Aave V3 mechanics, and facilitator/module caps and controls. These function as risk-management constraints rather than an issuer-directed investment mandate over a segregated reserve book.

The GSM holds stablecoin reserves with exposure caps set by governance — this is the closest analogue to an investment policy, with the DAO determining which stablecoins can be held and in what amounts. No formal written investment policy document was identified in publicly available sources.

#4.1.2 Overcollateralization Buffer

GHO is overcollateralised by design. In the core minting pathway (Aave V3 market facilitator), GHO is minted/borrowed against collateral supplied into Aave, and the maximum mintable amount is constrained by the borrower's collateral composition and associated collateral factors/liquidation thresholds (health factor mechanics).

No single protocol-wide overcollateralisation percentage was identified; the effective ratio is collateral-dependent.

In addition to collateralisation, GHO supply is also constrained at the facilitator level via governance-set mint caps ("bucketCapacity") and, for the GHO Stability Module, via module parameters such as exposure caps, fee strategies, and conversion freezes/last-resort liquidation controls.

The overcollateralisation buffer is not imposed by, calibrated to, or monitored under any external prudential/regulatory regime. It is a protocol risk-control feature implemented through smart contract parameters and governance.

Additional Insurance and Safety Mechanisms:

• Umbrella (upgraded Safety Module): Aave describes an on-chain backstop mechanism where users can stake assets (including GHO) and acknowledge potential slashing in a shortfall/deficit event to cover protocol deficits. This operates as a protocol-level deficit coverage mechanism rather than a GHO-specific reserve buffer.
• Liquidation mechanism: Automated liquidations are triggered when a borrower's health factor falls below 1.0, allowing third-party liquidators to repay debt and seize collateral at a discount.
• GHO Stability Module (GSM): Holds stablecoin reserves enabling swaps with GHO at predetermined ratios, with governance-set exposure caps and last-resort liquidation capabilities.

#4.1.3 Custody of Reserves

Official Aave documentation characterises Aave as a decentralised, non-custodial liquidity protocol and describes "self-custody" as a defining feature, with operations handled by permissionless smart contracts. GHO is described as native to Aave and minted by users, with stability mechanisms and controls implemented through Aave governance and protocol contracts rather than an issuer-held reserve account structure. GHO's effective "backing" is held on-chain in Aave market smart contracts (user-supplied collateral represented by aTokens) and, where applicable, within GHO-specific modules (e.g., the GHO Stability Module), which are themselves smart contract vaults. Custody is expressed as control over assets held in audited, open-source smart contracts — not as third-party custodial accounts. Aave Labs explicitly states it does not control or operate the protocol.

No issuer-style custody policy or procedure document was found in official sources (e.g., segregated custody accounts, reconciliation policies, cash management procedures, qualified custodian appointment). No third-party custodian arrangement is described for holding GHO-backed assets in off-chain accounts, as the architecture is on-chain. The closest equivalents are protocol mechanics and controls: (i) Pool contract flows where supplied assets are held by the pool and aTokens are minted as the accounting/claim representation; (ii) Aave governance-set risk parameters; and (iii) module-level constraints (e.g., the GSM's exposure cap limiting how much of an exogenous token a GSM instance can hold). These are technical/parameter controls rather than custodial operational procedures.

#4.1.4 Payment Rails

Official materials indicate GHO is minted/burned through protocol facilitators (not an issuer cash-reserve model) and do not describe a contractual right to redeem GHO for fiat at par via banking rails. "24/7 redeemability" should therefore be interpreted as on-chain convertibility/liquidity rather than redemption against an issuer reserve book.

The primary official par-conversion mechanism is the GHO Stability Module (GSM), which enables swaps between GHO and governance-accepted stablecoins at a predetermined ratio, with the initial implementation focusing on fixed 1:1 pricing. The GSM is explicitly positioned as a peg-support mechanism, accessible via direct integrations (e.g., CoW Swap). These are inherently 24/7, as smart contract interactions are subject to network uptime and gas constraints.

Official governance materials describe controls that can halt or constrain GSM conversions, including debt ceilings/exposure caps, price bounds, and swap freezes (to stop trading when the exogenous asset deviates from the intended ratio), as well as "last resort" actions that can pause/override module behaviour in adverse scenarios. While the rail exists, it is not an unconditional 24/7 redemption guarantee: availability depends on module liquidity/caps and governance-configured safety controls.

GHO can also be converted via secondary-market liquidity (DEX/CEX) and cross-chain availability/bridging infrastructure (Chainlink CCIP). These rails support accessibility and market liquidity, but are not equivalent to a hard redemption at par; pricing depends on market conditions and bridge capacity/operational constraints. The Push by Aave Labs service (MiCA-authorised) is designed to provide euro on/off-ramps but applies specifically to the Push service, not to GHO protocol interactions generally.

#4.1.5 Attestations

No issuer-style reserve attestation framework (e.g., monthly accountant attestations) was identified for GHO. This aligns with GHO's architecture as an overcollateralised stablecoin minted against on-chain collateral, where backing is inherently observable in smart contract state rather than via off-chain custody accounts. Official-facing transparency is primarily achieved through on-chain verifiability and public analytics.

#4.2 Regulations

#4.2.1 License

No explicit "license status" for a GHO issuer was found in the reviewed official GHO materials. Official Aave documentation frames GHO as a decentralised, overcollateralised stablecoin minted by users through governance-approved facilitators with mint caps — not a model in which a central issuer promises redemption at par from an off-chain reserve book.

#4.2.2 Enforcement Actions/Lawsuits

No official disclosure of enforcement actions or lawsuits specifically targeting GHO (as a stablecoin product) was located.

The SEC conducted a four-year investigation into Aave, examining whether the AAVE token or lending pools constituted unregistered securities. On December 16, 2025, the SEC closed the investigation without recommending any enforcement action. The SEC's letter stated that this should not be construed as exoneration and does not preclude future action. This closure occurred within the broader context of the SEC's pullback from crypto enforcement under the post-2025 administration.

#4.2.3 Legal Opinion

A formal legal opinion addressing GHO's classification under the EU Markets in Crypto-Assets Regulation (MiCA) has been reviewed.

Key conclusions of the opinion are as follows:

• Not an Asset-Referenced Token (ART): The opinion concludes that GHO does not qualify as an ART under MiCA because GHO lacks an identifiable issuer in the regulatory sense.
• Not an E-Money Token (EMT): Similarly, GHO is not classified as an EMT because the definition requires a single identifiable issuer maintaining reserves and offering redemption at par — characteristics inconsistent with GHO's decentralised minting model.
• General crypto-asset under MiCA: The opinion situates GHO within MiCA's residual category of crypto-assets (Title II), subject to general information and white paper requirements but not the stricter ART/EMT regimes (Titles III and IV).
• Not a financial instrument under MiFID II: The opinion analyses whether GHO could be classified as a transferable security, money-market instrument, or derivative under MiFID II and concludes it does not meet any of these definitions. GHO does not confer ownership rights, claims on issuer assets, or derivative-like exposures.
• Not electronic money under EMD2/PSD2: The opinion further concludes GHO does not satisfy the definition of electronic money under the E-Money Directive because there is no issuer accepting funds and issuing monetary value.

The opinion is limited to EU law (MiCA, MiFID II, EMD2) and does not address U.S., UK, or other jurisdictions.

#4.2.4 Sanctions Compliance

Interface-level compliance: Official Aave App Terms contain explicit sanctions-related user restrictions and a detailed list of "Prohibited Jurisdictions," reserving broad rights for Aave Labs to restrict access to the App for compliance and risk reasons. The Prohibited Jurisdictions list includes multiple sanctioned regions/countries (Crimea and other Ukrainian regions, Cuba, Iran, DPRK, Russia, Syria, etc.) and captures "any other jurisdictions designated from time to time by the U.S." This is clear, written sanctions/geo-blocking perimeter language at the interface layer.

Protocol-level compliance: There is no official statement that the GHO token contract itself includes an issuer-style blacklist/freeze function analogous to centralised stablecoins (USDC, USDT). At the blockchain level, GHO transfers cannot be blocked or addresses frozen by any party.

#4.2.5 User Restrictions

For ordinary use of the Aave Protocol via the Aave Labs interface, the official legal materials reviewed do not present the core protocol access model as requiring users to undergo KYC with Aave Labs to interact with the protocol. The Aave Terms describe the interface as a self-custodial access layer and disclaim that Aave Labs controls or operates the protocol.

Protocol-level restrictions specific to GHO: No explicit on-chain allowlist/KYC gate for GHO minting or holding was identified. Facilitators can be interacted with directly at the contract layer or through front-ends; the practical restriction is therefore more readily implemented at the interface layer than at the contract layer, unless governance opts for explicit smart contract gating.

There are no investor qualification restrictions for minting or holding GHO. It is available to any user regardless of accreditation status, net worth, or jurisdiction (subject to front-end geographic restrictions).

#4.2.6 Restrictions for Illegal Use

At the interface layer, Aave Labs' App Terms include broad prohibitions against unlawful activity and reserve rights typically used to address illegal use, including the right to restrict or deny access, to comply with legal obligations, and to take action based on risk/compliance determinations. The structure is conventional - users must not use the App for illegal purposes (including sanctions circumvention and other unlawful conduct), and Aave Labs reserves the discretion to suspend/terminate access and to cooperate with legal processes.

The GHO Stability Module documentation and governance materials describe controls such as swap freezes and exposure caps, but these are framed primarily as peg and risk-management controls (e.g., preventing the GSM from accumulating depegged assets or being drained) — not as AML/sanctions enforcement tools per se. Nonetheless, these controls can incidentally limit the utility of certain exploit/abuse patterns by restricting conversion pathways at critical moments.

#4.2.7 Customer Protection

The customer protection regime for GHO is primarily "disclosure-and-allocation-of-risk," rather than consumer protection through promises of redemption or guaranteed outcomes.

The Aave App Terms characterise the App as a self-custodial interface that merely enables user-initiated interaction with decentralised protocols outside the company's control. Key disclaimers include: (a) Aave Labs does not provide brokerage, exchange, payment service provider, financial intermediary, or investment advisory services; (b) no fiduciary relationship exists between Aave Labs and users; (c) services are provided "AS IS" and "AS AVAILABLE" with all warranties disclaimed; (d) users bear sole responsibility for understanding risks of self-custodial wallets and DeFi interactions; (e) users agree to indemnify and hold harmless Aave Labs. This framing defines the user's rights and expectations: Aave Labs is not undertaking execution, custody, or fiduciary duties and is not promising outcomes.

GHO-specific customer protection might be seen as reliant on what is absent — there is no issuer-level redemption right, statutory reserve regime, or an insolvency "claims pipeline" analogous to those of regulated payment stablecoins. A LlamaRisk governance post describes GHO as lacking "statutory reserves" and a "Chapter 11 redemption pipeline," which is relevant for customer protection framing: users should not expect bankruptcy-remote reserve claims.

No specific arbitration or dispute resolution mechanism for GHO-related disputes was identified beyond the general Terms of Service. The decentralised nature means there is no central authority for on-chain dispute resolution.

#Section 5: Pegkeeper Suitability

This section concludes the review of the pegkeeper asset by comparing it with existing pegkeeper assets. The aim is to diversify the pegkeeper basket without introducing undue risk. Finally, we provide an onboarding recommendation.

This section is divided into 2 sub-sections:

• 5.1 Comparative Analysis of Pegkeeper Assets
• 5.2 Recommendation

#5.1 Comparative Analysis of Pegkeeper Assets

#5.1.1 Geographical Correlation

GHO's decentralised model means there is no single regulatory jurisdiction that, if it were to turn hostile, could directly impair GHO's issuance, reserves, or transfer functionality at the smart contract level. The collateral is held in smart contracts, not bank accounts. This provides inherent resilience against single-jurisdictional regulatory action — a fundamentally different risk profile from that of all other pegkeeper candidates.

However, GHO faces a different category of geographical risk: (a) the Aave Labs front-end can be restricted by any jurisdiction, limiting accessibility; (b) the Push service operates under Irish/EU jurisdiction; (c) future regulations mandating identifiable issuers (like MiCA Titles III/IV or the GENIUS Act) could create a hostile environment for decentralised stablecoins generally; and (d) individual collateral assets within Aave may themselves be subject to jurisdictional actions (e.g., if USDC in the GSM were frozen by Circle).

No single jurisdiction can freeze GHO reserves or halt minting/burning at the protocol level. The risk is instead diffuse — multiple jurisdictions could simultaneously restrict front-end access or exchange listings, degrading liquidity and utility without a single point of failure.

Adding GHO as a PegKeeper would introduce the first asset in the composition whose reserves are not dependent on off-chain banking infrastructure or any single government's financial system. GHO's collateral (on-chain crypto assets in Aave V3) is exposed to crypto market risk but is immune to bank freezes, government asset seizures, or single-regulator enforcement actions. This is structurally uncorrelated with the risks affecting other PegKeepers' reserves.

#5.1.2 Peg Stability

This analysis evaluates historical peg performance across USDC, USDT, frxUSD, and GHO using hourly price data sourced from Pyth. Prices were normalized to a $1 peg. For each asset, we computed the deviation from peg (price − 1), absolute deviation, rolling 24-hour standard deviation, and rolling z-scores (mean-adjusted). We further measured tail quantiles and the proportion of time spent outside fixed deviation thresholds (10, 25, and 50 bps). All statistics are based on hourly closes and comparable time windows across assets.

Absolute peg accuracy: USDC exhibits the tightest peg (1.36 bps mean absolute deviation), followed by PYUSD (3.50 bps) and USDT (3.89 bps), and frxUSD (4.23 bps). GHO is the loosest at 6.16 bps, approximately 4.5× wider than USDC. This indicates a structurally wider equilibrium band rather than episodic dislocations.

Tail risk: At the 99th percentile, USDC remains tightly anchored (3.3 bps), while PYUSD, frxUSD, and USDT show moderate tails (~10–16 bps). GHO exhibits the heaviest tail (21.6 bps), though none of the assets breached 50 bps. GHO's weakness reflects more frequent moderate deviations rather than extreme peg breaks.

Structural stability: Rolling 24-hour volatility is lowest for USDC (0.27 bps), followed by USDT (0.94 bps), PYUSD (1.1 bps), GHO (1.02 bps), and frxUSD (1.45 bps). GHO is not the noisiest asset; its peg is consistently wider rather than unstable.

Regime stress: Rolling z-score exceedances (|z| > 2) fall within plausible bounds for all assets. GHO does not display disproportionate abnormal behavior; USDT shows more frequent stress episodes, likely due to a tighter average deviation.

Operational breach frequency: At a 10 bps threshold, breach rates are 0% (USDC), 1.2% (PYUSD), 2.3% (frxUSD), 7.6% (USDT), and 16.5% (GHO). GHO therefore exceeds the 10 bps band roughly once every six hours. Breaches beyond 25 bps are rare for all assets.

#5.1.3 Pegkeeper Pool Liquidity

For the analysis, we will include the most liquid crvUSD/GHO pool alongside the existing pegkeeper pools.

Pool TVL data were retrieved directly from Ethereum via RPC by sampling historical blocks and querying each Curve pool contract for token balances using the balances() method. For each pool, crvUSD and the paired stablecoin balances were summed to compute a TVL proxy in USD terms (assuming $1 parity for stable pairs). Time series were constructed by sampling up to 250 evenly spaced blocks from the specified start block to the current block, ensuring consistent coverage across all pools. TVL contribution percentages were then calculated by normalizing each pool's TVL by the total pegkeeper TVL at each timestamp. Stacked Area Chart of Total TVL

Normalised Stacked Area Chart

As of 2026-02-18, total pegkeeper TVL is approximately $110.35m, led by crvUSD/PYUSD at $57.54m (~52%), followed by crvUSD/USDC at $22.00m (~20%), crvUSD/USDT at $17.22m (~16%), crvUSD/frxUSD at $12.95m (~12%), while the candidate crvUSD/GHO pool remains small at $0.64m (~0.6%).

At its current size, the crvUSD/GHO pool is too small to meaningfully contribute to the peg defense. It would be reasonable to expect TVL growth to at least ~$5.5m (i.e, 5% of the overall TVL) before its impact can be considered substantial. Achieving this likely requires coordinated incentives between Aave (to drive GHO usage) and Curve (to deepen LP liquidity), ensuring the pool has sufficient depth to support stabilizing flows.

#5.2 Recommendation

LlamaRisk supports onboarding GHO as a PegKeeper asset, with a staged ramp that ties debt ceiling increases to observable liquidity and peg-support capacity. Relative to the current PegKeeper basket (USDC/USDT/PYUSD/frxUSD), GHO has historically traded in a somewhat wider "normal" band, but it remains a structurally resilient stablecoin with meaningful on-chain peg infrastructure (most notably the GHO Stability Module, GSM) and a governance process that can respond quickly via stewards. The key question for Curve is therefore less about absolute peg precision and more about sizing exposure so that any residual peg looseness cannot translate into outsized or improper PegKeeper actions.

Curve's PegKeeper architecture already provides meaningful protection here. PegKeepers are designed to trade only when their associated pool becomes imbalanced, and the PegKeeper Regulator supervises price/parameter checks and can effectively halt PegKeeper deposits/withdrawals by setting the allowed amount to zero when checks fail. This mechanism allows onboarding an asset like GHO: if GHO is meaningfully off-peg (or otherwise fails the Regulator's checks), the system prevents updates rather than forcing a rebalance. In our view, these mechanics are sufficient to make GHO safe to onboard, provided the initial ceiling is modest and increases only as market depth strengthens, and peg assurances (as evidenced by strong GSM reserves) remain healthy.

#Recommended staged onboarding parameters (principles + numbers):

Initial (minimum viable) GHO PegKeeper debt ceiling: Set conservatively at ~3–5m. This is intentionally small compared to the largest PegKeepers in the basket and sized to be directionally consistent with today's limited crvUSD/GHO pool depth (sub-scale relative to the existing PegKeeper pools). The goal is to enable integration, monitoring, and organic liquidity formation without making GHO a primary line of peg defense on day one.

First scale-up target (liquidity milestone): Increase toward ~10–15m once the crvUSD/GHO pool sustains roughly "low-single-digit %" of total PegKeeper TVL (e.g., on the order of ~5% as a heuristic), and demonstrates stable day-to-day execution quality. This ties risk to the pool's ability to absorb PegKeeper flows without creating self-induced volatility.

Higher ceiling eligibility (peg assurance milestone): Only consider moving beyond ~15m once GHO's peg support remains strong and credible at the system level. Here, the GSM matters: maintaining higher ceilings should be contingent on GSM reserve depth and usability remaining healthy (e.g., ample underlying reserves and an operational configuration that continues to keep GHO tightly bounded near $1 in practice). If GSM depth is materially reduced or governance actions (fees/buckets) meaningfully widen the effective redemption band, we recommend ratcheting the GHO ceiling back down until peg assurances strengthen.

Incentives / TVL expectations: We do not view incentives as a prerequisite for onboarding, but they are the cleanest lever to ensure staged onboarding succeeds. Because PegKeeper's effectiveness scales with pool depth, Curve should expect that meaningful ceiling increases will require the crvUSD/GHO pool to grow, likely via Aave-led liquidity management. A simple policy stance is to increase gauge weighting in tandem with each ceiling step, once the pool shows durable TVL (not just short-lived mercenary inflows).

Bottom line: Onboard GHO, but treat it as an additive diversifier to the PegKeeper basket, not a replacement for the tightest-peg assets. Structure onboarding so it earns its way into larger limits. With Curve's existing PegKeeper/Regulator safeguards that can block action when conditions are not met, plus a staged ceiling that scales with (i) sustained crvUSD/GHO liquidity and (ii) continued GSM-backed peg assurance, we believe GHO can be integrated without materially degrading crvUSD's PegKeeper risk profile.

#Disclaimer

TokenLogic and LlamaRisk are both service providers to Aave. Neither has been commissioned nor compensated specifically for producing this report. This report is presented for informational purposes for the benefit of Curve stakeholders. The information is provided for informational purposes only and should not be construed as legal, financial, tax, or other professional advice.