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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent royalty payments made to NFT creators and sellers on the Rarible marketplace. This metric captures the total daily value of royalties paid across all NFT trades on Rarible's exchange contracts, answering the question of how much revenue flows to the supply side (creators/sellers) of the marketplace. The calculation aggregates royalty amounts from individual trades and converts them to USD values.

## 2. Data sources

- **Smart contract function calls**: Parsed Rarible exchange contract interactions including `directPurchase`, `directAcceptBid`, and `matchOrders` functions on Ethereum and Polygon networks
- **Royalty registry data**: `getRoyalties` function calls from RoyaltyRegistry contracts on Ethereum and Polygon that define royalty percentages for specific NFTs
- **Token metadata**: Token information for validating payment token addresses and handling decimal conversions
- **External price data**: End-of-day token price feeds for USD conversion of fees paid in various cryptocurrencies

## 3. Step-by-step calculation

### Component A: Direct trade royalty extraction
- **Purpose**: Captures royalties from direct NFT purchases and bid acceptances
- **Logic**: Extracts trade data from `directPurchase` and `directAcceptBid` function calls on Rarible exchange contracts. For purchase orders, uses the buyer address and sell order maker. For bid orders, uses the contract caller and from address as seller. Fee tiers are calculated by extracting the last 5 hexadecimal characters from sell order data and buy order data (or bid data), converting to integers, summing them, and dividing by 10,000. Native token addresses are replaced with wrapped token equivalents. Trade amounts come from order payment amounts, with bid trades using the lesser of bid payment amount and sell order payment amount.
- **Key fields**: `buyOrderPaymentAmount` or `bidPaymentAmount` for trade values, `sellOrderData` and `buyOrderData` for embedded fee information, `paymentToken` for the currency used

### Component B: Match order royalty extraction  
- **Purpose**: Captures royalties from matched NFT orders where buyers and sellers are paired
- **Logic**: Processes `matchOrders` function calls where left and right orders are matched. Fee tiers are calculated by summing the last 5 hexadecimal characters from left order data and right order data, then dividing by 10,000. Token addresses are determined by examining make and take asset data from both orders, prioritizing tokens that exist in the token registry. Trade amounts use the lesser value between opposite direction make and take asset values to handle edge cases. Native ETH transfers are identified when asset data is empty and replaced with wrapped token addresses.
- **Key fields**: `makeAsset.value` and `takeAsset.value` for trade amounts, `Data` fields from order structures for fee tiers, `assetType.data` for token address extraction

### Component C: Royalty rate determination
- **Purpose**: Determines the percentage of each trade that should be paid as royalties
- **Logic**: Joins trade data with royalty registry information based on matching transaction hash and trace address prefix. Registry data comes from `getRoyalties` function calls that return recipient addresses and royalty percentages. Royalty tiers are calculated by dividing registry output values by 10,000. Only includes royalty records where the recipient address differs from the NFT seller to avoid double-counting.
- **Key fields**: `out_value` divided by 10,000 for royalty percentage, `out_account` for royalty recipient, `token` for the NFT token address

### Component D: Daily aggregation
- **Purpose**: Aggregates individual trade royalties into daily totals by relevant dimensions
- **Logic**: Calculates royalty amounts by multiplying trade amounts with their corresponding royalty tiers from the registry. Groups results by day timestamp, chain, market sector identifier, business segment identifier, product identifier, and payment token address. Sums all royalty amounts within each group to produce daily totals per token per chain.
- **Key fields**: `royalty_amount` as the product of trade amount and royalty tier, truncated daily timestamps for time grouping

### Final aggregation
- **Combining components**: Direct trades and match order trades are combined using union operations, then aggregated together in the daily rollup process
- **Currency conversion**: USD conversion is applied using end-of-day token price feeds with automatic decimal place correction based on token metadata
- **Time aggregation**: All trades are grouped by calendar day boundaries using timestamp truncation to day granularity
- **Final calculation**: The final metric value represents the total daily USD value of royalties paid to NFT creators and sellers across all Rarible exchange activities, with zero-filling applied for days with no trading activity

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

Portion of fees distributed to service providers or supply-side participants.

RaribleRARI

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown