Liquidity providers deposit funds into Aperture and receive trading fees from traders (supply-side fees).

Aperture is a non-custodial DeFi exchange protocol built on Manta Pacific (originally a fork of Uniswap). Aperture was founded by Gao Han, Lian Zhu, and Peiqian Li in 2021.

Aperture team & investors own and govern the protocol. They do not currently take a cut of the total trading fees paid by traders (revenue). Aperture's investors include ParaFi Capital, Arrington XRP Capital, Costanoa Ventures and Divergence Ventures.

github

twitter

discord

website

Exchanges (DEX)

Aperture

# Aperture Tradeable pairs Methodology

## 1. Overview

Tradeable pairs measures the cumulative number of unique trading pairs available on the Aperture decentralized exchange over time. This metric tracks the growth of liquidity pool diversity by counting each new token pair that becomes available for trading, providing insight into the platform's market breadth and development trajectory. The calculation identifies when new liquidity pools are created through smart contract events and maintains a running total of all tradeable pairs by chain.

## 2. Data sources

- **Factory contract events**: Parsed `PoolCreated` events from the Aperture v1 Factory contract on Manta chain, containing token pair addresses, fee tiers, and pool creation timestamps
- **Token metadata**: Reference data containing token symbols, decimal precision, and chain information for all supported tokens

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Identify all unique trading pairs created on the Aperture platform
- **Logic**: Extract `PoolCreated` events from the Aperture v1 Factory contract on Manta chain. Each event contains the addresses of two tokens (`token0` and `token1`), the fee tier, and the newly created pool address. The fee tier is normalized by dividing by 10^6 to convert from integer representation to decimal format. Each combination of token0, token1, and fee tier represents a unique trading pair.
- **Key fields**: Event timestamp (`block_timestamp`), token addresses (`token0_address`, `token1_address`), fee tier (`fee_tier`), and pool address (`account_address`)

### Component B: Token metadata enrichment
- **Purpose**: Add human-readable information to trading pairs
- **Logic**: Join the pool creation events with token metadata to obtain token symbols and decimal precision for both tokens in each pair. Create readable pair names by concatenating the symbols with a hyphen (e.g., "USDC-ETH"). Handle cases where token metadata may be missing by using empty strings as fallbacks.
- **Key fields**: Token symbols for name creation (`symbol`), decimal precision (`decimals`), and formatted pair name (`account_name`)

### Component C: First appearance tracking
- **Purpose**: Determine when each trading pair first became available
- **Logic**: For each unique trading pair (identified by pool address), find the earliest block timestamp when it was created. Truncate timestamps to daily boundaries to standardize the time granulation. This establishes the "birth date" of each tradeable pair.
- **Key fields**: First appearance date (`timestamp`), chain identifier (`chain`), and unique pool address (`account_address`)

### Component D: Daily new pair counting
- **Purpose**: Count how many new trading pairs were introduced each day
- **Logic**: Group the first appearances by date and chain, then count the distinct number of pool addresses that appeared for the first time on each day. This provides the daily increment of new tradeable pairs by chain.
- **Key fields**: Date (`timestamp`), chain (`chain`), and count of new pairs (`pair_count`)

### Component E: Time series gap filling
- **Purpose**: Ensure continuous time series without missing dates
- **Logic**: Apply zero-filling logic to handle any gaps in the daily time series. Days with no new pairs are explicitly set to zero rather than being omitted, ensuring a complete chronological sequence for accurate cumulative calculation.
- **Key fields**: Complete date range (`timestamp`) with zero-filled pair counts (`pair_count`)

### Final aggregation
- **Combining components**: The daily new pair counts are processed through a cumulative sum calculation partitioned by chain and ordered by timestamp
- **Currency conversion**: Not applicable - this is a count metric
- **Time aggregation**: Daily boundaries are used throughout, with timestamps truncated to the start of each day
- **Final calculation**: Running cumulative sum of new pairs over time, where each day's tradeable pairs total equals the sum of all new pairs from the beginning of time through that date, calculated separately for each chain

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Number of unique token pairs available for trading on the exchange.

Aperture

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown