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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of trading fees that are distributed to liquidity providers on Trader Joe, calculated as total fees minus protocol revenue. This metric answers the business question: "How much value do liquidity providers capture from trading activity?" The calculation involves aggregating fees across all Trader Joe protocol versions (v1, v2, v2.1, v2.2) on multiple chains and subtracting the protocol's revenue share.

## 2. Data sources

- **Trader Joe swap events**: Parsed `Swap` events from different protocol versions including v1 `Pair_Swap` events, v2 `LBPair_Swap` events, v2.1 `LBPairV2_Swap` events, and v2.2 `LBPairV22_Swap` events across Ethereum, Avalanche, BSC, and Arbitrum
- **Trading pair creation events**: Factory contract events including `PairCreated` and `LBPairCreated` events that establish trading pairs and their metadata
- **Protocol fee configuration events**: `FeeParametersSet` events from v2+ that define dynamic protocol fee tiers
- **Transaction data**: Blockchain transaction records from Ethereum, Avalanche, BSC, and Arbitrum for user identification
- **End-of-day price feeds**: Token price data for USD conversion
- **Token metadata**: Token decimals and symbols for proper amount normalization

## 3. Step-by-step calculation

### Component A: Trading data extraction by protocol version

- **Purpose**: Extract and standardize trading data across different Trader Joe protocol versions
- **Logic**: Each protocol version stores trading data differently in blockchain events. V1 stores token amount changes in `Swap` events with `amount0In`, `amount0Out`, `amount1In`, `amount1Out` fields. V2 stores trade direction, amounts, and fees in `Swap` events. V2.1 and v2.2 pack multiple values into encoded parameters that require JavaScript decoding to extract `amountsIn`, `amountsOut`, `protocolFees`, and `totalFees`. All versions join with transaction data to identify the actual user address.
- **Key fields**: `token0_amount`, `token1_amount` (calculated from input/output differences), `token0_fees`, `token1_fees` (direct for v2+, calculated for v1), `user_address`, `account_address` (trading pair contract)

### Component B: Trading pair metadata enrichment

- **Purpose**: Add trading pair information including token addresses, decimals, and symbols
- **Logic**: Trading pair data comes from factory contract creation events across all protocol versions. The system matches each trade's contract address with the corresponding trading pair metadata to determine the two tokens being traded, their decimal places for amount normalization, and symbols for naming. A denylist filters out trading pairs with limited price feed support.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component C: Protocol fee tier determination

- **Purpose**: Calculate protocol revenue share for v2+ protocols
- **Logic**: V2+ protocols have dynamic protocol fee tiers set through `FeeParametersSet` events. The system extracts the `protocolShare` parameter from these events and applies forward-filling to maintain the fee tier across time periods until a new tier is set. V1 protocols use fixed fee tiers defined in the calculation logic.
- **Key fields**: `protocol_fee_tier` (percentage of total fees retained by protocol)

### Component D: Fee and revenue calculation by version

- **Purpose**: Calculate total fees and protocol revenue using version-specific methodologies
- **Logic**: V1 protocols don't emit fee data in events, so fees are calculated as 0.3% of trading volume. V1 revenue varies by chain: 0.05% of trading volume on Avalanche, 0% on BSC. V2+ protocols extract fees directly from swap events and calculate revenue by multiplying fees by the protocol fee tier. V2.1 and v2.2 have revenue values directly embedded in the events.
- **Key fields**: `fees` (total fees paid), `revenue` (protocol's share of fees)

### Component E: Daily aggregation and USD conversion

- **Purpose**: Aggregate trading data to daily granularity and convert to USD values
- **Logic**: All trading data is aggregated daily by summing token amounts and fees after applying decimal corrections using token metadata. USD conversion uses end-of-day price feeds for both tokens in each trading pair. To prevent price manipulation, the system uses the minimum USD value between token0 and token1 amounts for trading volume calculation. Fees and revenue are converted by multiplying token amounts with respective token prices and summing across both tokens.
- **Key fields**: `trading_volume`, `fees`, `revenue` (all in USD)

### Final aggregation

- **Combining components**: The final model combines total fees and protocol revenue at the daily level by matching timestamps and chain identifiers
- **Currency conversion**: All amounts are already converted to USD in the intermediate processing using end-of-day price feeds
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation
- **Final calculation**: Supply-side fees equals total fees minus protocol revenue, representing the portion of fees that flows to liquidity providers rather than the protocol treasury

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

Portion of fees distributed to service providers or supply-side participants.

LFJJOE

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown