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

## 1. Overview

The OpenSea Weekly Active Users (WAU) metric measures the number of unique users who engaged in NFT trading activities on the OpenSea platform within a 7-day rolling window. This metric answers the business question: "How many distinct users are actively trading NFTs on OpenSea each week?" The calculation uses HyperLogLog (HLL) sketching for memory-efficient computation of unique users across the rolling window, tracking both NFT buyers and sellers as separate user categories.

## 2. Data sources

- **Seaport protocol events**: Parsed `OrderFulfilled` events from Seaport contract versions 1.1 through 1.6 on Ethereum, containing order execution details, token transfers, and participant addresses
- **WyvernExchange protocol data**: `OrdersMatched` events and `atomicMatch_` function calls from the legacy Wyvern protocol, including trade details and participant information
- **Ethereum transaction traces**: Raw transaction trace data used to identify OpenSea website-originated transactions through specific input pattern matching (`360c6ebe` signature)
- **OpenSea contract metadata**: Predefined lists of valid zone addresses, fee recipient addresses, and protocol-owned contract addresses used for transaction validation
- **Blockchain transaction records**: Ethereum transaction data including timestamps, hashes, and execution details for trade identification and temporal aggregation

## 3. Step-by-step calculation

### Component A: Trade data extraction and validation
- **Purpose**: Identify valid OpenSea trading transactions from multiple protocol sources
- **Logic**: Extracts trading data from both Seaport (versions 1.1-1.6) and WyvernExchange protocols. Seaport trades are parsed from `OrderFulfilled` events with offer and consideration arrays flattened to identify NFT transfers and payment details. WyvernExchange trades combine `OrdersMatched` events with `atomicMatch_` function calls to reconstruct complete trade information. All trades include participant addresses (`nft_seller_address`, `nft_buyer_address`), token details, and volume amounts
- **Key fields**: `block_timestamp`, `transaction_hash`, `nft_seller_address`, `nft_buyer_address`, `volume_amount`, `token_address`, `account_address`

### Component B: OpenSea transaction filtering
- **Purpose**: Identify transactions that definitively occurred through OpenSea's platform
- **Logic**: Applies three validation criteria to ensure trades are OpenSea-specific. First criterion identifies protocol fee transactions where fees are paid to known OpenSea fee addresses. Second criterion identifies protocol-owned transactions using valid OpenSea zone addresses from the `zone` field in Seaport orders. Third criterion identifies website transactions by detecting the `360c6ebe` signature in Ethereum transaction input data, indicating frontend-originated trades. These filters ensure only genuine OpenSea platform activity is counted
- **Key fields**: `fee_recipient_address`, `owner_id` (zone address), transaction input patterns, OpenSea contract addresses

### Component C: Daily active user identification
- **Purpose**: Extract unique user addresses from validated trading activities
- **Logic**: Processes validated trades to identify unique daily active users by extracting both `nft_seller_address` and `nft_buyer_address` as separate records. Each user address is categorized by user type (NFT seller or NFT buyer) and associated with trading day timestamp truncated to day boundaries. The logic creates separate records for sellers and buyers from the same transaction, allowing users to be counted in both categories if they engage in both activities
- **Key fields**: `timestamp` (day-truncated), `user_type`, `chain`, `user_address`, `product_id`

### Component D: HyperLogLog daily aggregation
- **Purpose**: Create memory-efficient sketches of daily unique users for rolling window calculations
- **Logic**: Aggregates daily unique users using HyperLogLog sketching with precision 15 for efficient unique counting. Groups users by timestamp, chain, user type, and product dimensions, then initializes HLL sketches containing all unique user addresses for each combination. This preprocessing enables efficient rolling window calculations without storing individual user addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component E: Seven-day rolling window generation
- **Purpose**: Create continuous 7-day rolling windows for weekly active user calculation
- **Logic**: Generates a complete datespine covering all days from the earliest trade to current date minus one day. For each date in the datespine, creates a joinday array containing the target date plus the 6 preceding days, forming 7-day windows. Joins this window structure with daily HLL sketches to associate each day's user data with all relevant weekly windows. This approach ensures continuous weekly metrics even for days with no trading activity
- **Key fields**: `timestamp` (target date), `joinday` (individual days in 7-day window), HLL sketches from matching days

### Component F: Weekly active user calculation
- **Purpose**: Calculate unique weekly active users by merging daily HLL sketches
- **Logic**: For each 7-day window, merges all available daily HLL sketches using `HLL_COUNT.MERGE_PARTIAL` function, then extracts the final unique count using `HLL_COUNT.EXTRACT`. This approach efficiently handles overlapping users across multiple days within the week, ensuring each unique user is counted only once per weekly period regardless of how many days they were active
- **Key fields**: `user_wau` (weekly unique count), dimensional breakdowns (chain, user type, product)

### Final aggregation
- **Combining components**: Weekly active user counts are calculated separately for four dimensional hierarchies: project-level (overall OpenSea), chain-level (per blockchain), user-type-level (sellers vs buyers), and product-level breakdowns. Results are combined using `UNION ALL` to create a comprehensive dimensional view
- **Currency conversion**: Not applicable as this metric counts users rather than monetary values
- **Time aggregation**: Uses 7-day rolling windows with day-level granularity, where each day represents the count of unique users active within the preceding 7-day period including the current day
- **Final calculation**: The final WAU value represents the unique count of user addresses that engaged in OpenSea NFT trading (as either buyers or sellers) within any 7-day rolling period, calculated using HyperLogLog merge operations for memory efficiency and accuracy

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

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

OpenSea

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown