website

twitter

discord

Exchanges (DEX)

Etherex

# Etherex Total value locked Methodology

## 1. Overview

Total Value Locked (TVL) for EtherEX represents the total USD value of assets held within EtherEX liquidity pools across both v2 and v3 versions on the Linea blockchain. The metric is calculated by tracking net deposits (inflows minus outflows) across all trading pairs and treating the cumulative net deposits as TVL. This approach captures the actual value locked by users through liquidity provision, trading activities, and other protocol interactions.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Linea blockchain event logs**: Parsed events from EtherEX v2 and v3 smart contracts including factory, pair, and pool contracts
- **Factory creation events**: `PairCreated` events from v2 factory contracts and `PoolCreated` events from v3 factory contracts that establish trading pairs
- **Liquidity events**: `Pool_Mint_event` for v3 deposits and `Pool_Collect_event` for v3 withdrawals  
- **Trading events**: `Pair_Swap_event` from v2 pairs and `Pool_Swap_event` from v3 pools capturing trade flows
- **Reserve synchronization events**: `Pair_Sync_event` from v2 pairs showing reserve balance updates
- **Flash loan events**: `Pool_Flash_event` from v3 pools for flash loan fee tracking
- **Fee configuration events**: `SetPairFee`, `SetFee`, and `FeeAdjustment` events managing pool fee tiers
- **Transaction records**: Linea transaction data linking events to user addresses
- **End-of-day token price feeds**: USD price data for token valuation
- **Token metadata**: Token symbol and decimal precision information

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Establish all EtherEX trading pairs and their token configurations
- **Logic**: Factory creation events from both v2 and v3 versions are parsed to identify trading pairs. Each pair consists of two tokens with their respective contract addresses. Token metadata is joined to obtain decimal precision and symbols for proper normalization and naming. Fee tier configurations are tracked through fee adjustment events, with v2 pairs defaulting to 0.3% (3000 basis points) if no specific fee is set before pair creation.
- **Key fields**: `account_address` (pair/pool contract), `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name` (token symbol pair)

### Component B: V2 asset flow calculation  
- **Purpose**: Track asset flows for v2 pairs using reserve balance changes
- **Logic**: Daily reserve balances are extracted from `Pair_Sync_event` logs, taking the last balance within each day for both tokens in the pair. Asset flows are calculated as the difference between consecutive daily balances using lag functions. For the first day of a pair's existence, the entire reserve balance is treated as the initial asset flow. Reserve amounts are normalized by dividing by 10 raised to the power of token decimals.
- **Key fields**: `reserve0_amount`, `reserve1_amount`, `token0_amount` (calculated flow), `token1_amount` (calculated flow)

### Component C: V3 asset flow aggregation
- **Purpose**: Aggregate all v3 asset movements from direct event tracking
- **Logic**: Multiple event types are combined to capture comprehensive asset flows. Deposit events (`Pool_Mint_event`) contribute positive flows with `amount0` and `amount1` values. Withdrawal events (`Pool_Collect_event`) contribute negative flows by multiplying amounts by -1. Trading events (`Pool_Swap_event`) contribute the direct `amount0` and `amount1` values representing net token changes. Flash loan events (`Pool_Flash_event`) contribute fee-based flows by multiplying loan amounts by the pool's current fee tier percentage. All amounts are normalized using token decimal precision.
- **Key fields**: `token0_amount`, `token1_amount`, `fee_tier` (for flash loans), `block_timestamp`

### Component D: Fee tier management
- **Purpose**: Apply correct fee percentages to flash loan calculations
- **Logic**: Pool fee tiers are tracked through configuration events and maintained as time-series data. Each fee change creates a new fee tier interval identified by block number and log index ordering. Flash loan amounts are multiplied by the applicable fee tier at the time of the transaction. Fee tiers are stored as basis points (e.g., 3000 = 0.3%) and converted to decimal form by dividing by 1,000,000.
- **Key fields**: `fee_tier`, `order_id`, `next_order_id` (interval boundaries)

### Final aggregation
- **Combining components**: V2 and v3 asset flows are union combined into a single dataset, aggregated daily by trading pair. Each flow record contains normalized token amounts for both tokens in the pair.
- **Currency conversion**: Token amounts are converted to USD by joining with end-of-day price feeds on timestamp and token address. Missing prices default to zero value. The USD value for each pair is calculated as: `(token0_amount × token0_price_usd) + (token1_amount × token1_price_usd)`
- **Time aggregation**: All asset flows are aggregated to daily granularity using `timestamp_trunc(block_timestamp, day)`. Multiple events within the same day are summed together.
- **Final calculation**: Daily net deposits across all trading pairs are summed to create total net deposits. These cumulative net deposits represent the TVL, with missing days filled with zeros using the fill_zeros strategy. The result shows the total USD value of assets locked in EtherEX liquidity pools.

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

Total value locked (TVL)

Total value locked (TVL) — value deposited into the project's applications.

EtherexREX

Archived

Total value locked

Total value locked

Competitive landscape