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 Revenue Methodology

## 1. Overview

Trader Joe revenue represents the protocol fees earned by the Trader Joe decentralized exchange across multiple versions and blockchain networks. The metric captures the exchange's share of trading fees, which varies significantly between protocol versions. Version 1 (v1) applies a fixed percentage to trading volume, while versions 2 and later extract actual protocol fees from swap events. This revenue metric answers the business question: "How much fee income does Trader Joe generate from its DEX operations?"

## 2. Data sources

The calculation relies on several raw blockchain data sources:
- **Parsed swap events**: `Pair_Swap_event` logs from Trader Joe v1 contracts on Avalanche and BSC, `LBPair_Swap_event` logs from v2 contracts, and `LBPairV2_Swap_event`/`LBPairV22_Swap_event` logs from v2.1/v2.2 contracts across Ethereum, Arbitrum, BSC, and Avalanche
- **Factory contract events**: `PairFactory_PairCreated_event` and various `LBFactory_LBPairCreated_event` logs that register valid trading pairs across all protocol versions and chains  
- **Fee parameter events**: `LBFactory_FeeParametersSet_event` logs that track dynamic protocol fee rates for v2 pairs
- **Transaction records**: Ethereum, Avalanche, Arbitrum, and BSC transaction data providing user addresses and timestamps
- **End-of-day price feeds**: Token price data for USD conversion across all supported chains
- **Token metadata**: Token contract information including decimals and symbols for proper amount normalization

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Establish the universe of valid Trader Joe trading pairs across all versions and chains
- **Logic**: Extract pair creation events from factory contracts across different protocol versions. For v1, process `PairFactory_PairCreated_event` logs to capture `token0`, `token1`, and `pair` addresses. For v2 variants, process `LBFactory_LBPairCreated_event` and `LBFactoryV2_LBPairCreated_event` logs to capture `tokenX`, `tokenY`, and `LBPair` addresses. Join with token metadata to obtain decimal precision and create human-readable pair names. Filter out hardcoded denylisted pairs that have insufficient price feed coverage for low-liquidity tokens.
- **Key fields**: `account_address` (trading pair contract), `token0_address`/`token1_address` (constituent tokens), `token0_decimals`/`token1_decimals` (decimal precision), `account_name` (pair symbol), `version` (protocol version), `chain` (blockchain network)

### Component B: V1 trade processing  
- **Purpose**: Extract trade volume data from Trader Joe v1 swap events on Avalanche and BSC
- **Logic**: Parse `Pair_Swap_event` logs from v1 pair contracts, extracting `amount0In`, `amount0Out`, `amount1In`, and `amount1Out` fields. Calculate net token amounts by subtracting out amounts from in amounts for each token. Join with transaction data to obtain user addresses and filter out denylisted trading pairs. V1 events do not contain explicit fee or revenue fields, so these are set to zero at this stage.
- **Key fields**: `token0_amount` (net token0 change), `token1_amount` (net token1 change), `account_address` (pair contract), `user_address` (transaction originator), `block_timestamp` (event timing)

### Component C: V2 trade processing
- **Purpose**: Extract trade volume and fee data from Trader Joe v2 swap events
- **Logic**: Parse `LBPair_Swap_event` logs from v2 pair contracts on Arbitrum, BSC, and Avalanche. Use the `swapForY` boolean field to determine trade direction and split `amountIn`, `amountOut`, and `fees` accordingly between token0 and token1. When `swapForY` is true, token0 is input and token1 is output; when false, the reverse applies. Join with dynamic protocol fee tiers from fee parameter setting events to calculate protocol revenue as a percentage of total fees.
- **Key fields**: `trade_direction` (swap direction boolean), `amount_in`/`amount_out` (trade amounts), `fees` (total fees), `token0_fees`/`token1_fees` (fees split by direction)

### Component D: V2.1 and V2.2 trade processing
- **Purpose**: Extract trade and fee data from newer Trader Joe v2 variants using packed data structures
- **Logic**: Parse `LBPairV2_Swap_event` and `LBPairV22_Swap_event` logs which store amounts in packed format. Use JavaScript decoding functions to unpack `amountsIn`, `amountsOut`, `protocolFees`, and `totalFees` from hexadecimal strings into separate token0 and token1 components. The decoding extracts lower 128 bits as token0 amounts and upper 128 bits as token1 amounts. Calculate net token amounts and extract protocol fees directly from the unpacked data.
- **Key fields**: `amount_in`/`amount_out` (decoded trade amounts), `revenues` (decoded protocol fees), `fees` (decoded total fees), split into token0 and token1 components

### Component E: Protocol fee tier tracking
- **Purpose**: Maintain dynamic protocol fee rates for v2 trading pairs over time
- **Logic**: Extract `FeeParametersSet_event` logs from v2 factory contracts to capture `protocolShare` values for each trading pair. Aggregate daily average protocol fee tiers and use fill-forward logic to propagate fee tier values across time periods when no updates occur. This ensures every trading day has a valid protocol fee tier for revenue calculation.
- **Key fields**: `protocol_fee_tier` (protocol's share of total fees), `account_address` (trading pair), `timestamp` (effective date)

### Component F: Volume and fee aggregation
- **Purpose**: Combine all trade data into daily aggregated volumes, fees, and revenues
- **Logic**: Union all trade data from different protocol versions, joining v2 trades with their corresponding protocol fee tiers to calculate revenue. Group trades by day, trading pair, and chain, summing absolute values of token amounts, fees, and revenues. Apply decimal correction by dividing amounts by 10 raised to the token's decimal precision. This normalization ensures consistent unit representation across different token standards.
- **Key fields**: `trading_volume` (daily trade volume), `fees` (daily total fees), `revenue` (daily protocol revenue), aggregated by `timestamp`, `account_address`, and `chain`

### Final aggregation
- **Combining components**: All processed trade data is combined through union operations, with v1 trades contributing zero fees/revenue and v2+ trades contributing calculated protocol fees
- **Currency conversion**: Convert token amounts to USD using end-of-day price feeds joined on timestamp, chain, and token address. Apply anti-manipulation logic by taking the minimum USD value between token0 and token1 amounts for trading volume calculation
- **Time aggregation**: Truncate timestamps to daily boundaries and group all metrics by day, chain, and trading pair
- **Final calculation**: For v1 trades on Avalanche, multiply trading volume by 0.05% (0.0005) to estimate protocol revenue. For v1 trades on BSC, set revenue to zero as the protocol takes no fees. For v2+ trades, use the actual protocol revenue calculated from swap events and fee tiers. The result undergoes final processing through the `finalize_metric_revenue` macro with a fill-zeros strategy to ensure complete time series coverage.

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

LFJJOE

Revenue

Revenue

Competitive landscape

Chain breakdown