GHO Stablecoin

GHO (pronounced go) is a decentralized, over-collateralized stablecoin that is fully backed, transparent, and native to the Aave Protocol. Designed to maintain a value pegged to the U.S. dollar, GHO is minted by users on demand, subject to mint cap limitations set by Aave’s governance. Its stability is maintained through market efficiencies and over-collateralization mechanisms inherent in the Aave Protocol.

GHO is an ERC-20 token deployed on Ethereum that operates through a facilitator model. Facilitators are contracts approved by Aave Governance with the ability to mint and burn GHO, each subject to a governance-defined mint cap. This model allows for flexibility in expanding GHO’s functionality while maintaining decentralized control over the supply.

GHO Token

The GHO Token contract includes specific roles for managing facilitators and their minting capacities:

• FACILITATOR_MANAGER_ROLE: This role is responsible for adding and removing facilitators.
• BUCKET_MANAGER_ROLE: This role is responsible for setting the bucketCapacity for existing facilitators.

Each facilitator is represented by a Facilitator struct, which contains:

• label: A string identifier for the facilitator.
• bucketCapacity: The maximum amount of GHO a facilitator can mint.
• bucketLevel: The current amount of GHO minted by the facilitator.

transfer

The simplest method for transferring ERC-20 tokens is transfer which can be used to send tokens to any address without a prior token approval. The limitation of transfer is that it must be executed directly by the token holder, so it cannot be used within a smart contract function call to retrieve funds from a user (EOA).

transferFrom

To transfer tokens within a smart contract function, transferFrom is the method that is used. The transferFrom function requires the sender to have approved the spender address for at least the transfer amount. There are two methods which can be used to perform the approval:

approve

The standard ERC-20 approve requires an on-chain transaction from the token holder to approve a specified spender and amount.

permit

EIP-2612 permit is a type of token approval which requires two components:

• A signed approval message from the token holder which encodes: owner, spender, amount, nonce, deadline, DOMAIN_SEPARATOR
• An on-chain permit transaction which can be executed from any address

The advantages to using permit in place of approve are that the gas cost of the transaction can be paid for by an address other than the token owner, and can reduce the number of transactions by batching the permit call with another action, an example of this is supplyWithPermit from Aave Protocol V3.

Facilitators

Facilitators are contract addresses approved by Aave Governance to mint and burn GHO tokens. Each facilitator operates under a specific bucketCapacity, controlling the maximum amount of GHO they can generate. Facilitators play a crucial role in maintaining GHO’s stability and integrating it across various platforms and use cases.

GHO Token Functions for Facilitators

Facilitators interact with the GHO token using the following functions:

• mint(address account, uint256 amount): Allows a facilitator to mint amount of GHO tokens to the account. The amount must be greater than 0, and the new bucketLevel (current bucketLevel + amount) must not exceed the facilitator’s bucketCapacity. This function updates the facilitator’s bucketLevel.
• burn(uint256 amount): Allows a facilitator to burn amount of GHO tokens from their own balance. The amount must be greater than 0, and the facilitator’s bucketLevel is decreased by the burned amount.

Facilitator Management Functions

The GHO token contract also provides functions for managing facilitators:

• addFacilitator(address facilitatorAddress, string calldata facilitatorLabel, uint128 bucketCapacity): Callable by an address with the FACILITATOR_MANAGER_ROLE, this function adds a new facilitator with a specified label and bucketCapacity. A facilitator cannot be added if it already exists or if the label is empty.
• removeFacilitator(address facilitatorAddress): Callable by an address with the FACILITATOR_MANAGER_ROLE, this function removes an existing facilitator. A facilitator can only be removed if its bucketLevel is 0.
• setFacilitatorBucketCapacity(address facilitator, uint128 newCapacity): Callable by an address with the BUCKET_MANAGER_ROLE, this function updates the bucketCapacity of an existing facilitator.

Facilitator Query Functions

Information about facilitators can be retrieved using:

• getFacilitatorsList(): Returns a list of all registered facilitator addresses.
• getFacilitator(address facilitator): Returns the Facilitator struct details (label, bucketCapacity, bucketLevel) for a given facilitator address.
• getFacilitatorBucket(address facilitator): Returns the bucketCapacity and bucketLevel of a specific facilitator.

Aave V3 Ethereum Market

The Aave V3 Ethereum Market serves as a primary facilitator for GHO. Users can mint GHO by supplying approved collateral assets into the Aave Protocol and borrowing GHO against them. This process follows standard over-collateralization practices, ensuring the protocol’s security and the stablecoin’s reliability.

Interacting with GHO via the Aave Pool Facilitator is very similar to interacting with a typical Aave reserve asset with one key difference:

• GHO is minted, not supplied, therefore interest rate and available liquidity calculations are based on custom interest rate strategy and facilitator caps respectively

Below are the technical guides for all GHO actions along with their contract references.

Minting

Minting occurs through the borrow function of the Aave V3 Ethereum market. To mint GHO, the process is nearly identical to borrowing any other reserve. To mint, an address must have sufficient collateral which is performed by approving and then calling supply on the Aave Pool with an eligible collateral asset. Once an address has sufficient collateral, it is able to borrow up to a maximum collateral factor determined by its collateral asset composition.

Since GHO is created and not borrowed from suppliers, GHO is not subject to restrictions on available liquidity, and instead, the Facilitator cap and collateralization requirements define the limits to which GHO can be minted as calculated below.

availableFacilitatorCap = ghoReserveData.aaveFacilitatorBucketMaxCapacity - ghoReserveData.aaveFacilitatorBucketLevel

See core functions for more information on integrating Aave borrow functionality.

Repay

Repay GHO like any other asset: approve the Pool to spend GHO and call repay, or sign a permit and call repayWithPermit.

See core functions for more information on integrating Aave repay functionality.

Liquidation

When an address has a GHO borrow position, they are eligible to be liquidated under the same conditions as any other collateralized address. If the health factor of a GHO borrower falls below 1, which happens when total debt value exceeds the collateral value weighted by each asset’s liquidation threshold, any address can call liquidationCall on the Pool contract.

The liquidationCall repays up to 50% of the borrower’s total debt, or all of the GHO debt when the health factor is at or below 0.95 or when the GHO debt or the chosen collateral is worth less than $2,000. In exchange, the liquidator receives collateral of equivalent USD value plus a liquidation bonus.

Flash Mint

Since GHO is not borrowed like a typical Aave reserve, a separate Facilitator is used in place to replicate the flashloan functionality of the Aave Pool.

The FlashMinter Facilitator has a separate minting cap from the Aave Pool. Since all FlashMint transactions are returned in a single transaction, no GHO is ever minted against this Facilitator and the cap is applied to each transaction.

FlashMint is useful for a variety of applications such as liquidations, debt switches, and peg arbitrage. The GhoFlashMinter smart contract implements the following functions:

function maxFlashLoan(address token) external view override returns (uint256)

function getFee() external view override returns (uint256)

function flashLoan(
    IERC3156FlashBorrower receiver,
    address token,
    uint256 amount,
    bytes calldata data
) external override returns (bool)

See the developers flash loan guide for more information on developing flash loan integrations.

Stability Module

A Peg Stability Module (PSM) is a contract that enables the conversion of two tokens at a predetermined ratio. The GHO Stability Module (GSM) leverages the benefits of existing PSM models while innovating upon them in several ways to help further maintain GHO’s peg. The GSM is designed to facilitate conversions between GHO and governance-approved tokens, underpinned by a suite of features designed for flexible operations and risk management.

GSMRegistry

The GSMRegistry is a smart contract that stores a list of all GSM instances. This contract is owned by the Governance V3 ExecutorLvl1.

GSM

Each token pairing in the stability module has a GSM or GSM4626 contract instance that acts as the GHO facilitator and entry-point for buy and sell functionality.

The GSM4626 contract is a special instance of the GSM that supports ERC-4626 tokenized vault shares as the exogenous token.

The parameters and periphery contracts that dictate module operations are detailed below:

Price Strategy

The GSM introduces a flexible Price Strategy framework, enabling the module to adapt its pricing mechanism based on market conditions or strategic objectives. This system supports both fixed and dynamic pricing strategies, allowing for adjustments in response to real-time market data or predetermined conditions. The initial implementation focuses on a fixed 1:1 pricing strategy for simplicity and stability, with provisions for future adaptation to dynamic strategies as dictated by DAO governance.

Fee Strategy

Each GSM instance has a FeeStrategy contract that determines a percentage fee for buy and sell conversions that is allocated to the Aave DAO treasury.

Exposure Cap

The exposure cap is a parameter determined by Aave DAO Governance that sets the maximum amount of an exogenous token the stability module can hold.

Conversion Freezes and Oracle Price Bounds

In case the price of the exogenous token deviates from a determined ratio, the freeze role can be utilized by the Aave DAO or assigned to an entity (autonomous agents or contracts) to respond and halt conversions.

An implementation of the freeze role is the OracleSwapFreezer contract. This contract utilizes Chainlink oracles and price bounds determined by Aave Governance to freeze/unfreeze based on oracle conditions.

Last Resort Liquidations

In case of a rapid increase in risk in an exogenous token, the GSM features Last Resort Liquidations to liquidate the exogenous token. This contract role allows in the worst-case scenarios for the DAO to pause GSM functionality and liquidate the underlying balance of exogenous tokens.

Cross-Chain

All GHO tokens are originated on Ethereum mainnet. GHO is made available to access on other networks using an infrastructure of cross-chain messaging.

The Chainlink CCIP protocol has been approved by Aave Governance as the messaging bridge to facilitate the transfer of GHO between networks.

GHO is transferred between networks by initiating a lock (Ethereum mainnet) or burn (other networks) action on the source network, and a release (Ethereum mainnet) or mint (other networks) action occurs on the destination chain after the cross-chain message has been validated.

The GhoCCIPTokenPoolEthereum contract locks and releases GHO on Ethereum. On every other network, a GHO CCIP token pool burns and mints GHO.

GHO Token Deployments:

• Ethereum Mainnet
• Arbitrum
• Base
• Avalanche
• Gnosis
• Mantle
• Monad
• Plasma
• XLayer

GHO CCIP Subgraph:

• CCIP Ethereum Subgraph
• CCIP Arbitrum Subgraph
• CCIP Avalanche Subgraph
• CCIP Gnosis Subgraph

GHO Liquidity Committee

The GHO Liquidity Committee (GLC) was created in October 2023 to focus solely on the liquidity of the GHO stablecoin. The committee was formed through a governance proposal and consisted of a small team. After a successful initial 3-month period, it was integrated into the Aave Liquidity Committee (ALC).

The ALC’s main responsibilities regarding GHO include:

• Providing analytics and modeling of the liquidity strategy
• Liaising with teams that support the protocols hosting GHO liquidity
• Leading and coordinating the committee’s weekly activities
• Providing critical feedback and helping refine the strategy
• Verifying and signing transactions

The ALC’s performance measures and liquidity targets for GHO can be found on the GHO Analytics platform provided by TokenLogic.

More information regarding the role of the GHO Liquidity Committee can be found in Aave’s Governance forum.

GHO Stewards

The GHO Stewards are four contracts (GhoAaveSteward, GhoBucketSteward, GhoCcipSteward, GhoGsmSteward) controlled by the Risk Council. The source code is on GitHub. Within governance-approved limits, and with at least 1 day between updates of the same parameter, they can adjust:

• GHO Borrow Cap and Supply Cap
• GHO Borrow Rate
• Facilitator Bucket Capacity
• CCIP Bridge Limit and Rate Limit
• GSM Exposure Cap
• GSM Buy/Sell Fees

See Stewards for the current limits.

Savings GHO

Deposit GHO into the sGHO vault to earn a fixed rate with no cooldown period.

Deployed Contracts

Ethereum

Arbitrum

Base

Mantle

Avalanche

Gnosis

Monad

Plasma

XLayer

Sepolia (Testnet)