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

## 1. Overview

Monthly active addresses measures the number of unique blockchain addresses that interacted with the Zora NFT marketplace protocol within a rolling 30-day window. This metric tracks user engagement across Zora's multi-chain ecosystem by counting distinct addresses that participated in NFT minting, purchasing, or collection creation activities. The calculation uses probabilistic counting methods to efficiently compute rolling monthly totals while avoiding double-counting addresses that are active across multiple days.

## 2. Data sources

- **Zora protocol events**: Parsed blockchain events from Zora's NFT marketplace smart contracts across Ethereum, Optimism, and Base networks
- **NFT minting events**: `Sale` events from 721Drop contracts and `Purchased` events from 1155 contracts capturing NFT purchases and mints
- **Collection creation events**: `CreatedDrop` events from Factory721 and NFTCreator contracts, and `SetupNewContract` events from Factory1155 and Creator1155Factory contracts
- **Transaction metadata**: Block timestamps and transaction hashes for temporal analysis
- **User identification data**: Address parameters from event logs including `to`, `creator`, and `sender` fields

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all meaningful user interactions with Zora protocol contracts across supported blockchains
- **Logic**: Extracts user addresses from specific Zora protocol events across Ethereum, Optimism, and Base chains. For each chain, the system monitors four key event types: NFT sale events that capture the buyer address from the `to` parameter, factory creation events that capture the creator address from the `creator` parameter, NFT purchase events that capture the buyer address from the `sender` parameter, and contract setup events that capture the creator address from the `creator` parameter. Each interaction is classified by user type as either 'Minter' for users purchasing or minting NFTs, or 'Drop Creator' for users creating new NFT collections
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` containing the blockchain address, `user_type` classifying the interaction type, `chain` identifying the blockchain network

### Component B: Daily active user calculation
- **Purpose**: Aggregates unique user addresses per day to establish the foundation for rolling monthly calculations
- **Logic**: Groups all user interactions by day using timestamp truncation to day granularity. For each day, calculates the distinct count of user addresses across all interaction types and chains. This creates a daily time series of unique active addresses that participated in any Zora protocol activity
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing the unique user address, `chain` for chain-specific analysis

### Component C: Monthly active user computation using HyperLogLog
- **Purpose**: Calculates 30-day rolling monthly active users using probabilistic counting to handle large-scale distinct address counting efficiently
- **Logic**: Creates a date spine covering all days from the earliest data to present, then generates 30-day rolling windows by creating join relationships between each day and the previous 29 days. For each day's user addresses, initializes HyperLogLog sketches with 15-bit precision for probabilistic distinct counting. Uses the rolling window to merge HyperLogLog sketches across the 30-day period, then extracts the estimated distinct count of user addresses. This approach avoids the computational complexity of exact distinct counting while maintaining high accuracy for large address sets. The calculation produces multiple dimensional breakdowns including project-level totals, chain-specific totals, user-type-specific totals, and product-specific totals
- **Key fields**: `user_mau` containing the estimated monthly active user count, `dimensions` indicating the aggregation level, `chain_id` for chain-specific breakdowns

### Final aggregation
- **Combining components**: The monthly active user calculation already provides the complete user engagement picture across all Zora protocol interactions
- **Currency conversion**: Not applicable as this metric counts addresses rather than monetary values  
- **Time aggregation**: Uses 30-day rolling windows calculated daily, meaning each day's value represents the count of unique addresses active in that day plus the previous 29 days
- **Final calculation**: Maps user monthly active users directly to active addresses monthly since each user is uniquely identified by their blockchain address. Filters results to include only project-level and chain-level dimensions for the final metric. Applies chain availability filtering to ensure data quality and completeness across supported blockchain networks

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

Unique addresses active over a rolling 30-day window.

ZoraZORA

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown