Creators & users sell NFTs on OpenSea. They receive royalties from secondary sales (supply-side fees).

OpenSea is a non-custodial NFT marketplace protocol built on Ethereum. OpenSea was founded by Alex Atallah & Devin Finzer and launched in 2017.

OpenSea team & investors own and govern the protocol. They currently take a cut of the total transaction fees paid by buyers (revenue). OpenSea's investors include a16z, Coatue, Founders Fund, etc.

github

twitter

discord

website

NFT marketplaces

OpenSea

# OpenSea Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for OpenSea measures the number of unique Ethereum addresses that participated in NFT trading activities on the OpenSea marketplace over a rolling 30-day period. This metric captures both NFT buyers and sellers as distinct user types, providing insight into the platform's user engagement and market activity. The calculation uses HyperLogLog probabilistic counting for efficient processing of large-scale user data across multiple chains and product dimensions.

## 2. Data sources

The methodology relies on several types of blockchain data sources:

- **Seaport protocol events**: Parsed `OrderFulfilled` events from Ethereum blockchain covering Seaport versions 1.1 through 1.6, containing detailed trade execution data with offer and consideration arrays
- **Wyvern protocol events**: Legacy `OrdersMatched` events and `atomicMatch_` function calls from the original OpenSea exchange contract on Ethereum
- **Transaction traces**: Ethereum transaction traces containing OpenSea website identifiers (specific input patterns) to identify platform-originated trades
- **Protocol identification data**: Hardcoded lists of OpenSea fee recipient addresses, valid zone identifiers, and protocol ownership markers
- **Order matching data**: `matchAdvancedOrders` and `matchOrders` function calls to identify batch transactions

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identifies unique user addresses participating in OpenSea trades on each day
- **Logic**: Extracts user addresses from both Seaport and Wyvern trading data, capturing participants in two distinct roles. From Seaport trades, identifies sellers as `recipient_address` (for NFT offers with currency considerations) or `offerer_address` (for currency offers with NFT considerations), and buyers as `consideration_recipient_address` or `recipient_address` depending on trade direction. From Wyvern trades, determines sellers as `maker` when `buyHash` is null and buyers as `taker` when `sellHash` is null. Filters trades to include only OpenSea-specific transactions through multiple validation methods: transactions with fees sent to known OpenSea fee addresses, transactions with valid OpenSea zone identifiers, transactions containing OpenSea website identifiers in traces, or transactions using recognized OpenSea fee recipients
- **Key fields**: `user_address` (Ethereum addresses), `user_type` (NFT seller or NFT buyer), `timestamp` (daily grain), `chain`, `product_id`

### Component B: OpenSea trade volume identification  
- **Purpose**: Aggregates all trading activity attributable to the OpenSea platform from multiple protocol sources
- **Logic**: Combines Seaport and Wyvern trade data using union operations, applying multiple filtering criteria to ensure OpenSea attribution. For Seaport trades, includes transactions where protocol fees are sent to known OpenSea addresses, transactions with valid OpenSea zone ownership, or transactions containing OpenSea website markers. For Wyvern trades, includes transactions where fee recipients match known OpenSea addresses. Handles complex Seaport offer/consideration structures by parsing embedded arrays to extract trade participants, amounts, and token addresses. Adjusts null addresses to WETH for proper price conversion and aggregates duplicate records from multiple matching criteria
- **Key fields**: `nft_seller_address`, `nft_buyer_address`, `volume_amount`, `token_address`, `nft_address`, `transaction_hash`

### Component C: HyperLogLog preparation
- **Purpose**: Converts daily user data into probabilistic data structures for efficient unique counting across time windows
- **Logic**: Groups daily active users by timestamp, chain, user type, and product dimensions, then initializes HyperLogLog structures with 15-bit precision using `hll_count.init()`. This approach enables approximate but highly accurate unique user counting while reducing memory and computational requirements for large datasets spanning multiple months
- **Key fields**: `hll` (HyperLogLog structure), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each day to capture monthly active user periods
- **Logic**: Generates a complete datespine covering all days from the earliest user activity to yesterday using `generate_timestamp_array()`. For each day in the datespine, creates a 30-day lookback window by generating an array of the previous 29 days plus the current day. Cross-joins the datespine with these window periods to create all combinations of target dates and their corresponding 30-day windows, ensuring no gaps in the time series
- **Key fields**: `timestamp` (target date), `joinday` (individual days within the 30-day window)

### Component E: HyperLogLog aggregation
- **Purpose**: Merges HyperLogLog structures across 30-day windows to count unique users
- **Logic**: Joins the rolling window structure with daily HLL data on matching dates, then groups by target timestamp and dimensions while merging HLL structures using `hll_count.merge_partial()`. This operation combines probabilistic user counts across the entire 30-day period for each target date, maintaining accuracy while handling overlapping user activity across multiple days
- **Key fields**: Merged `hll` structures grouped by `timestamp`, `chain_id`, `user_type`, `product_id`

### Component F: Dimensional breakdowns
- **Purpose**: Calculates MAU across different analytical dimensions for flexible reporting
- **Logic**: Creates four separate dimensional views from the aggregated HLL data. Project-level breakdown provides overall MAU by extracting from merged HLL structures without dimensional filtering. Chain-level breakdown groups by `chain_id` to show activity per blockchain. User-type breakdown separates NFT buyers from NFT sellers. Product-level breakdown segments by `product_id` for sub-product analysis. Each breakdown nullifies irrelevant dimension fields and applies `hll_count.extract()` to convert HLL structures back to integer user counts
- **Key fields**: `user_mau` (extracted unique user count), `dimensions` (breakdown type), dimension-specific fields

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single table using `union all` operations, preserving the distinct analytical perspectives while maintaining a consistent schema structure
- **Currency conversion**: Not applicable for user counting metrics
- **Time aggregation**: Uses rolling 30-day windows updated daily, with each day representing the MAU for the trailing 30-day period ending on that date
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize output format, add project metadata, implement zero-filling for missing dates, and ensure consistent schema across all user metrics

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

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

OpenSea

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown