Liquidity providers deposit funds into SushiSwap and NFTs into vaults and receive redemption and minting fees from users (supply-side fees).

NFTX is a non-custodial NFT marketplace protocol built on Ethereum. NFTX was founded by Alex Gausman and launched in 2021.

NFTX tokenholders own and govern the protocol. They currently take a cut of the redemption and minting fees (in the absence of liquidity providers) paid by users (revenue). NFTX's investors include Robot Ventures, etc.

governance

github

twitter

discord

etherscan

website

NFT marketplaces

NFTX

# NFTX Active users (monthly) Methodology

## 1. Overview

The NFTX Monthly Active Users (MAU) metric measures the number of unique users who interact with NFTX vaults over rolling 30-day periods. This metric tracks user engagement across different types of NFT trading activities on the NFTX platform, providing insights into protocol adoption and usage patterns. The calculation uses HyperLogLog (HLL) data structures for efficient unique user counting across multiple time windows and dimensional breakdowns.

## 2. Data sources

The MAU calculation relies on the following blockchain and metadata sources:

- **NFTX v2 smart contract events**: Parsed Ethereum events including `Vault_Minted_event` (users depositing NFTs to mint vault tokens), `Vault_Redeemed_event` (users redeeming NFTs from vaults), and `Vault_Swapped_event` (users swapping NFTs within vaults)
- **Ethereum transaction records**: Transaction data providing user addresses and timestamps for all NFTX interactions
- **NFTX vault configuration data**: `VaultFactory_NewVault_event` data linking vault addresses to their underlying NFT collections
- **NFTX v1 migration data**: `XStore_HoldingsRemoved_event` data used to exclude legacy migration transactions from the calculation
- **Token metadata**: Token symbols, chain information, and other metadata for vault tokens

## 3. Step-by-step calculation

### Component A: Trade transaction processing
- **Purpose**: Extract and enrich all NFTX trading activities with user and transaction context
- **Logic**: The system processes NFTX v2 vault events from Ethereum, extracting NFT trading activities including mints, redeems, and swaps. Each event is joined with Ethereum transaction data to obtain the user address (`from_address`) who initiated the transaction. Vault configuration data links each trade to its underlying NFT collection. The system filters out transactions before June 21, 2021, and excludes any transactions that are part of v1 to v2 vault migrations. Each trade record includes the `transaction_hash`, `user_address`, `nft_address`, event type, and timing information.
- **Key fields**: `user_address` (transaction initiator), `event_type` (Minted/Redeemed/Swapped), `block_timestamp` (activity timing), `nft_address` (traded NFT collection)

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily unique users by activity type using efficient HLL data structures
- **Logic**: The system processes trade data to identify unique users per day, classifying them by activity type. Users who perform `Redeemed` events become 'Redeemer' users, those performing `Minted` events become 'Minter' users, and those performing `Swapped` events become 'Swapper' users. Daily unique users are aggregated by timestamp (day-level), chain, user type, and product using HLL sketches for efficient storage and later aggregation. The HLL initialization uses a precision of 15 bits for balancing accuracy and storage efficiency.
- **Key fields**: `timestamp` (daily boundary), `user_type` (Redeemer/Minter/Swapper), `chain` (blockchain identifier), `user_dau` (unique user address), `hll` (HyperLogLog sketch)

### Component C: Time window generation
- **Purpose**: Create a complete datespine and generate 30-day rolling windows for MAU calculation
- **Logic**: The system creates a continuous daily datespine from the earliest NFTX activity through yesterday to ensure no gaps in the time series. For each day in the datespine, it generates a 30-day lookback window by creating an array of the current day plus the 29 preceding days. This windowing approach ensures that each day's MAU reflects unique users active within the 30-day period ending on that day. The datespine approach handles scenarios where certain days may have no trading activity.
- **Key fields**: `timestamp` (target date for MAU), `joinday` (each day within the 30-day window)

### Component D: Monthly active user windowing
- **Purpose**: Combine time windows with daily HLL data to prepare for unique user aggregation
- **Logic**: The system joins the 30-day time windows with the daily HLL data, creating a dataset where each target date has all relevant daily HLL sketches from its 30-day window. This join matches each `joinday` in the window with the corresponding daily HLL data, effectively gathering all user activity data that should contribute to each day's MAU calculation. The result is a denormalized dataset ready for HLL aggregation across multiple dimensions.
- **Key fields**: `timestamp` (MAU calculation date), `hll` (daily user sketches within window), dimensional attributes (`chain_id`, `user_type`, `product_id`)

### Component E: Dimensional aggregation
- **Purpose**: Calculate MAU across different dimensional breakdowns using HLL merge operations
- **Logic**: The system creates four distinct dimensional views of MAU data. The project-wide breakdown merges all HLL sketches regardless of chain, user type, or product to get total platform MAU. The chain-level breakdown groups by `chain_id` to show MAU per blockchain. The user-type breakdown groups by `user_type` to show MAU for Redeemers, Minters, and Swappers separately. The product-level breakdown groups by `product_id` for product-specific MAU. Each breakdown uses HLL merge operations (`hll_count.merge_partial`) to combine daily sketches within the 30-day window, then extracts the unique count (`hll_count.extract`) to get the final MAU value.
- **Key fields**: `dimensions` (breakdown type), `user_mau` (unique user count), dimensional identifiers (nulled for non-applicable dimensions)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a single dataset containing MAU values across all dimensional views
- **Time aggregation**: Each MAU value represents unique users within a rolling 30-day window ending on the specified timestamp
- **Final calculation**: The `finalize_metric_user_mau` macro standardizes the schema, applies the NFTX data identifier, and fills missing days with zero values to ensure complete time series coverage

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

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

NFTXNFTX

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown