website

Wallet providers

Phantom

# Phantom Fees Methodology

## 1. Overview

The Phantom fees metric measures the total daily fee revenue generated by the Phantom wallet application on Solana. This metric captures fees collected by Phantom through various user interactions including swaps, trades, and other wallet services. The calculation aggregates both native SOL fees and SPL token fees transferred to Phantom's designated fee collection addresses, converts all amounts to USD, and provides daily totals.

## 2. Data sources

The metric relies on the following raw data sources:
- **Native SOL transfers**: Solana blockchain records of native SOL token transfers, specifically tracking transfers TO designated recipient addresses
- **SPL token transfers**: Solana blockchain records of SPL (Solana Program Library) token transfers, tracking transfers where the recipient owner matches designated addresses
- **End-of-day token price feeds**: Daily closing prices for SOL and SPL tokens used for USD conversion
- **Token metadata**: Token decimal specifications and contract details for proper amount normalization

## 3. Step-by-step calculation

### Component A: Native SOL fee collection
- **Purpose**: Captures fees collected in native SOL tokens
- **Logic**: Filters native SOL transfer records to identify transfers sent TO any of eight specific Phantom fee collection addresses: `25mYnjJ2MXHZH6NvTTdA63JvjgRVcuiaj6MRiEQNs1Dq`, `9yj3zvLS3fDMqi1F8zhkaWfq8TZpZWHe6cz1Sgt7djXf`, `8psNvWTrdNTiVRNzAgsou9kETXNJm2SXZyaKuJraVRtf`, `CnmA6Zb8hLrG33AT4RTzKdGv1vKwRBKQQr8iNckvv8Yg`, `2rQZb9xqQGwoCMDkpabbzDB9wyPTjSPj9WNhJodTaRHm`, `9gnLg6NtVxaASvxtADLFKZ9s8yHft1jXb1Vu6gVKvh1J`, `wtpXRqKLdGc7vpReogsRugv6EFCw4HBHcxm8pFcR84a`, and `D1NJy3Qq3RKBG29EDRj28ozbGwnhmM5yBUp8PonSYUnm`. Excludes transactions where the transaction signer is one of these same addresses to avoid counting internal transfers or wallet management operations. Aggregates transfer amounts by day, using the wrapped SOL token address `So11111111111111111111111111111111111111112` as the standardized token identifier.
- **Key fields**: `block_timestamp` for timing, `transaction_id` for deduplication, `transaction_signer` for sender identification, `amount` for transfer value, and `to_address` for recipient filtering

### Component B: SPL token fee collection  
- **Purpose**: Captures fees collected in SPL tokens (non-native Solana tokens)
- **Logic**: Filters SPL token transfer records to identify transfers where the recipient owner address matches any of the same eight Phantom fee collection addresses. Uses the owner-based filtering approach appropriate for SPL token transfers, where tokens are transferred to accounts owned by the fee collection addresses. Excludes transactions where the transaction signer matches any fee collection address to avoid internal movements. Aggregates amounts by day and individual token address, preserving the specific SPL token being transferred rather than normalizing to a single identifier.
- **Key fields**: `block_timestamp` for timing, `transaction_id` for transaction linking, `token_address` for specific SPL token identification, `transaction_signer` for sender identification, `amount` converted to bignumeric precision, and `to_owner_address` for recipient filtering

### Final aggregation
- **Combining components**: Unions the native SOL fees and SPL token fees into a single dataset, maintaining separate records for each token type and daily timestamp
- **Currency conversion**: Applies USD conversion using end-of-day price feeds matched by token address and date, with automatic decimal correction based on each token's decimal specification to ensure proper unit conversion  
- **Time aggregation**: Truncates all timestamps to daily boundaries and groups by day, chain (always 'solana'), product_id (null for Phantom), and token_address
- **Final calculation**: Sums all fee amounts in USD for each day-token combination, applies the finalize_metric_fees macro with a fill_zeros strategy to ensure complete time series coverage by inserting zero values for days with no fee collection activity, validates data IDs, and applies chain availability filtering to ensure data consistency across the reporting period

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

Total value users pay to use a protocol (gross fees, user-paid fees).

Phantom

Fees

Fees

Competitive landscape