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

## 1. Overview

The TraderJoe fees metric measures the total fees paid by traders on the TraderJoe decentralized exchange across all supported versions (v1, v2, v2.1, v2.2) and blockchain networks. This metric answers the business question of how much traders are paying in fees to use TraderJoe's automated market maker (AMM) services. The calculation approach varies by version: v1 fees are derived by applying a fixed 0.3% fee rate to trading volumes, while v2+ versions use actual fee amounts extracted directly from swap events.

## 2. Data sources

The calculation relies on several categories of blockchain and external data:

- **Blockchain events**: Parsed TraderJoe contract events including `PairCreated` events from various factory contracts (PairFactory, LBFactory, LBFactoryV2, LBFactoryV22) across Ethereum, Avalanche, BSC, and Arbitrum to identify trading pairs
- **Swap events**: Parsed TraderJoe swap events (`Pair_Swap_event`, `LBPair_Swap_event`, `LBPairV2_Swap_event`, `LBPairV22_Swap_event`) that capture trade details, token amounts, and fee data across all protocol versions
- **Fee parameter events**: Parsed `FeeParametersSet_event` logs from v2 exchanges that track protocol fee percentage changes over time
- **Transaction data**: Blockchain transaction records from Ethereum, Avalanche, BSC, and Arbitrum providing user addresses and transaction context
- **Token metadata**: Token contract information including decimal places and symbols for proper amount normalization
- **External data**: End-of-day token price feeds for USD conversion of fee amounts

## 3. Step-by-step calculation

### Component A: Trading pair identification

- **Purpose**: Identifies all valid TraderJoe trading pairs across different protocol versions and excludes low-liquidity pairs
- **Logic**: Extracts trading pair creation events from TraderJoe factory contracts across all supported chains and versions. For v1, uses `PairCreated` events with `token0`, `token1`, and `pair` address fields. For v2 versions, uses various `LBPairCreated` events with `tokenX`, `tokenY`, and `LBPair` address fields. Joins with token metadata to obtain decimal places and symbols for each token in the pair. Applies a denylist to exclude specific low-liquidity trading pairs that lack reliable price feed support
- **Key fields**: `account_address` (trading pair contract), `token0_address` and `token1_address` (constituent tokens), `token0_decimals` and `token1_decimals` (for amount normalization), `account_name` (token symbol pair), `version` (v1, v2, etc.), `chain` (blockchain network)

### Component B: Trade data extraction

- **Purpose**: Extracts individual trade transactions from swap events across all TraderJoe versions
- **Logic**: Processes different swap event types based on protocol version. For v1 (`Pair_Swap_event`), calculates net token amounts by subtracting out amounts from in amounts for each token. For v2 (`LBPair_Swap_event`), uses trade direction boolean to determine which token is being sold/bought. For v2.1 and v2.2 (`LBPairV2_Swap_event`, `LBPairV22_Swap_event`), employs JavaScript functions to decode packed amount data that combines both token amounts in a single field. Joins with transaction records to obtain user addresses and applies incremental processing with configurable lookback periods
- **Key fields**: `block_timestamp`, `transaction_hash`, `account_address` (pair contract), `token0_amount` and `token1_amount` (normalized amounts), `token0_fees` and `token1_fees` (for v2+ versions), `user_address`, `version`

### Component C: Fee tier tracking (v2 only)

- **Purpose**: Tracks protocol fee percentages for v2 exchanges which can change over time
- **Logic**: Monitors `FeeParametersSet_event` logs that announce changes to protocol fee rates for v2 trading pairs. Aggregates these events by day and trading pair to capture fee rate changes. Uses forward-filling logic to propagate the most recent fee rate across time periods until a new rate is set, ensuring every trading day has an applicable fee rate for revenue calculations
- **Key fields**: `timestamp`, `account_address`, `protocol_fee_tier` (percentage of fees retained by protocol), `chain`

### Component D: Volume and fee aggregation

- **Purpose**: Aggregates individual trades into daily trading volumes and fee amounts with USD conversion
- **Logic**: Groups trades by day, trading pair, and chain. For each group, sums the absolute values of token amounts after correcting for decimal places by dividing by 10^decimals. Performs USD conversion by joining with end-of-day price feeds for both tokens in each pair. For trading volume calculation, uses the minimum USD value between the two tokens to prevent price manipulation attacks. For fee calculations in v2+ versions, sums actual fee amounts extracted from swap events and converts to USD. For v1 exchanges, fee amounts are set to zero at this stage since they will be calculated separately using the percentage method
- **Key fields**: `timestamp`, `trading_volume` (USD), `fees` (USD for v2+ only), `version`, `chain`

### Final aggregation

- **Combining components**: Joins the aggregated trading data with trading pair information to ensure all necessary metadata is available for fee calculations
- **Currency conversion**: Uses end-of-day token price feeds to convert all amounts to USD values, ensuring consistent valuation across different tokens and chains
- **Time aggregation**: Aggregates data at the daily level using `timestamp_trunc` to day boundaries based on block timestamps
- **Final calculation**: Applies version-specific fee calculation logic. For v1 exchanges, multiplies the USD trading volume by the hardcoded 0.3% fee tier using the `safe_multiply` function. For v2, v2.1, and v2.2 exchanges, uses the actual fee amounts already calculated and converted to USD in the previous steps. Applies the `finalize_metric_fees` macro with a zero-filling strategy to ensure consistent data structure and handle any missing values across the time series and chain combinations

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

Total value users pay to use a protocol (gross fees, user-paid fees).

LFJJOE

Fees

Fees

Competitive landscape

Chain breakdown