logo
menu
About UsCareersBlog
Pegkeeper Onboarding Review: Aave's GHO

TokenLogic

March 2, 2026

Pegkeeper Onboarding Review: Aave's GHO

Pegkeeper Onboarding Review: Aave's GHO

Pegkeeper Onboarding Review: Aave's GHO

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, providing insights into the safety of integrating GHO and recommending any necessary exposure restrictions.

We will categorize the assessment into three main areas:

This review will involve a comparative analysis against existing crvUSD pegkeepers in the final section of this report, providing Curve stakeholders with valuable information to make informed decisions regarding the integration of GHO and the establishment of 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.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 deposit approved collateral assets (ETH, wstETH, WBTC, cbBTC, etc.) and can borrow GHO against their collateral 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) Launched in August 2025, Horizon 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 peg stability mechanism.

Current GSM Status:

GSM FacilitatorUnderlying TokenHoldingsGHO MintedBucket CapUtilization
stataUSDCwaEthUSDC83.8M97.3M100.0M97.25%
stataUSDTwaEthUSDT55.0M63.4M65.0M97.60%
Total138.8M160.7M165.0M97.39%

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

Peg Mechanism:

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

AssetBuy Fee (Burn GHO)Sell Fee (Mint GHO)
USDC0.08%0.00%
USDT0.10%0.00%

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

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.

image Source: TokenLogic (Accessed 05-02-2026)

1.1.2 Reserves Overview

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

Collateralization

MetricValue
GHO Borrower Collateralization Ratio2.53x
GHO Borrower Collateral Value~$499M
Total GHO Supply522.3M
Circulating Supply347.8M

Source: TokenLogic (Accessed 05-02-2026)

Collateral Composition (Aave V3 Core Market):

The top collateral assets backing GHO borrowing positions include:

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

GSM Reserves (1:1 Stablecoin Backing)

MetricValue
GSM GHO Minted160.7M
GSM Share of Total Supply30%
Stablecoin Holdings138.8M (stataUSDC + stataUSDT)

Source: GSM Contract Status (Accessed 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:

ProtocolPoolTVL
FluidGHO/USDC$42.22M
FluidGHO/sUSDe$22.63M
BalancerGHO/USDT/USDC$30.58M
Curve/ConvexfxUSD/GHO$2.21M
Total Mainnet~$97.6M

Cross-Chain:

ChainProtocolPoolTVL
BaseBalancerUSDC/GHO$12.82M
ArbitrumBalancerGHO/USDT/USDC$8.65M
Other chainsVariousVarious~$5M
Total Cross-Chain~$26.5M

Total Liquidity Summary:

1.1.3 Fees and Business Model

GHO generates revenue for the Aave DAO through multiple streams:

Revenue Sources

SourceDescription
GHO Borrow InterestInterest paid by users borrowing GHO against collateral
GSM Swap FeesFees on GSM swaps (0.08-0.10% to redeem GHO, 0% to mint GHO)
GSM Stata YieldYield earned on stablecoin deposits in Aave V3
Prime/Horizon YieldInterest from Prime and Horizon market borrowers

Revenue Metrics

MetricValue
Total Revenue to Date$21.8M
Annualized Revenue (30d avg)$14.1M
Weekly Revenue$253.9K
Daily Revenue$37.5K

GHO Borrow Rates

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

GSM Fee Revenue

GSMTotal Swap Fees Collected
stataUSDC$41,375.06
stataUSDT$50,993.10
Total$92,368.16

Source: TokenLogic (Accessed 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:

Steward Signers:

Source: Forum Post (Accessed 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:

1.1.5 Third Party Relations

Oracle Provider: Chainlink

GHO uses Chainlink as its primary oracle infrastructure:

Cross-Chain Infrastructure

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

ChainStatusBridge
EthereumNative-
ArbitrumLiveCCIP
BaseLiveCCIP
AvalancheLiveCCIP
GnosisLiveCCIP
InkLiveCCIP
Lens (Arrow)LiveCCIP
PlasmaLiveCCIP

Source: Cross-Chain Dashboard (Accessed 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

DateMilestone
July 2022GHO proposed in Aave governance forum
July 2023GHO launches on Ethereum mainnet
September 2023GHO Stability Module (GSM) deployed
October 2023Aave Liquidity Committee (ALC) established
April 2024GHO Stewards multisig activated
July 2024GHO launches on Arbitrum via CCIP
October 2024GSM upgraded to stata tokens (yield-bearing)
February 2025GHO launches on Base via CCIP
August 2025Horizon Market (RWA facilitator) launches
2025Expansion to Avalanche, Gnosis, Ink, Lens, Plasma

Growth Metrics

MetricLaunch (Jul 2023)Current
Total Supply0$522.3M
Circulating Supply0$347.8M
GSM Capacity0$165.0M
Chains Deployed18
Revenue Generated$0$21.8M

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.

image Source: TokenLogic (Accessed 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

FacilitatorTypeBucket CapacityCurrent Minted
Aave V3 CoreCollateralized LendingVariable~300M
Aave V3 PrimeCollateralized LendingVariable~100M
GSM stataUSDC1:1 Swap100M97.3M
GSM stataUSDT1:1 Swap65M63.4M
FlashMinterFlash Loans50M0 (transient)
HorizonRWA CollateralVariableTBD

Minting/Burning Process

Collateralized Minting (Aave V3):

User deposits collateral → Collateral locked in Aave →
User borrows GHO → GHO minted to user wallet →
Debt position created → Interest accrues to DAO

GSM Minting:

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

GSM Redemption:

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

Cross-Chain Architecture

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

1.2.2 Architecture Diagram

                                    ┌─────────────────┐
                                    │   Aave DAO      │
                                    │   Governance    │
                                    └────────┬────────┘
                                             │
                    ┌────────────────────────┼────────────────────────┐
                    │                        │                        │
            ┌───────▼───────┐       ┌───────▼───────┐       ┌───────▼───────┐
            │   Aave V3     │       │     GSM       │       │   Horizon     │
            │ Core/Prime    │       │ USDC/USDT     │       │   (RWA)       │
            └───────┬───────┘       └───────┬───────┘       └───────┬───────┘
                    │                       │                       │
                    │                       │                       │
            ┌───────▼───────────────────────▼───────────────────────▼───────┐
            │                          GHO Token                            │
            │                    (Ethereum Mainnet)                         │
            └───────────────────────────┬───────────────────────────────────┘
                                        │
                            ┌───────────┴───────────┐
                            │    Chainlink CCIP     │
                            └───────────┬───────────┘
                                        │
        ┌───────────┬───────────┬───────┴───────┬───────────┬───────────┐
        │           │           │               │           │           │
    Arbitrum      Base     Avalanche        Gnosis        Ink        Lens

1.2.3 Key Components

GHO Token Contract

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

Fixed Price Oracle

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

GHO Stability Module (GSM)

The GSM smart contracts enable:

sGHO (Savings GHO)

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

Umbrella Safety Module

The Umbrella Safety Module provides backstop protection for GHO:

Cross-Chain (CCIP) Standard

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

Summary Statistics

CategoryMetricValue
SupplyTotal Supply522.3M
Circulating Supply347.8M
GSM Minted (1:1 backed)160.7M (30%)
CollateralizationBorrower Ratio2.53x
Borrower Collateral~$499M
LiquidityGSM Reserves$138.8M
DEX Liquidity~$124M
Total Accessible~$262.8M
RevenueTotal to Date$21.8M
Annualized (30d)$14.1M
IntegrationsChains Deployed8
Fluid Protocol TVL~$100M+
PriceCurrent Spot$0.9989
GSM Floor$1.0000
GSM Ceiling$1.0008-$1.0010

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.1.1 Outstanding and Free-Float Supply

Total Outstanding Supply

image

Source: TokenLogic (Accessed 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.

image

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

2.1.2 Market Share in the Overall Stablecoin Supply

According to TokenLogic (Accessed 04-02-2026), GHO's market cap is $341.21M. Using DefiLlama statistics for other stablecoin market caps, this places GHO as the 27th largest stablecoin by market cap. 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 only used on a few exchanges without much 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 image Source: TokenLogic (Accessed 04-02-2026)

image

Source: Etherscan (Accessed 04-02-2026)

2.1.4 Transaction Count and Volume

With overall volume increasing over the past 90 days, it shows an increase in GHO usage, consistent with its market cap increasing.

image

Source: Dune-TokenLogic (Accessed 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, the majority of payments should be of high value.

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

image Source: Dune-TokenLogic (Accessed 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.

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

2.1.7 Active Users

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

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

2.1.8 User Growth

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

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

2.1.9 Activity Distribution

The top 5% of active addresses have contributed to over 86% of on-chain transactions involving GHO, indicating a potential lack of use for the token outside of a few venues.

image

Source: Dune-TokenLogic (Accessed 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, in the past 3 months, only 5.9% of hours deviated beyond 10 bps.

PositiveNegative
Count (12mo)6788,036
Avg deviation+0.9 bps-7.3 bps
Max deviation+18.5 bps-37.0 bps

image Source: TokenLogic (Accessed 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. image Source: TokenLogic (Accessed 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%. image Source: TokenLogic (Accessed 06-02-2026)

2.2.4 Market Depth at Pegged Value

GHO -> USDC image

USDC -> GHO image Source: Defillama (Accessed 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:

DatePeak DeviationDirectionTime to Recovery
5/29/2537.0 bpsbelow328 hours
7/18/2533.8 bpsbelow379 hours
2/10/2521.1 bpsbelow19 hours
6/12/2519.6 bpsbelow84 hours
11/17/2518.4 bpsbelow86 hours

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

image Source: GHO liquidity on Ethereum ODOS (Accessed 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). image

Source: TokenLogic (Accessed 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%.

MetricValue7d Change
sGHO Circulating Supply270.79M+12.61M
sGHO APY5.07%-0%
% GHO Supply in sGHO52.4%+2%

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.

image Source: TokenLogic (Accessed 04-02-2026)

2.3.6 Liquidity Utilization Rate

Over the past 7 days, GHO liquidity utilization has had an average of 97.0% on Ethereum. Over the last 30 days, the liquidity utilization averaged 81.4%, and over the last 90 days, the average was 51.2%.

image

Source: TokenLogic (Accessed 06-02-2026)

PeriodAvg Utilization
7d97.0%
30d81.4%
90d51.2%
180d41.5%

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 market stress proxy. 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.

image

Source: TokenLogic

Size BinTrade CountWeighted Avg SlippageMedian Slippage
small43,810+0.015%-0.002%
mid32,445-0.001%+0.000%
large6,903-0.015%+0.011%
whale850-0.060%+0.022%

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

image

Source: TokenLogic (Accessed 06-02-2026)

ProtocolTrade CountWeighted Avg Slippage
Balancer30,648+0.032%
Fluid24,778+0.004%
Curve23,776-0.016%
Uniswap4,806-0.054%

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.

image Source: Defillama (Accessed 04-02-2026)

<!-- ### 2.3.9 Stablecoin Usage in TradFi ==needed?== *Stablecoin usage as the underlying asset for lending, borrowing, fundraising activies in traditional finance* -->

2.3.9 Net Cross-Chain Flow

ChainGHO Amount
Base5,407,233
Ink4,046,015
Arbitrum3,145,961
Lens1,269,679
Gnosis994,780
Avalanche740,603
Total15,604,271

Source: TokenLogic (Accessed 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.1.1 Smart Contracts

<!-- *Description of the technical on-chain architecture of the stablecoin, including supported chains and any associated contracts. Include immutability properties of the contracts. List deployment addresses.* -->

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:

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).

ChainKey contracts (address)
EthereumGhoToken 0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f<br>GhoCCIPTokenPoolEthereum 0x06179f7C1be40863405f374E7f5F8806c728660A<br>GhoFlashMinter 0xb639D208Bcf0589D54FaC24E655C79EC529762B8<br>GhoGsmSteward 0xD1E856a947CdF56b4f000ee29d34F5808E0A6848<br>GSMRegistry 0x167527DB01325408696326e3580cd8e55D99Dc1A<br>GSMUSDC 0xFeeb6FE430B7523fEF2a38327241eE7153779535<br>GSMUSDT 0x535b2f7C20B9C83d70e519cf9991578eF9816B7B<br>GSMUSDCFixedFeeStrategy 0xE5025A7c15a44283A0616567181587eE6A646D64<br>GSMUSDTFixedFeeStrategy 0xA4346AEa575fCf5777D32F419E5850E5c68B2329<br>GSMUSDCFixedPriceStrategy 0x00e89F4022FD13AD56e321D50612Eec598eF3b72<br>GSMUSDTFixedPriceStrategy 0x20Be7090711995336A13e24B9EA9e05ac2cdd8C0<br>GSMUSDCOracleSwapFreezer 0x29F8c924B7aB50649c9597B8811d08f9Ef0310c3<br>GSMUSDTOracleSwapFreezer 0x6439DA186BD3d37fE7Fd36036543b403e9FAbaE7<br>GHO_AAVE_CORE_STEWARD 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34<br>GHO_BUCKET_STEWARD 0x46Aa1063e5265b43663E81329333B47c517A5409<br>GHO_CCIP_STEWARD 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39<br>RISK_COUNCIL 0x8513e6F37dBc52De87b166980Fa3F50639694B60
ArbitrumGHOToken 0x7dfF72693f6A4149b17e7C6314655f6A9F7c8B33<br>GHOCCIPTokenPool 0xB94Ab28c6869466a46a42abA834ca2B3cECCA5eB<br>GHOAaveCoreSteward 0xd2D586f849620ef042FE3aF52eAa10e9b78bf7De<br>GHOBucketSteward 0xa9afaE6A53E90f9E4CE0717162DF5Bc3d9aBe7B2<br>GHOCCIPSteward 0xCd5ab470AaC5c13e1063ee700503f3346b7C90Db
BaseGHOToken 0x6Bb7a212910682DCFdbd5BCBb3e28FB4E8da10Ee<br>GHOCCIPTokenPool 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34<br>GHOAaveCoreSteward 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39<br>GHOBucketSteward 0x3c47237479e7569653eF9beC4a7Cd2ee3F78b396<br>GHOCCIPSteward 0xB94Ab28c6869466a46a42abA834ca2B3cECCA5eB
Gnosis ChainGHOToken 0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73<br>TokenPool 0xDe6539018B095353A40753Dc54C91C68c9487D4E<br>GhoCcipSteward 0x06179f7C1be40863405f374E7f5F8806c728660A<br>GhoAaveSteward 0x6e637e1E48025E51315d50ab96d5b3be1971A715<br>GhoBucketSteward 0x6Bb7a212910682DCFdbd5BCBb3e28FB4E8da10Ee
MantleGhoToken 0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73<br>GhoTokenPool 0xDe6539018B095353A40753Dc54C91C68c9487D4E<br>GhoBucketSteward 0x2Ce400703dAcc37b7edFA99D228b8E70a4d3831B<br>GhoCcipSteward 0x20fd5f3FCac8883a3A0A2bBcD658A2d2c6EFa6B6<br>GhoAaveCoreSteward 0xA5Ba213867E175A182a5dd6A9193C6158738105A
AvalancheGHOToken (CCIP directory) 0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73<br>TokenPool (Burn/Mint) 0xDe6539018B095353A40753Dc54C91C68c9487D4E

Immutability and upgradeability properties

GHO’s on-chain system is composed of a largely non-upgradeable monetary core plus role-gated, parameterized modules, with selective use of proxy upgradeability 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: immutable core issuance registry and governance controllers, non-upgradeable utility facilitators, and upgradeable stability/bridge modules where evolving operational logic is most likely.

3.1.2 Dependencies

<!-- *Describe any external components of the stablecoin design that introduces additional risk or trust assumptions e.g. a proof of reserves oracle.* -->

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 plus governance-defined price bounds to freeze/unfreeze conversions if the exogenous asset deviates from expected ratios, which introduces 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, configuring CCIP lanes).

3.1.3 Access Control

<!-- *Describe the privileged roles and role assignments within the on-chain system.* -->

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

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:

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 comprised of 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

<!-- *Describe the security practices of the on-chain operational management, any emergency procedures the protocol team attests to have in place, and protocol upgrade procedures.* -->

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, plus 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:

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

<!-- *Visual diagram of the technical onchain architecture of the stablecoin, including any associated contracts, privileged roles managing the stablecoin, and typical operations like mint/redeem/oracle update.* --> 
graph TD
    subgraph "Core"
        GhoToken["GhoToken Contract (ERC20 + Facilitator Registry)"]
    end

    subgraph "Facilitators"
        AaveFacilitator["Aave V3 Pool Facilitator (GhoAToken/GhoVariableDebtToken)"]
        FlashMinter["GHO Flash Minter"]
        GSM["GHO Stability Module (Gsm/Gsm4626)"]
    end

    subgraph "Governance & Control"
        AaveGov["Aave Governance"]
        GhoAaveSteward["GhoAaveSteward"]
        GhoBucketSteward["GhoBucketSteward"]
        GhoGsmSteward["GhoGsmSteward"]
        GhoCcipSteward["GhoCcipSteward"]
    end

    subgraph "External Integrations"
        Underlying["Underlying Assets (e.g., USDC)"]
        CCIP["CCIP Token Pool"]
    end

    GhoToken -- "mint/burn within bucket" --> AaveFacilitator
    GhoToken -- "mint/burn within bucket" --> FlashMinter
    GhoToken -- "mint/burn within bucket" --> GSM

    AaveGov -- "controls" --> GhoToken
    AaveGov -- "controls" --> GhoAaveSteward
    AaveGov -- "controls" --> GhoBucketSteward
    AaveGov -- "controls" --> GhoGsmSteward
    AaveGov -- "controls" --> GhoCcipSteward

    GhoAaveSteward -- "manages rates/caps" --> AaveFacilitator
    GhoBucketSteward -- "manages bucket capacities" --> GhoToken
    GhoGsmSteward -- "manages exposure/fees" --> GSM
    GhoCcipSteward -- "manages CCIP limits" --> CCIP

    GSM -- "swaps with" --> Underlying
    CCIP -- "bridges" --> GhoToken

3.2 Development and Security Metrics

3.2.1 Development Activity

<!-- *Frequency and volume of code commits, merges, and updates in the stablecoin's repository.* -->

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.

RepositoryDescription^1 Year CommitsLatest Update
gho-coreCore smart contracts & deployment for the GHO stablecoin~119 commitsSep 23 2025 (GitHub)
gho-aptos-ts-sdkTypeScript SDK for GHO on Aptos~0 commitsJan 27 2026 (GitHub)
GhoDirectMinterFacilitator minter/supply/withdraw logic~4 commitsSep 19 2025 (GitHub)
gho-wrapperERC-20 wrapper + permit support~3 commitsSep 18 2025 (GitHub)
paraswap-dex-lib-gho-integration (archived)ParaSwap integration library~377 commitsSep 9 2024 (GitHub)
gho-brand-assetsBranding assets for GHO~2 commitsJul 2 2024 (GitHub)
gho-aipAave Improvement Proposal for GHO~1 commitJan 18 2024 (GitHub)
gho-bug-bounty (archived)Bug bounty related code~21 commitsNov 20 2023 (GitHub)
gho-public (archived)Historical public GHO repo~1 commitOct 17 2022 (GitHub)

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

<!-- *Number of active developers contributing to the protocol codebase.* -->

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

<!-- *Observations about the quality and comprehensiveness of technical documentation.* -->

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 Upgrade Frequency *Frequency of network or protocol upgrades.* -->

3.2.4 Smart Contract Audits

<!-- *Number and scope of 3rd-party codebase security 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.

DateAuditorScope (as titled in repo)Category
2022-08-12OpenZeppelinGHO (core)Audit
2022-11-10OpenZeppelinGHO (core)Audit
2023-03-01ABDKGHO (core)Audit
2023-02-28CertoraGHO (core)Formal verification
2023-07-06Sigma PrimeGHO (core)Audit
2023-06-13Sigma PrimeGhoStewardAudit
2023-09-20Emanuele Ricci (@Stermi)GHO Stability Module (GSM)Review
2023-10-23Sigma PrimeGHO Stability Module (GSM)Audit
2023-12-07CertoraGHO Stability Module (GSM)Formal verification
2024-03-14CertoraGhoStewardV2Formal verification
2024-06-11CertoraUpgradeableGHOFormal verification
2024-06-11CertoraModular Gho StewardsFormal verification

3.2.5 Known Vulnerabilities Count

<!-- *Number of known security vulnerabilities assigned in audits.* -->

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

AuditorHighMediumLowInformationalTotal
OpenZeppelin0351927
ABDK0466777
Sigma Prime1181020
StErMi04112439
Centora00235
Total11232123168

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

<!-- *Size and scope of the bug bounty program.* -->

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

<!-- ### 3.2.7 Historical Downtime *Recorded instances and duration of network downtime due to security breaches. @marin: here we can take perspective from unsuccessful/failed mints/redemptions?* -->

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.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:

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 through aTokens) and, where applicable, within GHO-specific modules (e.g., the GHO Stability Module) that 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 backing assets in off-chain accounts, because 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), described as enabling 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, 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), and "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 through secondary market liquidity (DEX/CEX) and via 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 pulling back 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:

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 Ukraine 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 one where users must undergo KYC with Aave Labs in order 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 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 by promise 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<span>) 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 not present — there is no issuer-level redemption right, statutory reserve regime, or insolvency "claims pipeline" analogous to 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 no central authority exists for on-chain dispute resolution.

Section 5: Pegkeeper Suitability

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

This section is divided into 2 sub-sections:

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 turned 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-jurisdiction regulatory action — a fundamentally different risk profile from 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<span>) 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 restrict front-end access or exchange listings simultaneously, 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 have zero dependency 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

<!-- *Conduct a comparative analysis of the pegkeeper candidate's historical peg strength compared to the existing pegkeeper assets. Show as an overlay of standard deviations from the peg.* -->

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 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.

image

image

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 because of 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 a 10 bps band roughly one in six hours. Breaches beyond 25 bps are rare for all assets.

<!-- Overall, GHO demonstrates the weakest peg tightness in the set but remains structurally stable and free of extreme dislocations. Its profile reflects a wider steady-state band rather than instability. Inclusion as a pegkeeper benchmark is defensible if governance accept deviation within ±10 bps occuring normally for GHO. -->

5.1.3 Pegkeeper Pool Liquidity

<!-- *Chart TVLs in the existing pegkeeper pools (crvUSD/USDT, crvUSD/USDC, crvUSD/frxUSD, and crvUSD pyUSD) and the candidate pegkeeper pool, overlaid in TVL quantity and another TVL percentage of total.* -->

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

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 image

Normalised Stacked Area Chart image

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 peg defense capacity. 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 for 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 rebalancing. 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 strengthen 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 versus 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 to onboarding, but they are the cleanest lever to make staged onboarding succeed. Because PegKeeper 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: 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 such that it should earn 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 have been commissioned or 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.

logo
About UsCareersSolutions

SOON

PartnersBlog

©2024 TokenLogic Inc. All Rights Reserved.

Privacy PolicyTerms & ConditionsFollow us on X