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 Revenue Methodology

## 1. Overview

Rarible revenue represents the total protocol fees earned by the Rarible NFT marketplace across all supported exchange versions and chains. The metric captures fees from three distinct exchange mechanisms: Rarible v1 exchange functions, Rarible v2 exchange functions (including both direct trades and order matching), and token-specific sales contracts. Revenue is calculated by extracting fee parameters from blockchain function calls and events, applying appropriate fee calculations based on trade type, and aggregating daily across all supported chains.

## 2. Data sources

- **Rarible v1 exchange function calls**: Ethereum `ExchangeV1_exchange` and `ExchangeV12_exchange` function calls containing trade details and fee parameters
- **Rarible v2 exchange function calls**: Ethereum and Polygon function calls for `directPurchase`, `directAcceptBid`, and `matchOrders` operations with embedded fee tier data
- **Rarible token sale events**: Ethereum `ERC721Sale_Buy`, `ERC1155Sale_Buy`, and `TokenSale_Buy` events and function calls with price and fee information
- **Rarible royalty registry calls**: Ethereum and Polygon `getRoyalties` function calls providing additional fee tier information linked by transaction hash and trace address
- **Token metadata**: Token contract information for address validation and native token identification
- **End-of-day price feeds**: Token price data for USD conversion of revenue amounts

## 3. Step-by-step calculation

### Component A: Rarible v1 exchange revenue
- **Purpose**: Extracts protocol fees from Rarible's original exchange contract versions
- **Logic**: Processes `exchange` function calls from both `ExchangeV1` and `ExchangeV12` contracts on Ethereum. Identifies payment tokens by checking if `buyAsset.tokenId` equals zero (indicating fungible payment token vs NFT). Calculates fee tier as the sum of `buyerFee` and `sellerFee` parameters divided by 10,000 (converting from basis points). For trades where `total_amount` (native ETH value) is zero, calculates amount as the trade amount plus half the fee amount. Normalizes null token addresses to WETH address for consistent handling
- **Key fields**: `buyerFee` and `sellerFee` for fee calculation, `buying` and `selling` amounts for trade value, `value` for native ETH amounts, `buyAsset.token` and `sellAsset.token` for payment token identification

### Component B: Rarible v2 direct trade revenue  
- **Purpose**: Captures fees from direct purchase and bid acceptance transactions in v2 exchange
- **Logic**: Processes `directPurchase` and `directAcceptBid` function calls from Ethereum and Polygon v2 exchanges. Extracts fee tiers by taking the last 5 characters of hex-encoded `sellOrderData` and `buyOrderData` (or `bidData`), converting to integers and summing, then dividing by 10,000. For purchase trades, uses the transaction's native value as the amount. For bid trades, uses the minimum of bid and sell amounts, then adds half the calculated fee. Joins with royalty registry data by matching transaction hash and trace address to capture additional royalty-based fees
- **Key fields**: `sellOrderData` and `buyOrderData`/`bidData` for fee extraction, `buyOrderPaymentAmount` and `bidPaymentAmount` for trade amounts, `paymentToken` for token identification, `value` for native amounts

### Component C: Rarible v2 matched order revenue
- **Purpose**: Calculates fees from order matching transactions where buy and sell orders are matched by the protocol
- **Logic**: Processes `matchOrders` function calls from Ethereum and Polygon v2 exchanges. Extracts fee tiers by summing the last 5 characters of `orderLeft.Data` and `orderRight.Data` hex values, divided by 10,000. Identifies payment tokens by examining `makeAsset` and `takeAsset` data, extracting token addresses from positions 27-46 of the hex data and validating against known token lists. Calculates trade amounts as the minimum value between left order's `takeAsset.value` and right order's `makeAsset.value` (or corresponding pairs). When `total_amount` is zero, adds half the fee amount to the base trade amount
- **Key fields**: `orderLeft.Data` and `orderRight.Data` for fees, `makeAsset.value` and `takeAsset.value` for amounts, `makeAsset.assetType.data` and `takeAsset.assetType.data` for token identification

### Component D: Token sale revenue
- **Purpose**: Captures fees from direct token sale contracts for ERC721, ERC1155, and general token sales
- **Logic**: Processes `Buy` events from `ERC721Sale`, `ERC1155Sale`, and `TokenSale` contracts, plus `buy` function calls from v2 token sale contracts. For ERC1155 sales, multiplies price by quantity (`value` parameter). For v2 function calls, calculates fees as `sellerFee` divided by 10,000 multiplied by the price. ERC1155 v2 fees are multiplied by quantity and doubled. Uses WETH as the standard payment token for all token sales
- **Key fields**: `price` for trade value, `value` for ERC1155 quantities, `sellerFee` for v2 fee calculations, `buying` for ERC1155 v2 quantities

### Component E: Royalty integration
- **Purpose**: Adds royalty-based fees to v2 exchange transactions
- **Logic**: Uses `getRoyalties` function call results from Ethereum and Polygon royalty registries to supplement fee calculations. Matches transactions by `transaction_hash` and trace address (using first element of comma-separated trace arrays). Calculates royalty amounts by multiplying trade amounts by `royalty_tier` values (converted from basis points by dividing by 10,000). Only includes royalties where the recipient address differs from the NFT seller address to avoid double-counting
- **Key fields**: `token` for NFT contract, `account` for royalty recipient, `value` for royalty tier in basis points

### Final aggregation
- **Combining components**: All revenue streams (v1 exchange, v2 direct trades, v2 matched orders, token sales) are combined using union operations, with each maintaining consistent field structure including timestamp, chain, token address, and calculated fee amounts
- **Currency conversion**: Revenue amounts are converted to USD using the `convert_to_usd_and_correct_decimals` macro, which applies end-of-day token prices and adjusts for token decimal places
- **Time aggregation**: Timestamps are truncated to daily boundaries using `timestamp_trunc(block_timestamp, day)` and revenue is summed by day, chain, market sector, business segment, product, and token address
- **Final calculation**: The `finalize_metric_revenue` macro applies final formatting with a 'fill_zeros' strategy for missing data points and applies chain availability filters to ensure only supported chains are included in the output

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

RaribleRARI

Revenue

Revenue

Competitive landscape

Chain breakdown