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

LFJ (previously Trader Joe) is a non-custodial exchange protocol built on Avalanche (originally a fork of SushiSwap). LFJ was founded by an anonymous team and launched in 2021.

JOE tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). LFJ's investors include Three Arrows Capital, DeFiance Capital, GBV Capital, Mechanism Capital, etc.

website

github

twitter

discord

etherscan

Exchanges (DEX)

# LFJ Average trading volume (per user) Methodology

## 1. Overview

Trading volume average per user measures the average USD trading volume per daily active user on the TraderJoe decentralized exchange protocol. This metric indicates user engagement intensity by dividing total daily trading volume by the number of unique users who executed trades on that day. The calculation combines trading volume data from all TraderJoe protocol versions (V1, V2, V2.1, V2.2) across supported chains and divides by the count of unique daily active traders.

## 2. Data sources

- **TraderJoe swap events**: Parsed `Swap` events from TraderJoe V1 (`Pair_Swap_event`), V2 (`LBPair_Swap_event`), V2.1 (`LBPairV2_Swap_event`), and V2.2 (`LBPairV22_Swap_event`) contracts across Ethereum, Arbitrum, Avalanche, and BSC
- **Trading pair creation events**: `PairFactory_PairCreated_event` and various `LBFactory_LBPairCreated_event` logs to identify valid trading pairs and map them to underlying token pairs
- **Transaction records**: Blockchain transaction data from Ethereum, Arbitrum, Avalanche, and BSC to identify user addresses (`from_address` field)
- **Token price feeds**: End-of-day USD price data for tokens traded on TraderJoe
- **Token metadata**: Token decimal places and symbols for normalization and pair naming
- **Fee parameter events**: `LBFactory_FeeParametersSet_event` logs for TraderJoe V2 protocol fee calculations

## 3. Step-by-step calculation

### Component A: TraderJoe V1 trade processing
- **Purpose**: Extract and process swap events from TraderJoe V1 AMM pairs on Avalanche and BSC
- **Logic**: Parse `Pair_Swap_event` logs and calculate token amounts by taking the difference between `amountIn` and `amountOut` for each token in the pair. Join with transaction data to identify the user address from the transaction `from_address` field. Filter out denylisted trading pairs that have limited price feed support for low liquidity tokens.
- **Key fields**: `amount0In`, `amount0Out`, `amount1In`, `amount1Out` represent token flows, `sender` identifies the contract caller, transaction `from_address` identifies the end user

### Component B: TraderJoe V2 trade processing  
- **Purpose**: Extract and process swap events from TraderJoe V2 liquidity book pairs
- **Logic**: Parse `LBPair_Swap_event` logs from Arbitrum, BSC, and Avalanche. Use the `swapForY` boolean field to determine trade direction and split `amountIn`, `amountOut`, and `fees` between token0 and token1 accordingly. When `swapForY` is true, the input amount goes to token0 and output comes from token1; when false, the opposite occurs.
- **Key fields**: `swapForY` determines trade direction, `amountIn` and `amountOut` represent swap amounts, `fees` captures trading fees, `sender` identifies contract caller

### Component C: TraderJoe V2.1 and V2.2 trade processing
- **Purpose**: Extract and process swap events from newer TraderJoe V2 versions with packed parameters
- **Logic**: Parse `LBPairV2_Swap_event` and `LBPairV22_Swap_event` logs. Use JavaScript functions to decode packed parameters in `amountsIn`, `amountsOut`, `protocolFees`, and `totalFees` fields. Each packed parameter contains both tokenX and tokenY amounts encoded as 128-bit integers. Calculate net token amounts by taking differences between decoded input and output amounts.
- **Key fields**: `amountsIn`, `amountsOut` are packed 256-bit integers containing both token amounts, `protocolFees` and `totalFees` contain fee information, `sender` identifies contract caller

### Component D: Trading pair metadata enrichment
- **Purpose**: Map trading pair addresses to underlying token information
- **Logic**: Join swap events with trading pair creation events from various factory contracts to identify `token0_address`, `token1_address`, `token0_decimals`, and `token1_decimals`. Use token metadata to create human-readable pair names by concatenating token symbols.
- **Key fields**: `account_address` identifies the trading pair contract, `token0_address` and `token1_address` identify underlying tokens, `decimals` fields enable amount normalization

### Component E: Amount normalization and USD conversion
- **Purpose**: Convert raw token amounts to normalized USD values
- **Logic**: Normalize token amounts by dividing by `10^decimals` for each token. Join with end-of-day price feeds to convert normalized amounts to USD values. For each trade, calculate USD value for both token0 and token1 amounts, then take the minimum value between them to filter out potential price manipulation or oracle errors.
- **Key fields**: `token0_amount` and `token1_amount` in normalized units, `price_usd` from price feeds, final `trading_volume` as minimum USD value

### Component F: Daily trading volume aggregation
- **Purpose**: Calculate total daily trading volume across all chains and protocol versions
- **Logic**: Aggregate normalized USD trading volumes by day using `timestamp_trunc` to daily boundaries. Combine volumes from all TraderJoe protocol versions using union operations. Group by timestamp and sum trading volume amounts while preserving chain and business segment dimensions.
- **Key fields**: `timestamp` truncated to day level, `trading_volume` as sum of USD trade amounts, `chain` and business segment identifiers

### Component G: Daily active user calculation
- **Purpose**: Count unique users who executed trades each day
- **Logic**: Extract unique `user_address` values from all trade fact tables on a daily basis. Use `UNION DISTINCT` across all protocol versions to ensure each user is counted only once per day even if they trade on multiple versions. Apply HyperLogLog aggregation to efficiently count distinct users across different dimensional breakdowns including project-level aggregation.
- **Key fields**: `user_address` from transaction `from_address`, `timestamp` for daily grouping, `user_dau` as distinct count using HLL functions

### Final aggregation
- **Combining components**: Join daily trading volume data with daily active user data on the timestamp field, using the project-level user DAU aggregation (`dimensions = 'project_dbt_tag'`)
- **Currency conversion**: All amounts are already converted to USD using end-of-day price feeds during the volume calculation phase
- **Time aggregation**: Both metrics use daily boundaries created by truncating timestamps to day level using `timestamp_trunc`
- **Final calculation**: Divide total daily trading volume by daily active user count using `SAFE_DIVIDE` to handle cases where DAU might be zero, resulting in the trading volume average per user metric in USD

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

Average trading volume (per user)

Trading volume divided by daily active users.

LFJJOE

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape