website

Wallet providers

Phantom

# Phantom Revenue Methodology

## 1. Overview

Phantom revenue represents the total fees collected by Phantom wallet from user transactions, measured in USD on a daily basis. The metric captures revenue from both native SOL transfers and SPL (Solana Program Library) token transfers where users pay fees to Phantom's designated fee collection addresses. Revenue is calculated by identifying transfers TO Phantom's fee addresses FROM external users, then converting these fee payments to USD values. This metric answers the business question: "How much revenue does Phantom generate daily from wallet transaction fees?"

## 2. Data sources

- **Solana native transfers**: Records of native SOL transfers on the Solana blockchain, capturing transfers between addresses with amount and signer information
- **Solana SPL token transfers**: Records of SPL token transfers on Solana, including token address, amounts, and owner addresses for both sender and recipient  
- **End-of-day price feeds**: Token price data used for USD conversion of fee amounts collected in various tokens
- **Token metadata**: Configuration data providing decimal precision and other attributes needed for proper amount calculations

## 3. Step-by-step calculation

### Component A: Native SOL fee collection
- **Purpose**: Identifies and aggregates daily SOL fees paid to Phantom wallet
- **Logic**: Filters Solana native transfer events where the recipient (`to_address`) is one of eight hardcoded Phantom fee collection addresses: `25mYnjJ2MXHZH6NvTTdA63JvjgRVcuiaj6MRiEQNs1Dq`, `9yj3zvLS3fDMqi1F8zhkaWfq8TZpZWHe6cz1Sgt7djXf`, `8psNvWTrdNTiVRNzAgsou9kETXNJm2SXZyaKuJraVRtf`, `CnmA6Zb8hLrG33AT4RTzKdGv1vKwRBKQQr8iNckvv8Yg`, `2rQZb9xqQGwoCMDkpabbzDB9wyPTjSPj9WNhJodTaRHm`, `9gnLg6NtVxaASvxtADLFKZ9s8yHft1jXb1Vu6gVKvh1J`, `wtpXRqKLdGc7vpReogsRugv6EFCw4HBHcxm8pFcR84a`, and `D1NJy3Qq3RKBG29EDRj28ozbGwnhmM5yBUp8PonSYUnm`. Excludes transfers where the sender (`transaction_signer`) is also one of these Phantom addresses to avoid counting internal transfers. Truncates timestamps to daily boundaries and sums transfer amounts by day.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` for sender identification, `to_address` for recipient filtering, `amount` for fee values, and hardcoded `token_address` as `So11111111111111111111111111111111111111112` (wrapped SOL)

### Component B: SPL token fee collection  
- **Purpose**: Identifies and aggregates daily SPL token fees paid to Phantom wallet
- **Logic**: Filters Solana SPL token transfer events where the recipient owner (`to_owner_address`) is one of the same eight Phantom fee collection addresses. Excludes transfers where the sender (`transaction_signer`) is also a Phantom address to avoid internal transfers. Truncates timestamps to daily boundaries and sums transfer amounts by day and token address.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` for sender identification, `to_owner_address` for recipient filtering, `token_address` for token type, and `amount` for fee values

### Combined fee aggregation
- **Combining components**: Unions the daily SOL fee data with daily SPL token fee data, creating a single stream of all fee payments to Phantom addresses grouped by day, chain, product (null for Phantom), and token address
- **Daily grouping**: Both components aggregate to daily totals using `timestamp_trunc(block_timestamp, day)` with `sum(amount)` aggregation

### Final calculation
- **Currency conversion**: Applies USD conversion using end-of-day price feeds and corrects for token decimal places through the `convert_to_usd_and_correct_decimals` macro, ensuring proper scaling of raw token amounts
- **Schema standardization**: Uses `finalize_metric_fees` macro to apply standard metric schema, validate chain and product IDs, and fill any gaps in the time series with zeros
- **Revenue calculation**: The revenue metric simply takes the finalized fees data and relabels the `fees` column as `revenue`, since Phantom's revenue model is based on collecting transaction fees from users

*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.

Phantom

Revenue

Revenue

Competitive landscape