Creators create and sell NFTs on Zora. They receive a cut of the primary sales (supply-side fees).

Zora is a non-custodial NFT minting protocol built on Ethereum and launched in 2021.

Team and investors own and govern the protocol. They currently take a cut the primary sales paid by collectors (revenue).

github

twitter

discord

website

NFT marketplaces

Zora

# Zora Active users (monthly) Methodology

## 1. Overview

The Zora Monthly Active Users (MAU) metric measures the number of unique users who have interacted with the Zora NFT marketplace protocol within a rolling 30-day window. This metric answers the business question: "How many distinct users are actively engaging with Zora's platform each month?" The calculation uses HyperLogLog probabilistic data structures to efficiently compute approximate unique user counts across multiple dimensional breakdowns, including chain-level, user type-level, and product-level segmentation.

## 2. Data sources

The MAU calculation is built from the following raw blockchain data sources:
- **Zora smart contract events**: Parsed event logs from Zora's NFT marketplace contracts deployed across Ethereum, Optimism, and Base networks
- **Sale events**: `Sale` events from `721Drop` contracts capturing NFT purchase/mint transactions
- **Purchase events**: `Purchased` events from `1155` contracts capturing ERC-1155 NFT transactions  
- **Drop creation events**: `CreatedDrop` events from `Factory721` and `NFTCreator` contracts capturing new NFT drop deployments
- **Contract setup events**: `SetupNewContract` events from `Factory1155` and `Creator1155Factory` contracts capturing ERC-1155 contract deployments
- **Transaction metadata**: Block timestamps and transaction hashes from blockchain transaction records
- **Chain data**: Multi-chain event data from Ethereum mainnet, Optimism, and Base Layer 2 networks

## 3. Step-by-step calculation

### Component A: User fact table creation
- **Purpose**: Extract and classify all user interactions with Zora contracts across supported blockchains
- **Logic**: Parse smart contract event logs from Zora's marketplace contracts on Ethereum, Optimism, and Base networks. Extract user addresses from specific event parameters: `to` parameter from `Sale` events identifies minters, `sender` parameter from `Purchased` events identifies buyers, and `creator` parameter from creation events identifies drop creators. Each user interaction is classified into one of two user types: 'Minter' for users purchasing or minting NFTs, and 'Drop Creator' for users creating new NFT drops or contracts. All interactions are tagged with chain information, market sector as 'nfts', and business segment as 'marketplace'
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for deduplication, `chain` for network identification, `user_type` for categorization, `user_address` for unique user identification

### Component B: Daily active users (DAU) aggregation  
- **Purpose**: Aggregate user interactions into daily unique user counts with dimensional attributes
- **Logic**: Group all user interactions by truncated day timestamp, maintaining dimensional breakdowns by chain, user type, market sector, business segment, and product. Each unique combination of user address and day creates one DAU record. The aggregation preserves all dimensional attributes needed for downstream MAU calculations while ensuring each user is counted only once per day regardless of how many transactions they performed
- **Key fields**: `timestamp` truncated to day granularity, `user_address` as the unique user identifier, dimensional attributes (`chain`, `user_type`, `product_id`) for segmentation

### Component C: HyperLogLog sketch initialization
- **Purpose**: Convert daily user lists into efficient probabilistic data structures for approximate counting
- **Logic**: Transform each day's list of unique user addresses into HyperLogLog sketches using `hll_count.init()` with 15-bit precision. This creates compact representations of user sets that can be efficiently merged across time windows. Group sketches by timestamp, chain, user type, and product dimensions to maintain proper segmentation for downstream calculations
- **Key fields**: `hll` sketches containing compressed user address sets, dimensional grouping fields preserved from DAU layer

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each target date to capture monthly active user periods
- **Logic**: Generate a complete datespine covering all days from the earliest available data through yesterday. For each target date in the spine, create joins to the 30 preceding days (including the target date) using `generate_timestamp_array` with 29-day lookback intervals. This creates a cartesian product where each target date is associated with its complete 30-day window of source days, ensuring no gaps in the rolling window calculation
- **Key fields**: `timestamp` as the target MAU date, `joinday` representing each day within the 30-day lookback window

### Component E: Windowed HLL aggregation
- **Purpose**: Combine daily HLL sketches across 30-day windows to calculate approximate unique user counts
- **Logic**: Join the rolling window structure with daily HLL sketches, matching each window day to its corresponding DAU sketch. For each target date and dimensional combination, collect all HLL sketches from the 30-day window. Use `hll_count.merge_partial()` to combine sketches from multiple days, then `hll_count.extract()` to produce the final approximate unique user count for the monthly period
- **Key fields**: Merged `hll` sketches representing 30-day user sets, dimensional attributes maintained throughout the aggregation

### Component F: Dimensional breakdown creation
- **Purpose**: Generate MAU metrics across multiple business dimensions for analytical flexibility
- **Logic**: Create four separate dimensional views from the windowed HLL data: project-level aggregation (combining all chains and user types), chain-level breakdown (segmenting by blockchain network), user type-level breakdown (segmenting by minter vs creator behavior), and product-level breakdown (segmenting by specific product offerings). Each breakdown nullifies non-relevant dimensional fields while preserving the target dimension and combining HLL sketches appropriately
- **Key fields**: `dimensions` field indicating the breakdown type, relevant dimensional field (`chain_id`, `user_type`, `product_id`), null values for non-applicable dimensions

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, creating a comprehensive MAU dataset that supports multiple analytical perspectives while maintaining data consistency across dimensions
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundary logic uses timestamp truncation to day granularity, with 30-day rolling windows calculated for each day. Monthly partitioning is applied for efficient incremental processing
- **Final calculation**: The final MAU value represents the approximate count of unique user addresses that appeared in any qualifying Zora contract event within the 30-day rolling window ending on each target date, calculated using merged HyperLogLog sketches and segmented across multiple dimensional hierarchies

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

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

ZoraZORA

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown