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

LooksRare is a non-custodial NFT marketplace protocol built on Ethereum and launched in 2022.

LOOKS tokenholders own and govern the protocol. They currently take a cut of the total transaction fees paid by buyers (revenue).

github

twitter

discord

etherscan

website

NFT marketplaces

LooksRare

# LooksRare Active users (weekly) Methodology

## 1. Overview

LooksRare weekly active users (WAU) measures the number of unique users who interact with LooksRare's NFT marketplace within any 7-day period. This metric captures both users of LooksRare's native exchange and users of LooksRare's aggregation service on OpenSea's Seaport protocol. The calculation uses a rolling 7-day window approach with HyperLogLog data structures for efficient unique user counting across multiple dimensions including project level, blockchain, user type (buyer/seller), and product categories.

## 2. Data sources

- **LooksRare native exchange events**: Parsed Ethereum `Exchange_TakerAsk`, `Exchange_TakerBid`, `ExchangeV2_TakerAsk`, and `ExchangeV2_TakerBid` events from LooksRare's smart contracts
- **Seaport marketplace events**: Parsed Ethereum `OrderFulfilled` events from OpenSea's Seaport protocol versions 1.1 through 1.6 
- **Seaport order matching data**: Parsed `OrdersMatched` events and `matchAdvancedOrders`/`matchOrders` function calls from Seaport contracts
- **Fee recipient data**: LooksRare's designated fee collection address used to identify their involvement in Seaport transactions

## 3. Step-by-step calculation

### Component A: LooksRare native exchange users
- **Purpose**: Identifies users interacting directly with LooksRare's native exchange contracts
- **Logic**: Extracts user addresses from LooksRare exchange events on Ethereum. For `TakerAsk` events, the `maker` is classified as seller and `taker` as buyer. For `TakerBid` events, the `maker` is seller and `taker` is buyer. For ExchangeV2 events, `bidUser` is buyer, `askUser` is seller, and the first `feeRecipient` is also counted as seller. Each event provides the user address, transaction hash, block timestamp, and user type classification.
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` for unique counting, `user_type` for buyer/seller segmentation, `chain` for blockchain identification

### Component B: LooksRare Seaport aggregation users  
- **Purpose**: Captures users who trade through LooksRare's aggregation service on OpenSea's Seaport protocol
- **Logic**: Processes Seaport `OrderFulfilled` events across versions 1.1-1.6, filtering for transactions where LooksRare's fee address appears as recipient. Flattens offer and consideration arrays to identify NFT versus currency tokens based on token type IDs (0,1 for currencies, 2,3 for NFTs). Extracts buyer and seller addresses by analyzing token flow patterns and recipient addresses. Handles matched orders differently using special logic for order matching scenarios.
- **Key fields**: `nft_buyer_address` and `nft_seller_address` for user identification, `block_timestamp` for daily grouping, `transaction_hash` for deduplication

### Component C: Fee transaction filtering
- **Purpose**: Identifies which Seaport transactions involve LooksRare as a fee recipient
- **Logic**: Scans all Seaport `OrderFulfilled` events to find transactions where LooksRare's hardcoded fee address `0x1838de7d4e4e42c8eb7b204a91e28e9fad14f536` appears either as the main recipient or within the consideration array recipients. Creates an allowlist of transaction hashes representing LooksRare's involvement in Seaport trades.
- **Key fields**: `transaction_hash` for filtering, `order_hash` for order identification

### Component D: Daily user aggregation
- **Purpose**: Combines all user sources into daily unique user lists
- **Logic**: Unions native LooksRare exchange users with Seaport aggregation users, grouping by day using timestamp truncation. Each user address is tagged with user type (buyer/seller), chain, and product metadata. Applies chain availability filtering and date boundaries. Removes duplicate user addresses within the same day, user type, and chain combination.
- **Key fields**: `timestamp` (daily), `user_address`, `user_type`, `chain`, `product_id`

### Component E: HyperLogLog initialization  
- **Purpose**: Converts daily user lists into HyperLogLog data structures for efficient unique counting
- **Logic**: Initializes HLL sketches for each day's user list using precision parameter 15. Groups by timestamp, chain, user type, and product dimensions. HLL data structures allow approximate unique counting with high accuracy while using minimal memory, enabling efficient processing of large user datasets.
- **Key fields**: `hll` (HyperLogLog sketch), grouping dimensions for breakdown categories

### Component F: Rolling window creation
- **Purpose**: Creates 7-day sliding windows for weekly active user calculation  
- **Logic**: Generates a complete datespine covering all days from the earliest data to current date minus 1 day. For each date in the spine, creates an array of the current date plus 6 preceding days (7 days total). Joins this window with the daily HLL data to associate each day with user activity from its 7-day window period.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component G: Weekly user aggregation by dimensions
- **Purpose**: Calculates weekly active users across different breakdown dimensions
- **Logic**: Merges HLL sketches across each 7-day window to count unique users. Creates separate breakdowns for project level (all chains combined), individual chains, user types (buyer/seller), and product categories. Each breakdown nullifies non-relevant dimension fields and extracts the final unique user count from the merged HLL structure.  
- **Key fields**: `user_wau` (unique user count), `dimensions` (breakdown type), dimension-specific fields

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns using `UNION ALL` to create a comprehensive view with project-level, chain-level, user type, and product-level WAU metrics in a single table
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily boundaries with 7-day rolling windows, where each day represents the count of unique users active in that day plus the 6 preceding days
- **Final calculation**: Extracts unique user counts from merged HyperLogLog sketches, applies the `finalize_metric_user_wau` macro to standardize schema and fill missing days with zero values, then filters for the appropriate incremental time range based on the last modified timestamp

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

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

LooksRareLOOKS

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape