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 (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with NFTX protocol vaults within any 7-day rolling window. NFTX is an NFT marketplace protocol that allows users to mint fungible tokens backed by NFTs, redeem NFTs from vaults, and swap between different NFT positions. The metric tracks distinct users across three interaction types: Minters (users depositing NFTs), Redeemers (users withdrawing NFTs), and Swappers (users exchanging NFTs). The calculation uses HyperLogLog probabilistic data structures to efficiently count unique users across overlapping time windows while providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on the following raw data sources:
- **NFTX v2 protocol events**: Parsed Ethereum event logs from NFTX v2 contracts including `Vault_Minted_event`, `Vault_Redeemed_event`, and `Vault_Swapped_event` logs that capture user interactions with NFT vaults
- **NFTX vault registry**: `VaultFactory_NewVault_event` logs that map vault addresses to underlying NFT contract addresses and vault IDs
- **NFTX v1 migration data**: `XStore_HoldingsRemoved_event` logs from NFTX v1 contracts used to identify and exclude legacy migration transactions
- **Ethereum transaction data**: Transaction records providing user addresses (`from_address`) and block timestamps for each vault interaction
- **Token metadata**: Token registry data providing symbol information for NFTX vault tokens

## 3. Step-by-step calculation

### Component A: Vault and migration data preparation
- **Purpose**: Establish vault-to-NFT mappings and identify migration transactions to exclude
- **Logic**: Extract vault definitions from `VaultFactory_NewVault_event` logs, mapping each `vaultId` to its corresponding `assetAddress` (NFT contract) and `vaultAddress`. Simultaneously collect transaction hashes from NFTX v1 `XStore_HoldingsRemoved_event` logs to identify migration transactions that should be excluded from current user metrics
- **Key fields**: `vault_id`, `nft_address`, `account_address` for vault mappings; `transaction_hash` for migration exclusions

### Component B: Trade fact extraction
- **Purpose**: Parse NFTX vault events to extract individual NFT trades with user attribution
- **Logic**: Process three event types from NFTX v2 Ethereum contracts - `Vault_Minted_event` (NFT deposits), `Vault_Redeemed_event` (NFT withdrawals), and `Vault_Swapped_event` (NFT swaps). For each event, extract the transaction hash, vault address, and NFT token IDs. Join with vault mappings to get NFT contract addresses, transaction data to get user addresses and timestamps, and token metadata for vault token symbols. Filter out transactions occurring before June 21, 2021 and exclude any migration transactions identified in Component A. Unnest NFT ID arrays to create one record per NFT traded
- **Key fields**: `transaction_hash`, `user_address`, `nft_address`, `event_type`, `block_timestamp`, `token_id`

### Component C: Daily active user identification
- **Purpose**: Aggregate unique users by day and interaction type
- **Logic**: Group trade records by truncated day timestamp and categorize users based on event type - 'Redeemer' for `Redeemed` events, 'Minter' for `Minted` events, and 'Swapper' for `Swapped` events. Extract distinct user addresses for each day-user type combination, creating the foundation for rolling window calculations
- **Key fields**: `timestamp` (daily), `user_type`, `chain`, `user_dau` (user address)

### Component D: HyperLogLog initialization
- **Purpose**: Convert daily user sets into HyperLogLog sketches for efficient set operations
- **Logic**: For each unique combination of day, chain, user type, and product ID, initialize a HyperLogLog sketch with precision parameter 15 using the `hll_count.init()` function. This probabilistic data structure enables efficient counting of distinct users across overlapping time windows without the memory overhead of storing actual user address lists
- **Key fields**: `timestamp`, `timestamp_grain`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component E: Date spine and rolling window construction
- **Purpose**: Create complete time series coverage and establish 7-day rolling windows
- **Logic**: Generate a date spine covering all days from the earliest DAU data through yesterday using `generate_timestamp_array()` with daily intervals. For each date in the spine, create a 7-day lookback window by joining with the 6 preceding days plus the current day. This ensures every day has a complete 7-day window for WAU calculation, even when some days have no user activity
- **Key fields**: `timestamp` (target date), `joinday` (dates within 7-day window)

### Component F: Rolling window HLL aggregation
- **Purpose**: Merge HyperLogLog sketches across 7-day windows
- **Logic**: Join the date spine rolling windows with daily HLL data, matching on the join dates within each 7-day window. This creates records where each target date is associated with all HLL sketches from its 7-day lookback period, enabling aggregation of unique users across the full weekly window
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll`

### Component G: Dimensional WAU calculation
- **Purpose**: Calculate weekly active users across multiple dimensional breakdowns
- **Logic**: Group the rolling window data by target timestamp and dimension type, then merge HLL sketches using `hll_count.merge_partial()` and extract final counts with `hll_count.extract()`. Create four separate dimensional views: project-level (all dimensions null), chain-level (grouped by `chain_id`), user-type-level (grouped by `user_type`), and product-level (grouped by `product_id`). Each breakdown aggregates HLL sketches across the specified dimension while preserving temporal granularity
- **Key fields**: `timestamp`, `dimensions`, `chain_id`, `product_id`, `user_type`, `user_wau` (distinct user count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set containing project-level, chain-level, user-type-level, and product-level WAU metrics
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro with 'nftx' data ID and 'fill_zeros' strategy to standardize column names, add metadata fields, and ensure complete time series coverage
- **Time boundaries**: Filter results to include only data from recent time periods based on incremental processing logic, maintaining a rolling window of historical data while processing new daily updates
- **Final calculation**: The final `user_wau` value represents the count of distinct users who interacted with NFTX vaults in any capacity during the 7-day period ending on each timestamp, calculated using probabilistic HyperLogLog aggregation for efficient processing of large user sets

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

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

NFTXNFTX

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown