GHO

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.

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

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:

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

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

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.

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

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

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.aaveFacilitatorButcketMaxCapacity - ghoReserveData.aaveFacilitatorBucketLevel

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

GHO is repaid just like any other asset, by approving the Pool contract to spend GHO tokens (by approval transaction or signed permit and repayWithPermit).

What is different about GHO is the calculation of accrued interest. See the discount dynamics section for more info on how accrued interest affects balances for repayment.

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

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 borrow falls below one, which occurs when the sum of borrow value exceeds the weighted average of liquidation thresholds of collateral assets, then any address is eligible to make a liquidationCall on the Pool contract.

The liquidationCall repays up to 100% of the GHO borrow position in exchange for an equivalent USD valuation of the collateral plus a liquidation bonus.

See the developers liquidation guide for more information.

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.

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.

The GSMRegistry is a smart contract that stores a list of all GSM instances. This contract is owned by the Aave Governance Short Executor.

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:

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.

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.

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.

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 Governence to freeze/unfreeze based on oracle conditions.

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.

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 by 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 facilitates the locking and burning of GHO on Ethereum and other chains, enabling GHO's presence across multiple DeFi ecosystems.

CCIP Subgraph: Track GHO's cross-chain activity through subgraphs for Ethereum and Arbitrum:

See the Aave Labs interface bridging integration as a reference for token bridging.