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 fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average fee revenue generated per daily active user on the Rarible NFT marketplace. This metric answers the business question "How much fee revenue does each active user generate on average?" and is calculated by dividing total daily fees (in USD) by the number of daily active users. The calculation combines fee data from multiple Rarible exchange versions and comprehensive user activity tracking across Ethereum and Polygon networks.

## 2. Data sources

- **Ethereum event logs**: Parsed `Buy` events from Rarible V1 contracts including `ERC721Sale`, `ERC1155Sale`, and `TokenSale` contracts capturing NFT purchase transactions
- **Ethereum function call traces**: Transaction traces from Rarible V1 `ExchangeV1` and `ExchangeV12` contracts for exchange function calls, and Rarible V2 `ExchangeV2` contracts for `matchOrders`, `directPurchase`, and `directAcceptBid` functions
- **Polygon function call traces**: Transaction traces from Rarible V1 `ExchangeMeta` contracts for cross-chain trading functions including `matchOrders`, `directPurchase`, and `directAcceptBid`
- **Royalty registry data**: Function call traces to Rarible's `RoyaltyRegistry` and `RoyaltiesRegistry` contracts on Ethereum and Polygon for `getRoyalties` function calls
- **Third-party marketplace events**: Event logs from OpenSea Seaport, LooksRare, X2Y2, and Sudoswap contracts to capture aggregated trading activity
- **End-of-day price feeds**: Daily token price data for USD conversion of fee amounts
- **Token metadata**: Token contract information including decimal places and address validation data

## 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 sources including direct event logs where users appear as `buyer`, `seller`, or `owner` in `Buy` events from ERC721, ERC1155, and TokenSale contracts. Also capture users from function call parameters including `maker`, `taker`, and transaction initiators (`from_address`) from exchange functions. Include aggregated trading activity from third-party platforms to capture users trading Rarible NFTs through aggregators. Users are classified as either 'Trader' for direct Rarible activity or 'Aggregator Trader' for third-party platform activity.
- **Key fields**: `user_address` extracted from various event and function parameters, `block_timestamp` for daily aggregation, `chain` for multi-chain tracking, `user_type` for classification

### Component B: Exchange V1 fee calculation  
- **Purpose**: Calculate fees from older Rarible exchange contracts
- **Logic**: Process `exchange` function calls from `ExchangeV1` and `ExchangeV12` contracts. Extract fee tiers by combining `buyerFee` and `sellerFee` parameters and dividing by 10,000 for percentage conversion. Determine token addresses from order data, converting null addresses to WETH. Calculate fee amounts by multiplying trade amounts by fee tiers. Handle cases where `total_amount` is zero by using parameter-based amounts plus half the fee.
- **Key fields**: `fee_tier` from combined buyer and seller fees, `token_address` with null-to-WETH conversion, `amount` from trade value, `fee_amount` as calculated fee

### Component C: Exchange V2 fee calculation
- **Purpose**: Calculate fees from newer Rarible exchange contracts including protocol fees and royalties
- **Logic**: Process two types of V2 trades separately. For direct trades (`directPurchase` and `directAcceptBid`), extract fee tiers from order data using hexadecimal string manipulation, handle different token address logic for purchases vs bids, and adjust amounts accordingly. For matched orders (`matchOrders`), determine payment tokens from asset type data, calculate amounts using the minimum of opposing order values, and extract fee tiers from combined order data. Join all trades with royalty registry data based on transaction hash and trace address to add royalty amounts. Combine protocol fees and royalties for total fee calculation.
- **Key fields**: `fee_tier` from order data manipulation, `royalty_tier` from registry lookups, `fee_amount` and `royalty_amount` as separate calculations, `trade_type` for different handling logic

### Component D: Token trade fee calculation
- **Purpose**: Calculate fees from direct token sales outside the main exchange contracts
- **Logic**: Process `Buy` events from token sale contracts and direct purchase function calls. For events, use hardcoded WETH as token address and extract prices directly. For function calls, calculate fees using `sellerFee` parameters divided by 10,000, multiply by trade amounts. Handle ERC1155 trades by multiplying price by quantity for total amounts.
- **Key fields**: `price` from event parameters, `sellerFee` from function parameters, `value` and `buying` for quantity calculations

### Final aggregation
- **Combining components**: Union all fee calculations from V1 exchange, V2 exchange, and token trades. Sum fees daily by timestamp, chain, market sector, business segment, product, and token address. For users, count distinct addresses daily using HyperLogLog aggregation across the same dimensions plus user type breakdowns.
- **Currency conversion**: Apply end-of-day token price feeds to convert native token amounts to USD values. Use decimal correction based on token metadata to ensure proper unit conversion.
- **Time aggregation**: Truncate all timestamps to day boundaries. Fill missing days with zero values for both fees and user counts to maintain consistent time series.
- **Final calculation**: Divide total daily fees in USD by daily active user count using the ARPU calculation macro. Apply zero-filling strategy to handle days with no trading activity, resulting in zero AFPU values rather than null.

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

RaribleRARI

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape