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

KyberSwap is a non-custodial exchange protocol & aggregator built on Ethereum and other adjacent blockchains. KyberSwap was founded by Loi Luu and Victor Tran in 2017.

KNC tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). Kyber Network raised $52 million in an ICO in 2017.

governance

github

twitter

discord

etherscan

website

DEX aggregators

KyberSwap

# KyberSwap Tradeable assets Methodology

## 1. Overview

The tradeable assets metric measures the total number of unique tokens that can be traded on KyberSwap, categorized by their liquidity levels. This metric answers the question "How many tokens are available for trading and what is their liquidity depth?" The calculation identifies unique tokens from trading pairs, tracks their first appearance, calculates their total liquidity from pool deposits and trading activity, and categorizes them into liquidity cohorts while avoiding double-counting.

## 2. Data sources

The methodology relies on several types of blockchain data and external sources:

- **Pool creation events**: Parsed `Factory_PoolCreated_event`, `KSFactory_PoolCreated_event`, and `ElasticFactory_PoolCreated_event` logs from Kyber v2 and v3 contracts across Ethereum, Arbitrum, Avalanche, BSC, Fantom, Optimism, Polygon, and zkSyncEra
- **Pool activity events**: Parsed liquidity events including `Pool_Mint_event`, `ElasticPool_Mint_event`, `Pool_Burn_event`, `ElasticPool_Burn_event` for deposits and withdrawals
- **Trading events**: Parsed `Pool_Swap_event` and `ElasticPool_Swap_event` logs from AMM and Elastic pools
- **Reserve synchronization events**: Parsed `KSPool_Sync_event` and `DMMPool_Sync_event` logs tracking pool reserve changes
- **Flash loan events**: Parsed `Pool_Flash_event` and `ElasticPool_Flash_event` logs for flash loan fees
- **Transaction data**: Transaction records from supported blockchains for user context and validation
- **Price data**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token decimals, symbols, and addresses for proper calculation and display

## 3. Step-by-step calculation

### Component A: Asset discovery from trading pairs
- **Purpose**: Identify all unique tokens that have ever been tradeable on KyberSwap
- **Logic**: Extract token addresses from all pool creation events across Kyber v2 and v3. Each pool creation event contains `token0_address` and `token1_address` fields representing the two tokens in the trading pair. The methodology processes `Factory_PoolCreated_event`, `KSFactory_PoolCreated_event`, and `ElasticFactory_PoolCreated_event` across all supported chains. For each pool creation event, both `token0` and `token1` are recorded as separate tradeable assets with their first appearance timestamp
- **Key fields**: Extract `block_timestamp`, `token0_address`, `token1_address`, `chain`, and `version` from pool creation events

### Component B: New asset counting
- **Purpose**: Track when new tokens become tradeable and maintain cumulative counts
- **Logic**: For each token discovered in Component A, identify the earliest timestamp when it first appeared on each chain. Group these first appearances by day and chain, counting how many new unique tokens became tradeable each day. Apply gap-filling to ensure continuous daily data, setting asset counts to zero for days with no new tokens. Calculate a cumulative running sum to track total unique tokens available over time
- **Key fields**: Process `timestamp`, `chain`, `token_address` to generate daily `asset_count` and cumulative `tradeable_assets`

### Component C: Asset liquidity calculation
- **Purpose**: Determine the total USD liquidity for each token across all pools
- **Logic**: Calculate net deposits for each token by aggregating flows from multiple sources. For Kyber v2, use reserve synchronization events (`KSPool_Sync_event`, `DMMPool_Sync_event`) to track daily changes in pool reserves by comparing current day reserves with previous day reserves. For Kyber v3, combine deposit flows from `Pool_Mint_event` and `ElasticPool_Mint_event`, withdrawal flows from `Pool_Burn_event` and `ElasticPool_Burn_event` (negated), trading flows from swap events, and flash loan fees. Correct all token amounts for decimals using token metadata, then convert to USD using end-of-day price feeds. For each token, sum USD values across all pools containing that token to get total liquidity
- **Key fields**: Process `token0_amount`, `token1_amount`, `decimals`, `price_usd` to calculate `net_deposits` and aggregate to `total_liquidity`

### Component D: Liquidity cohort classification
- **Purpose**: Categorize tokens by their liquidity levels into meaningful cohorts
- **Logic**: For each token with calculated total liquidity, assign it to one of six cohorts based on USD liquidity thresholds: tokens with liquidity ≥ $1,000,000 go to "> $1m" cohort, ≥ $500,000 to "$500k - $1m" cohort, ≥ $100,000 to "$100k - $500k" cohort, ≥ $25,000 to "$25k - $100k" cohort, ≥ $5,000 to "$5k - $25k" cohort, and all others would theoretically go to "< $5k" cohort. Count the number of tokens in each cohort daily for each chain
- **Key fields**: Transform `total_liquidity` into `liquidity_cohort` categories and count tokens per cohort

### Final aggregation
- **Combining components**: The final result combines three data sources. First, take the cumulative count of all new tokens from Component B as the base "< $5k" cohort count. Second, add the daily counts from Component D for tokens with measurable liquidity in their respective cohorts. Third, subtract the count of tokens that have measurable liquidity from the "< $5k" cohort to prevent double-counting, since these tokens are already counted in their appropriate liquidity cohorts
- **Currency conversion**: All liquidity calculations use end-of-day USD prices applied at the time of each net deposit calculation
- **Time aggregation**: Data is aggregated at daily boundaries using truncated timestamps, with gap-filling applied to ensure continuous time series
- **Final calculation**: The final tradeable assets count for each liquidity cohort represents the number of unique tokens available for trading with liquidity in that range. The "< $5k" cohort shows cumulative new tokens minus those with higher liquidity, while other cohorts show current token counts meeting their liquidity thresholds. A special decommission rule stops including Kyber v3 data after November 23, 2023, due to a contract exploit

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

Number of unique tokens tradeable on the exchange.

KyberSwapKNC

Tradeable assets

Tradeable assets

Competitive landscape

Chain breakdown