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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the Rarible NFT marketplace. This metric is calculated by dividing total daily fee revenue by the number of daily active users. ARPU provides insight into revenue efficiency and user monetization across Rarible's exchange platforms on Ethereum and Polygon networks. The calculation combines fee collection from multiple exchange versions and user activity tracking across direct trades, matched orders, and token sales.

## 2. Data sources

- **Ethereum exchange function calls**: Rarible V1 (`ExchangeV1_exchange_function`, `ExchangeV12_exchange_function`) and V2 (`ExchangeV2_directPurchase_function`, `ExchangeV2_directAcceptBid_function`, `ExchangeV2_matchOrders_function`) trading functions that capture direct purchases, bid acceptances, and order matching
- **Polygon exchange function calls**: Rarible V1 Polygon exchange functions (`ExchangeMeta_directPurchase_function`, `ExchangeMeta_directAcceptBid_function`, `ExchangeMeta_matchOrders_function`) for cross-chain trading activity
- **Sale events**: Ethereum-based sale events for ERC721, ERC1155, and token sales (`ERC721Sale_Buy_event`, `ERC1155Sale_Buy_event`, `TokenSale_Buy_event`) capturing marketplace transactions
- **Sale function calls**: Rarible V2 Ethereum sale functions (`ERC721Sale_buy_function`, `ERC1155Sale_buy_function`) for direct token purchases
- **Royalty registry data**: Function calls to Rarible's royalty registries (`RoyaltyRegistry_getRoyalties_function`, `RoyaltiesRegistry_getRoyalties_function`) providing royalty rate information
- **Aggregated marketplace events**: Third-party marketplace events from OpenSea Seaport, LooksRare, X2Y2, and Sudoswap that route through Rarible for user classification
- **Token metadata**: Contract information for token identification and decimal correction
- **End-of-day price feeds**: Daily token price data for USD conversion of fee amounts

## 3. Step-by-step calculation

### Component A: User activity tracking
- **Purpose**: Identify and count daily active users across all Rarible trading activities
- **Logic**: Extract user addresses from multiple blockchain event types including sale events and exchange function calls. Capture buyers, sellers, order makers, and order takers from both direct Rarible activity and aggregated marketplace routing. User addresses include `buyer`, `seller`, `owner`, `maker`, `taker`, and `from_address` fields depending on the specific event or function. Classify users as either 'Trader' for direct Rarible activity or 'Aggregator Trader' for activity routed through other marketplaces. Aggregate daily using HyperLogLog to count distinct users efficiently across multiple dimensions including chain, user type, and product
- **Key fields**: `user_address` (extracted from various address fields), `user_type` (Trader/Aggregator Trader classification), `block_timestamp` (for daily aggregation)

### Component B: V1 exchange revenue calculation  
- **Purpose**: Calculate fee revenue from Rarible V1 exchange trades on Ethereum
- **Logic**: Process exchange function calls from V1 and V1.2 contracts. Extract fee tiers by combining `buyerFee` and `sellerFee` parameters and dividing by 10^4 to convert from basis points. Calculate trade amounts based on order asset types, using buying/selling ratio calculations for token-to-NFT trades. Handle token address normalization by converting null addresses to WETH. Apply fee calculations differently based on whether the trade includes ETH value - if no ETH value, add half the fee amount to the base trade amount to derive total revenue
- **Key fields**: `buyerFee`, `sellerFee` (fee parameters), `buying`, `selling`, `amount` (trade values), `value` (ETH transaction value)

### Component C: V2 exchange revenue calculation
- **Purpose**: Calculate fee revenue from Rarible V2 exchange trades across Ethereum and Polygon
- **Logic**: Combine direct trades (purchases and bids) with matched orders. For direct trades, extract fee tiers from the last 5 hexadecimal characters of order data fields, converting to decimal and dividing by 10^4. Handle purchases by using total transaction values, while for bids add half the calculated fee amount to the trade amount. For matched orders, identify payment tokens through complex asset type parsing from order data, using substring operations to extract token addresses and validate against known token lists. Calculate fee tiers from combined left and right order data. Join with royalty registry data based on transaction hash and trace address matching to add royalty amounts to fee calculations
- **Key fields**: `sellOrderData`, `buyOrderData`, `bidData` (fee tier sources), `paymentToken`, `makeAsset`, `takeAsset` (token and amount identification), `directPurchase`, `matchOrders` (trade type differentiation)

### Component D: Token sales revenue calculation
- **Purpose**: Calculate fee revenue from direct token sales across ERC721, ERC1155, and general token contracts
- **Logic**: Process sale events and function calls from multiple contract types. For events, use fixed WETH addresses and extract prices directly, with ERC1155 sales multiplied by quantity values. For function calls, calculate fees by applying `sellerFee` percentages to sale prices, with ERC1155 calculations including both price and buying quantity multipliers. All token sales are denominated in WETH for consistency. Handle different NFT standards with appropriate amount calculations - single units for ERC721 and quantity-based for ERC1155
- **Key fields**: `price` (sale amount), `value` (quantity for ERC1155), `sellerFee` (fee percentage), `buying` (purchase quantity)

### Component E: Royalty integration
- **Purpose**: Add royalty fee components to V2 exchange revenue calculations  
- **Logic**: Extract royalty tiers from registry function calls, converting values by dividing by 10^4. Match royalty data to trades using transaction hash and trace address alignment, ensuring royalty recipients differ from NFT sellers to avoid double-counting. Apply royalty rates to trade amounts and add to total fee calculations for V2 exchanges
- **Key fields**: `token` (NFT contract), `account` (royalty recipient), `value` (royalty rate), `trace_address` (transaction linking)

### Final aggregation
- **Combining components**: Union all revenue sources (V1 exchange fees, V2 exchange fees, V2 royalty fees, token sale fees) into daily aggregates by timestamp, chain, and product dimensions. Sum all fee amounts per day while maintaining separation by token type for accurate USD conversion
- **Currency conversion**: Convert all fee amounts to USD using end-of-day token price feeds, applying decimal corrections based on token metadata to normalize amounts before price multiplication
- **Time aggregation**: Group all data by day using timestamp truncation, ensuring consistent daily boundaries across all revenue sources and user activity
- **Final calculation**: Divide total daily revenue (sum of all fee components in USD) by daily active users (distinct count using HyperLogLog) to produce ARPU values for each day. Apply zero-filling strategy for days with no activity to maintain complete time series

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

RaribleRARI

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape