Creators mint & users sell NFTs on Rarible. Creators and users receive payments from sales & creators receive royalties from secondary sales.

Rarible is a non-custodial NFT marketplace protocol built on Ethereum. Rarible was founded by Alexander Salnikov and launched in 2020.

RARI tokenholders own and govern the protocol. They currently take all of the total transaction fees paid by traders (revenue). Rarible's investors include Coinbase Ventures, CoinFund, ParaFi Capital, etc.

governance

github

twitter

discord

etherscan

website

NFT marketplaces

Rarible

# Rarible Active users (monthly) Methodology

## 1. Overview

The Rarible Monthly Active Users (MAU) metric measures the number of unique users who interact with the Rarible marketplace ecosystem within any 30-day rolling period. This metric answers the business question "How many distinct users are actively using Rarible's marketplace services on a monthly basis?" The calculation uses a sophisticated rolling window approach combined with HyperLogLog probabilistic data structures to efficiently count distinct users across multiple dimensional breakdowns while handling the computational complexity of large-scale blockchain data.

## 2. Data sources

The calculation draws from several categories of blockchain data sources:

- **Rarible marketplace events**: Parsed Ethereum event logs from Rarible's marketplace contracts including `ERC721Sale_Buy`, `ERC1155Sale_Buy`, `TokenSale_Buy`, and `ExchangeV1_Buy` events across Rarible v1 and v2 contracts
- **Rarible function call traces**: Ethereum and Polygon transaction traces capturing calls to Rarible's exchange functions including `matchOrders`, `directPurchase`, and `directAcceptBid` operations
- **Aggregator marketplace events**: Parsed event logs from third-party marketplaces where Rarible NFTs are traded, including OpenSea Seaport `OrderFulfilled` events, LooksRare `TakerAsk`/`TakerBid` events, X2Y2 `EvProfit` events, and Sudoswap swap function calls
- **Transaction metadata**: Blockchain transaction records providing timestamps, transaction hashes, and execution status for validation

## 3. Step-by-step calculation

### Component A: User address extraction
- **Purpose**: Identify all unique user addresses that interact with Rarible marketplace services and classify them by interaction type
- **Logic**: Extract user addresses from various parameter fields within marketplace events and function calls. For direct Rarible events, extract addresses from `buyer`, `seller`, and `owner` fields. For function calls, extract addresses from complex nested parameters like `orderLeft.maker`, `orderRight.maker`, `orderLeft.taker`, and `orderRight.taker`. For aggregator events, extract recipient and profit addresses from third-party marketplace transactions involving Rarible NFTs. Filter function calls to only include successful executions where `status` equals true.
- **Key fields**: `user_address` (extracted user identifier), `user_type` (classified as either 'Trader' for direct Rarible users or 'Aggregator Trader' for users trading through other platforms), `block_timestamp` (transaction timing), `chain` (blockchain network), `product_id` (set to 'raribleexchange')

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users by aggregating unique user addresses per day while maintaining dimensional attributes
- **Logic**: Group all user interactions by day using timestamp truncation to the day level. Within each day, collect all unique user addresses along with their associated metadata including chain, user type, market sector, business segment, and product identifiers. Apply chain availability filtering to ensure only valid blockchain data is included in the analysis.
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to 'day'), `chain` (blockchain network), `user_type` (user classification), `product_id` (product identifier), `user_dau` (unique user address for that day)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists into probabilistic data structures for efficient distinct counting across time windows
- **Logic**: Transform the daily active user data into HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. Group data by timestamp, chain, user type, and product to create separate sketches for each dimensional combination. This approach enables efficient merging of user counts across multiple days without the computational overhead of exact distinct counting.
- **Key fields**: `hll` (HyperLogLog sketch containing user addresses), `timestamp` (daily boundary), `chain_id` (blockchain identifier), `user_type` (user classification), `product_id` (product identifier)

### Component D: 30-day rolling window generation
- **Purpose**: Create a comprehensive datespine and rolling window structure to calculate MAU for each day
- **Logic**: Generate a complete datespine covering all days from the minimum available date to yesterday. For each date in the datespine, create a 30-day lookback window by generating an array of the current date plus the previous 29 days. Join this rolling window structure with the daily HyperLogLog sketches to associate each date with all relevant daily user data from its 30-day window. Handle incremental processing by filtering to recent time periods based on last modified timestamps.
- **Key fields**: `timestamp` (target date for MAU calculation), `joinday` (each day within the 30-day window), `hll` (daily user sketches to be merged)

### Component E: Multi-dimensional MAU calculation
- **Purpose**: Calculate MAU across different dimensional breakdowns to support various analytical perspectives
- **Logic**: Create separate MAU calculations for four different dimensional levels: project level (overall Rarible MAU), chain level (MAU per blockchain), user type level (MAU per user classification), and product level (MAU per product). For each dimension, merge the HyperLogLog sketches from all 30 days using `hll_count.merge_partial` and extract the final distinct count using `hll_count.extract`. Set non-relevant dimensions to null for each breakdown to maintain consistent schema structure.
- **Key fields**: `dimensions` (breakdown category), `chain_id` (blockchain filter), `user_type` (user type filter), `product_id` (product filter), `user_mau` (calculated monthly active users)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema structure, using null values for non-applicable dimensions in each breakdown
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Use rolling 30-day windows calculated daily, with timestamp truncation to day boundaries and incremental processing based on monthly partitions
- **Final calculation**: The final MAU value represents the distinct count of user addresses extracted from merged HyperLogLog sketches across each 30-day rolling period, calculated separately for each dimensional breakdown and combined into a unified metric table with appropriate metadata and zero-filling for missing periods

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

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

RaribleRARI

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown