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 fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees generated per daily active user on the Trader Joe decentralized exchange. This metric answers the business question: "How much fee revenue does each active user generate on average per day?" The calculation divides total daily fees by the number of daily active users, providing insight into user value and protocol monetization efficiency across Trader Joe's multiple protocol versions (v1, v2, v2.1, v2.2) operating on Ethereum, Arbitrum, BSC, and Avalanche.

## 2. Data sources

The AFPU calculation relies on several key raw data sources:

- **Swap events**: Parsed `Swap` events from Trader Joe contracts across protocol versions - `Pair_Swap_event` for v1, `LBPair_Swap_event` for v2, `LBPairV2_Swap_event` for v2.1, and `LBPairV22_Swap_event` for v2.2
- **Transaction records**: Blockchain transaction data from Ethereum, Arbitrum, BSC, and Avalanche containing user addresses and timestamps
- **Factory events**: `PairCreated` events from Trader Joe factory contracts that define valid trading pairs across different protocol versions
- **Price feeds**: End-of-day token price feeds for USD conversion of fee amounts
- **Token metadata**: Token information including decimal precision and symbols for amount normalization
- **Fee configuration**: Protocol fee parameter events from v2 contracts that determine revenue sharing ratios
- **Trading pair metadata**: Denylist of trading pairs excluded due to limited price feed support

## 3. Step-by-step calculation

### Component A: Daily active users calculation
- **Purpose**: Identifies and counts unique users who performed swaps on any given day across all Trader Joe protocol versions
- **Logic**: Extracts user addresses from swap transactions across four protocol versions. For each swap event, the `user_address` comes from the transaction's `from_address` field, while `contract_user_address` comes from the swap event's `sender` field. Users are deduplicated daily using union distinct operations across all protocol versions. The system aggregates users using HyperLogLog (HLL) data structures to efficiently handle large-scale counting across multiple dimensions including chain, user type, and product categories
- **Key fields**: `user_address` from transaction records, `sender` from swap events, `block_timestamp` for daily grouping, and `chain` for multi-chain aggregation

### Component B: Fee collection and calculation
- **Purpose**: Calculates total fees generated from trading activity using protocol-specific methodologies
- **Logic**: Fee calculation varies significantly by protocol version. For v1, fees are calculated by applying a hardcoded rate of 0.3% to the trading volume since fee amounts are not directly available in the events. For v2 original, fees are extracted directly from the `fees` field in swap events and attributed to tokens based on trade direction. For v2.1 and v2.2, fee amounts are encoded in packed hexadecimal format and must be decoded using JavaScript functions to separate X and Y token fee components. All raw token amounts are adjusted for decimal precision and converted to USD using end-of-day price feeds
- **Key fields**: `fees` from v2 events, `totalFees` and `protocolFees` from v2.1/v2.2 events, `trading_volume` for v1 calculations, token decimal adjustments, and USD price conversions

### Component C: Trading volume and pair processing
- **Purpose**: Processes raw swap data into standardized trading metrics while filtering invalid pairs
- **Logic**: Swap events are processed differently across versions. V1 calculates token amounts by subtracting `amountOut` from `amountIn` for each token. V2 uses direct `amountIn` and `amountOut` values with trade direction flags to determine token allocation. V2.1 and V2.2 decode packed amount structures containing both input and output amounts. All swaps are filtered against a denylist of trading pairs with insufficient price feed coverage. Trading pairs are identified from factory `PairCreated` events and enriched with token metadata including symbols and decimal precision
- **Key fields**: `amountIn`, `amountOut`, `swapForY` trade direction, `tokenX` and `tokenY` addresses, and pair contract addresses

### Component D: Multi-chain data aggregation
- **Purpose**: Combines swap data across Ethereum, Arbitrum, BSC, and Avalanche chains into unified metrics
- **Logic**: Each chain's data is processed separately then combined using union operations. Chain-specific transaction data is joined with swap events to obtain user addresses. Fee tier configurations are chain and protocol version specific, particularly for v2 protocols where protocol revenue shares vary by trading pair and change over time. The system applies forward-filling logic to propagate fee tier changes across time periods
- **Key fields**: `chain` identifiers, protocol `version` tags, and chain-specific contract addresses

### Final aggregation
- **Combining components**: Daily active users and total fees are calculated independently then combined using the ARPU calculation macro. Users are counted using HyperLogLog aggregation to handle deduplication across multiple dimensions, while fees are summed directly after USD conversion
- **Currency conversion**: All fee amounts are converted to USD using end-of-day token price feeds matched by timestamp, token address, and chain. Conversion occurs after decimal adjustment but before final aggregation
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation. Missing days are filled with zero values to create complete time series
- **Final calculation**: AFPU is calculated as the simple ratio of total daily fees divided by daily active users count. The result represents the average fee revenue generated per active user on each day across the entire Trader Joe protocol ecosystem

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

LFJJOE

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape