website

Exchanges (DEX)

Moonshot

# Moonshot Revenue Methodology

## 1. Overview

Moonshot revenue represents the total fees collected by the Moonshot protocol on Solana. The metric captures all tokens (both native SOL and SPL tokens) transferred to Moonshot's designated fee collection address, converted to USD and aggregated daily. Revenue is calculated as the direct equivalent of fees collected, providing insight into the protocol's earnings from user activity.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Solana native transfers**: Native SOL transfer records showing movements of SOL tokens between addresses
- **Solana SPL token transfers**: SPL (Solana Program Library) token transfer records for all tokens on Solana
- **End-of-day token price feeds**: Daily closing prices for SOL and SPL tokens used for USD conversion
- **Token metadata**: Token decimal information and identifiers required for proper amount normalization

## 3. Step-by-step calculation

### Component A: Native SOL fee collection
- **Purpose**: Captures fees paid to Moonshot in native SOL tokens
- **Logic**: Identifies all native SOL transfers directed to the Moonshot fee collection address `5wkyL2FLEcyUUgc3UeGntHTAfWfzDrVuxMnaMm7792Gk`. The calculation filters Solana native transfer records to include only transfers where the recipient address matches the fee collection address and excludes self-transfers where the transaction signer is also the fee collection address
- **Key fields**: `block_timestamp` for timing, `transaction_id` for uniqueness, `transaction_signer` as the fee payer, `amount` as the SOL fee amount, with `token_address` set to SOL's identifier `So11111111111111111111111111111111111111112`

### Component B: SPL token fee collection  
- **Purpose**: Captures fees paid to Moonshot in various SPL tokens
- **Logic**: Identifies all SPL token transfers directed to the same Moonshot fee collection address. The calculation filters Solana SPL token transfer records to include only transfers where the recipient owner address matches the fee collection address and excludes self-transfers where the transaction signer is the fee collection address
- **Key fields**: `block_timestamp` for timing, `transaction_id` for uniqueness, `transaction_signer` as the fee payer, `token_address` identifying the specific SPL token, and `amount` as the token fee amount

### Component C: Daily fee aggregation
- **Purpose**: Combines and aggregates all fee collections by day and token type
- **Logic**: Unions the native SOL and SPL token fee data, then groups by day (truncating timestamps to daily boundaries), chain identifier (always 'solana'), product identifier (null for Moonshot), and token address. The calculation sums all fee amounts within each group to get total daily fees per token
- **Key fields**: `timestamp` (daily), `chain_id`, `product_id`, `token_address`, and aggregated `fees` amount

### Final aggregation
- **Combining components**: The two fee collection components are combined using a union operation, then aggregated by day and token type to create a comprehensive view of all Moonshot fees
- **Currency conversion**: All token amounts are converted to USD using end-of-day token prices, with proper decimal correction applied based on each token's decimal specification
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, ensuring consistent daily reporting periods
- **Final calculation**: Revenue is calculated as the direct sum of all converted USD fee amounts, with the finalize metric macro ensuring proper schema compliance, ID validation, and zero-filling for any missing days in the time series

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

Moonshot

Revenue

Revenue

Competitive landscape