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

## 1. Overview

LooksRare Monthly Active Users (MAU) measures the estimated number of unique wallet addresses that interact with LooksRare's NFT marketplace within rolling 30-day periods. This metric captures user activity across both LooksRare's native exchange protocol and LooksRare-facilitated trades through OpenSea's Seaport protocol. The calculation uses HyperLogLog probabilistic counting to efficiently estimate unique users over time windows and provides dimensional breakdowns by blockchain, user type, and product segments.

## 2. Data sources

The metric draws from several blockchain data sources:

- **LooksRare native exchange events**: Parsed `TakerAsk` and `TakerBid` events from LooksRare Exchange V1 and ExchangeV2 contracts on Ethereum, capturing direct marketplace transactions with maker and taker wallet addresses
- **OpenSea Seaport events**: Parsed `OrderFulfilled` events from Seaport protocol versions 1.1 through 1.6 on Ethereum, containing offer and consideration arrays that identify trade participants
- **LooksRare fee transactions**: Ethereum transactions where LooksRare's fee recipient address (`0x1838de7d4e4e42c8eb7b204a91e28e9fad14f536`) receives fees, used to identify LooksRare-facilitated Seaport trades
- **Seaport matched orders**: Ethereum events and function calls that identify matched order transactions in the Seaport protocol, used for proper trade classification
- **Transaction metadata**: Blockchain transaction timestamps, hashes, and addresses for linking events and temporal aggregation

## 3. Step-by-step calculation

### Component A: LooksRare native exchange user identification
- **Purpose**: Extract user addresses from direct LooksRare marketplace transactions
- **Logic**: Parse `TakerAsk` and `TakerBid` events from LooksRare Exchange V1 and ExchangeV2 contracts on Ethereum. For `TakerAsk` events, identify the `maker` address as seller and `taker` address as buyer. For `TakerBid` events, identify the `taker` as buyer and extract seller information from maker or fee recipient fields depending on the exchange version. Each user address is classified with a user type of either "Buyer" or "Seller" based on their role in the transaction.
- **Key fields**: Extract `block_timestamp` for daily aggregation, `transaction_hash` for deduplication, `chain` identifier, user type classification, and `user_address` for unique counting

### Component B: LooksRare Seaport trade user identification  
- **Purpose**: Identify users participating in LooksRare-facilitated trades through the Seaport protocol
- **Logic**: Process `OrderFulfilled` events from Seaport versions 1.1-1.6, filtering for transactions where LooksRare receives fees by checking if the fee recipient address appears in consideration arrays. Parse offer and consideration structures to determine trade direction based on token types (ETH/ERC20 vs ERC721/ERC1155). Extract `nft_buyer_address` and `nft_seller_address` from the complex offer/consideration matching logic, handling both regular and matched order scenarios. Apply the LooksRare fee recipient filter to ensure only LooksRare-related trades are included.
- **Key fields**: Extract `block_timestamp`, `transaction_hash`, `chain`, and separate `nft_buyer_address` and `nft_seller_address` fields for user identification

### Component C: Daily active user aggregation
- **Purpose**: Combine all user sources into daily unique active user counts
- **Logic**: Union the LooksRare native exchange users with LooksRare Seaport buyers and sellers, creating separate records for each user type. Truncate timestamps to daily grain and deduplicate user addresses within each day, chain, user type, and product combination. Apply chain availability filtering and enforce a cutoff date of February 21, 2024. Group users by timestamp, chain, user type, and product dimensions to prepare for HyperLogLog aggregation.
- **Key fields**: Standardize to `timestamp` (daily), `chain`, `user_type`, `product_id`, and `user_dau` address for counting

### Component D: HyperLogLog initialization for daily data
- **Purpose**: Create probabilistic sketches of unique users for each day
- **Logic**: Initialize HyperLogLog sketches with precision parameter 15 for each day's unique user addresses, grouped by timestamp, chain, user type, and product dimensions. This creates compact probabilistic representations that can be efficiently merged across time periods while maintaining reasonable accuracy for unique count estimation.
- **Key fields**: Generate `hll` sketch objects containing user address hashes for each dimensional combination

### Component E: Rolling 30-day window construction
- **Purpose**: Create sliding 30-day time windows for MAU calculation
- **Logic**: Generate a complete datespine from the earliest available data date to yesterday using daily intervals. For each date in the datespine, create a 30-day lookback window by generating an array of dates from 29 days prior to the current date. Use `unnest` operations to expand this into individual date combinations, creating a mapping between each target date and all dates in its 30-day window. Join this window structure with the daily HyperLogLog data to collect all relevant user sketches for each 30-day period.
- **Key fields**: Map each target `timestamp` to constituent `joinday` dates within the 30-day window, preserving dimensional groupings

### Component F: HyperLogLog merging and extraction
- **Purpose**: Combine daily user sketches within each 30-day window to estimate unique monthly users
- **Logic**: For each 30-day window, merge all daily HyperLogLog sketches using `hll_count.merge_partial()` to create a combined sketch representing unique users across the entire period. Extract the final unique count estimate using `hll_count.extract()`. This approach handles overlapping users across days within the window, providing an estimated count of unique monthly active users rather than a simple sum of daily users.
- **Key fields**: Generate final `user_mau` count estimates for each timestamp and dimensional combination

### Component G: Dimensional breakdown creation
- **Purpose**: Generate multiple analytical perspectives on the MAU data
- **Logic**: Create four separate dimensional breakdowns from the merged HyperLogLog data: project-level aggregation (all dimensions set to null), chain-level breakdown (preserving only chain dimension), user type breakdown (preserving only user type), and product-level breakdown (preserving only product dimension). Each breakdown aggregates the HLL sketches appropriately and extracts unique counts for its specific dimensional focus. Union all breakdowns together to create a comprehensive analytical dataset.
- **Key fields**: Set appropriate dimensional fields to null or preserve them based on breakdown type, maintaining `user_mau` estimates for each combination

### Final aggregation
- **Combining components**: Union the four dimensional breakdowns (project-level, chain-level, user-type-level, product-level) into a single result set, with each record representing MAU estimates for different analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps represent the end date of each 30-day rolling window, with each date showing the unique user count for the 30 days ending on that date
- **Final calculation**: Apply the `finalize_metric_user_mau` macro to standardize the schema, add metadata fields like `data_id` set to "looksrare", and implement a fill-zeros strategy for missing time periods to ensure complete time series coverage

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

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

LooksRareLOOKS

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape