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

## 1. Overview

Rarible user DAU (Daily Active Users) measures the number of unique users who interact with the Rarible NFT marketplace ecosystem on any given day. This metric captures both direct interactions with Rarible's marketplace contracts and aggregated trading activity where users trade Rarible-compatible NFTs through external platforms. The calculation uses HyperLogLog algorithms for efficient distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

- **Rarible marketplace events**: Parsed `ERC721Sale_Buy`, `ERC1155Sale_Buy`, `TokenSale_Buy`, and `ExchangeV1_Buy` events from Rarible v1 and v2 contracts on Ethereum
- **Exchange function calls**: Parsed `matchOrders`, `directPurchase`, and `directAcceptBid` function calls from Rarible ExchangeV2 contracts on Ethereum and ExchangeMeta contracts on Polygon
- **Aggregator marketplace events**: Parsed events from external NFT marketplaces including OpenSea Seaport `OrderFulfilled` events, LooksRare `TakerAsk` and `TakerBid` events, X2Y2 `EvProfit` events, and SudoSwap swap function calls on Ethereum
- **Transaction metadata**: Blockchain transaction timestamps, transaction hashes, and block information from Ethereum and Polygon networks
- **Chain availability data**: Filters for determining when specific blockchain networks were operational and providing reliable data

## 3. Step-by-step calculation

### Component A: User extraction from Rarible marketplace events
- **Purpose**: Identifies users participating in direct Rarible marketplace transactions through buy/sell events
- **Logic**: Extracts user addresses from parsed Rarible marketplace events across multiple contract versions. For `ERC721Sale_Buy` and `ERC1155Sale_Buy` events, captures both `buyer` and `seller`/`owner` addresses. For `TokenSale_Buy` events, captures `buyer` and `seller` addresses. For `ExchangeV1_Buy` events, captures `buyer` and `owner` addresses. All users are classified as 'Trader' type and associated with the 'raribleexchange' product
- **Key fields**: `block_timestamp` for daily aggregation, `transaction_hash` for deduplication, `buyer`/`seller`/`owner` addresses as user identifiers, chain identifier, and user classification

### Component B: User extraction from exchange function calls  
- **Purpose**: Identifies users participating in Rarible marketplace transactions through direct contract function calls
- **Logic**: Extracts user addresses from successful exchange function calls on Ethereum and Polygon networks. For `matchOrders` functions, captures both `orderLeft.maker`, `orderRight.maker`, `orderLeft.taker`, and `orderRight.taker` addresses from order structures. For `directPurchase` and `directAcceptBid` functions, captures the `from_address` as the active user. Only includes successful transactions where status equals true. All users are classified as 'Trader' type
- **Key fields**: `block_timestamp`, `transaction_hash`, nested order maker/taker addresses, `from_address` for direct functions, chain identifier, and success status filter

### Component C: User extraction from aggregator marketplaces
- **Purpose**: Captures Rarible users who trade through external NFT marketplaces and aggregators
- **Logic**: Extracts user addresses from external marketplace events where users may be trading Rarible-compatible NFTs. Includes OpenSea Seaport events capturing `offerer` and `recipient` addresses, LooksRare events capturing `taker` addresses, X2Y2 events capturing `to` addresses, and SudoSwap function calls capturing `nftRecipient` addresses. All users are classified as 'Aggregator Trader' type to distinguish from direct Rarible interactions
- **Key fields**: Event-specific user address fields (`offerer`, `recipient`, `taker`, `to`, `nftRecipient`), timestamp and transaction identifiers, chain information

### Component D: Daily user aggregation
- **Purpose**: Consolidates all user interactions into daily distinct user counts
- **Logic**: Combines user addresses from all three extraction components and truncates timestamps to daily boundaries using timestamp truncation. Performs distinct counting on user addresses within each day, maintaining dimensions for chain, user type, market sector ('nfts'), business segment ('marketplace'), and product identifier. Applies chain availability filters to ensure data quality
- **Key fields**: Truncated daily `timestamp`, `timestamp_grain` set to 'day', `chain`, `user_type`, `product_id`, distinct `user_address` as the DAU metric

### Component E: HyperLogLog aggregation and dimensional breakdowns
- **Purpose**: Efficiently aggregates daily active user counts across multiple dimensions using probabilistic counting
- **Logic**: Initializes HyperLogLog sketches for each distinct user within daily/chain/user_type/product combinations. Creates four separate dimensional views: project-level aggregation (all dimensions collapsed), chain-level breakdown (preserving chain dimension), user-type-level breakdown (preserving user type classification), and product-level breakdown (preserving product identifier). Uses HyperLogLog merge operations to combine sketches and extract final counts, enabling efficient distinct counting across large datasets
- **Key fields**: HyperLogLog initialized sketches, merged sketch aggregations, extracted distinct user counts, dimensional identifiers (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with standardized schema including timestamp, dimension type, and relevant identifiers
- **Data completeness**: Applies the `finalize_metric_user_dau` macro with 'fill_zeros' strategy to ensure continuous daily time series with zero values for days with no activity
- **Chain filtering**: Applies chain availability filters to exclude data from periods when specific blockchain networks were not reliably operational
- **Final calculation**: The metric represents the distinct count of user addresses who performed any qualifying interaction with the Rarible ecosystem on each day, segmented across multiple dimensional breakdowns for comprehensive analysis

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

Unique revenue-generating users over a fixed 24-hour window.

RaribleRARI

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown