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 Active users (monthly) Methodology

## 1. Overview

TraderJoe MAU (Monthly Active Users) measures the number of unique users who performed at least one trade on the TraderJoe decentralized exchange within a rolling 30-day window. This metric counts unique wallet addresses that executed swaps across all TraderJoe protocol versions (V1, V2, V2.1, V2.2) and supported blockchain networks. The calculation uses HyperLogLog probabilistic data structures to efficiently handle unique user counting across large datasets and time windows.

## 2. Data sources

- **Swap events**: Parsed swap event logs from TraderJoe contracts across multiple protocol versions:
  - V1 `Pair_Swap_event` logs from BSC and Avalanche
  - V2 `LBPair_Swap_event` logs from Arbitrum, BSC, and Avalanche  
  - V2.1 `LBPairV2_Swap_event` logs from Ethereum, Arbitrum, BSC, and Avalanche
  - V2.2 `LBPairV22_Swap_event` logs from Arbitrum and Avalanche
- **Transaction records**: Blockchain transaction data from BSC, Avalanche, Ethereum, and Arbitrum to identify actual user wallet addresses
- **Trading pair denylist**: Hardcoded list of trading pair contract addresses excluded due to limited price feed support for low liquidity tokens

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identify unique daily traders across all TraderJoe protocol versions and chains
- **Logic**: Extract swap events from all four TraderJoe protocol versions, truncate block timestamps to day granularity, and collect distinct user addresses per day. Join swap events with blockchain transaction records to extract the actual user wallet address (`from_address`) rather than contract interaction addresses. Filter out denylisted trading pairs that have limited price feed support. Classify all users as "Trader" user type since they are performing swap transactions.
- **Key fields**: `timestamp` (day-truncated), `chain`, `user_type` (always "Trader"), `user_address`, `product_id`, `market_sector_id`, `business_segment_id`

### Component B: HyperLogLog initialization  
- **Purpose**: Convert daily user counts to probabilistic data structures for efficient unique counting
- **Logic**: Transform daily active user data into HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. Group by timestamp, chain, user type, and product dimensions to create separate HLL sketches for each combination. This allows efficient merging and counting of unique users across different time windows and dimensional breakdowns.
- **Key fields**: `timestamp`, `chain`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component C: Datespine and window creation
- **Purpose**: Generate complete daily timeline and 30-day rolling windows for consistent MAU calculation
- **Logic**: Create a datespine covering all days from the earliest trade date to yesterday to handle missing days. For each day in the datespine, generate a 30-day lookback window (29 days prior plus current day) using BigQuery's `generate_timestamp_array` function. This creates a cross-join structure where each day maps to its corresponding 30-day window of dates.
- **Key fields**: `timestamp` (current day), `joinday` (each day in the 30-day window)

### Component D: Window aggregation
- **Purpose**: Aggregate unique users within each 30-day rolling window
- **Logic**: Join the 30-day windows with daily HLL sketches, matching each window day to its corresponding daily user data. For each 30-day window, merge all HLL sketches using `hll_count.merge_partial` and extract the final unique user count with `hll_count.extract`. This produces a rolling 30-day unique user count for each day.
- **Key fields**: `timestamp`, `chain`, `user_type`, `product_id`, merged HLL sketches

### Component E: Dimensional breakdowns
- **Purpose**: Calculate MAU across different dimensional views
- **Logic**: Create four separate dimensional breakdowns of the MAU data: overall project level (all dimensions collapsed), by chain (showing MAU per blockchain), by user type (showing MAU per user category), and by product (showing MAU per product). Each breakdown aggregates the merged HLL sketches across the non-relevant dimensions while preserving the target dimension for analysis.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_mau` (final count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with standardized schema where non-applicable dimension fields are set to null
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily values represent rolling 30-day unique user counts ending on that day
- **Final calculation**: The `user_mau` field contains the final count of unique users who traded within the 30-day window ending on each timestamp. The `finalize_metric_user_mau` macro applies standardized formatting and fills missing periods with zeros where no trading activity occurred.

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

Unique revenue-generating users over a rolling 30-day window.

LFJJOE

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown