website

twitter

github

Stablecoin issuers

Fathom

# Fathom Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Fathom measures the number of unique users who interacted with either Fathom DEX or Fathom Lending protocols within any 30-day rolling period. This metric tracks user engagement across Fathom's decentralized exchange and lending platform on the XDC blockchain. The calculation uses a sliding 30-day window approach with HyperLogLog aggregation for memory-efficient distinct user counting, providing daily MAU values that capture unique users over the preceding 30 days.

## 2. Data sources

The MAU calculation draws from several XDC blockchain event sources:
- **DEX trading events**: Parsed `Pair_Swap` events from Fathom DEX v2 contracts on XDC blockchain
- **Transaction data**: XDC transaction records used to identify the actual initiators of DEX trades
- **Lending events**: Five types of parsed lending pool events from Fathom Lending v3 contracts:
  - `LendingPool_Supply` events for token deposits
  - `LendingPool_Withdraw` events for token withdrawals  
  - `LendingPool_Borrow` events for borrowing actions
  - `LendingPool_FlashLoan` events for flash loan activities
  - `LendingPool_Repay` events for loan repayments

## 3. Step-by-step calculation

### Component A: DEX user identification
- **Purpose**: Identify daily active users from Fathom DEX trading activity
- **Logic**: Extract all `Pair_Swap` events from Fathom DEX v2 contracts on XDC blockchain. Join swap events with XDC transaction data to identify the actual transaction initiator (`from_address`) rather than just the contract caller. Calculate token amount changes for both tokens in each swap (`amount0In` minus `amount0Out`, `amount1In` minus `amount1Out`). Classify all DEX users uniformly as 'Trader' type. Aggregate users daily by truncating `block_timestamp` to day level, grouping by chain, user type, and product identifier 'Fathom DEX'
- **Key fields**: `block_timestamp` for daily aggregation, `from_address` as the actual user address, `user_address` as the final user identifier, `product_id` set to 'Fathom DEX'

### Component B: Lending user identification  
- **Purpose**: Identify daily active users from Fathom Lending protocol interactions
- **Logic**: Process five distinct lending event types from Fathom Lending v3 contracts. For `Supply` events, extract `user` field and classify as 'Depositor'. For `Withdraw` events, extract `user` field and classify as 'Withdrawer'. For `Borrow` events, extract `user` field and classify as 'Borrower'. For `FlashLoan` events, extract `initiator` field and classify as 'Borrower'. For `Repay` events, extract `repayer` field and classify as 'Repayer'. Union all lending events together and aggregate daily by truncating `block_timestamp` to day level, grouping by chain, user type, and product identifier 'Fathom Lending'
- **Key fields**: `block_timestamp` for daily aggregation, various user fields (`user`, `initiator`, `repayer`) based on event type, `user_type` classification by lending action, `product_id` set to 'Fathom Lending'

### Component C: Daily user aggregation
- **Purpose**: Combine DEX and lending users into unified daily active user counts
- **Logic**: Union the DEX trader data with lending user data. Group the combined dataset by `timestamp` (day level), `chain`, `user_type`, and `product_id`. Initialize HyperLogLog sketches for each group using `hll_count.init` with precision parameter 15 to enable memory-efficient distinct user counting across the subsequent 30-day rolling windows
- **Key fields**: `timestamp` as day-level date, `chain_id` for blockchain identifier, `user_type` for user classification, `product_id` for protocol identifier, `hll` as the HyperLogLog sketch

### Component D: Rolling 30-day window creation
- **Purpose**: Create sliding 30-day windows for each date to calculate rolling MAU
- **Logic**: Generate a complete datespine covering all dates from the earliest data through yesterday to ensure no missing timestamps. For each date in the datespine, create a 30-day window by generating all dates from 29 days prior through the current date using `generate_timestamp_array`. Join this window structure with the daily HLL data to collect all user sketches that fall within each 30-day period. This creates multiple rows per final date, one for each contributing day in the 30-day window
- **Key fields**: `timestamp` as the final MAU date, `joinday` as each contributing day within the window, `hll` sketches from contributing days

### Component E: HyperLogLog aggregation
- **Purpose**: Calculate distinct users within each 30-day window using HLL aggregation
- **Logic**: For each 30-day window (grouped by final `timestamp`, `chain_id`, `user_type`, `product_id`), merge all contributing HyperLogLog sketches using `hll_count.merge_partial`. Extract the final distinct user count using `hll_count.extract`. This provides memory-efficient distinct user counting that handles overlapping users across the 30-day period without requiring full user address enumeration
- **Key fields**: `timestamp` as MAU date, merged `hll` sketches, `user_mau` as final distinct user count

### Component F: Dimensional breakdowns
- **Purpose**: Create MAU calculations across different dimensional combinations
- **Logic**: Generate four separate dimensional views of the MAU data. Create project-level MAU by nullifying chain, product, and user type dimensions. Create chain-level MAU by preserving chain dimension while nullifying others. Create user type-level MAU by preserving user type while nullifying others. Create product-level MAU by preserving product dimension while nullifying others. Each breakdown aggregates the HLL sketches appropriately and extracts distinct user counts
- **Key fields**: `dimensions` indicating the breakdown type, conditional nulling of dimension fields, `user_mau` for each dimensional slice

### Final aggregation
- **Combining components**: Union all dimensional breakdown tables (project_dbt_tag, chain, user_type, product_id) to create a comprehensive MAU dataset with multiple dimensional views
- **Schema standardization**: Apply the `finalize_metric_user_mau` macro to standardize the output schema, add metadata fields, and implement zero-filling strategy for missing dates
- **Time boundaries**: Apply incremental processing filters to focus on recent months while maintaining sufficient lookback (29 days plus configurable incremental lookback) to ensure complete 30-day windows
- **Final calculation**: The final MAU value represents the distinct count of users who interacted with any Fathom protocol (DEX or lending) within the 30-day period ending on each date, calculated efficiently using HyperLogLog aggregation and broken down across multiple dimensional combinations

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

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

Fathom

Active users (monthly)

Active users (monthly)

Competitive landscape