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

## 1. Overview

Weekly active addresses measures the number of distinct wallet addresses that interact with the Zora NFT platform within a 7-day rolling window. This metric captures both minting activity (users purchasing NFTs) and creation activity (users deploying new NFT drops) across Ethereum, Optimism, and Base blockchains. The calculation uses HyperLogLog probabilistic counting to efficiently aggregate distinct users across multiple chains and interaction types while avoiding double-counting addresses that perform multiple actions.

## 2. Data sources

The metric relies on parsed blockchain events from Zora V1 smart contracts deployed across multiple chains:

- **Zora V1 contract events on Ethereum**: `Sale` events from 721Drop contracts, `CreatedDrop` events from Factory721 contracts, `Purchased` events from 1155 contracts, and `SetupNewContract` events from Factory1155 contracts
- **Zora V1 contract events on Optimism**: `Sale` events from 721Drop contracts, `CreatedDrop` events from Factory721 contracts, `Purchased` events from 1155 contracts, and `SetupNewContract` events from Factory1155 contracts  
- **Zora V1 contract events on Base**: `Sale` events from 721Drop contracts, `CreatedDrop` events from NFTCreator contracts, `Purchased` events from 1155 contracts, and `SetupNewContract` events from Creator1155Factory contracts
- **Blockchain transaction metadata**: Block timestamps and transaction hashes for all events
- **Chain availability filters**: Configuration data determining which chains should be included in final metric outputs

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Extract and categorize user addresses from Zora platform interactions across all supported chains
- **Logic**: Parse contract events from Zora V1 contracts on Ethereum, Optimism, and Base. Extract user addresses from different event parameters: `to` field for Sale events (identifying Minters), `sender` field for Purchased events (identifying Minters), and `creator` field for factory/creation events (identifying Drop Creators). Standardize all events with consistent schema including `block_timestamp`, `transaction_hash`, `chain`, `user_type`, and `user_address`
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for distinct counting, `chain` for multi-chain aggregation, `user_type` distinguishing between Minters and Drop Creators

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users by removing duplicates within each day
- **Logic**: Group user events by day using timestamp truncation to daily boundaries. Count distinct user addresses per day, chain, and user type combination. This creates the foundation for weekly rolling window calculations
- **Key fields**: `timestamp` truncated to day granularity, `user_dau` containing distinct user addresses, `chain` and `user_type` for dimensional breakdowns

### Component C: Weekly active user calculation with HyperLogLog
- **Purpose**: Calculate 7-day rolling distinct user counts using probabilistic data structures for efficiency
- **Logic**: Create HyperLogLog sketches for each daily distinct user set to enable memory-efficient distinct counting. Generate a date spine covering the full time range, then create 7-day rolling windows by joining each date with the previous 6 days. For each 7-day window, merge the HyperLogLog sketches from all constituent days and extract the estimated distinct count. This provides weekly active user counts while handling the computational complexity of distinct counting across large datasets
- **Key fields**: `timestamp` for the end date of each 7-day window, `user_wau` containing the distinct user count estimate, `hll` sketches for intermediate calculations

### Component D: Multi-dimensional aggregation
- **Purpose**: Break down weekly active users across different analytical dimensions
- **Logic**: Calculate weekly active users at four different aggregation levels: project level (all chains and user types combined), chain level (separate counts for Ethereum, Optimism, and Base), user type level (separate counts for Minters vs Drop Creators), and product level (currently null for Zora). Each dimension uses the same HyperLogLog merging approach but groups data differently to avoid double-counting users who appear in multiple categories
- **Key fields**: `dimensions` indicating the aggregation level, `chain_id` for chain-specific breakdowns, `user_type` for role-specific breakdowns

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single dataset, with the final metric selecting only project-level and chain-level aggregations as specified by the dimensions filter
- **Currency conversion**: Not applicable for user counting metrics
- **Time aggregation**: Uses 7-day rolling windows with daily granularity, where each day represents the count of distinct users active in the trailing 7-day period
- **Final calculation**: Apply the `finalize_metric_active_addresses_weekly` macro to standardize schema, fill missing days with zero values, and apply chain availability filters to ensure only supported chains appear in output. The final `active_addresses_weekly` value represents the distinct count of wallet addresses that interacted with Zora contracts within the 7-day window ending on each date

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

Unique active addresses over a rolling 7-day window.

ZoraZORA

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown