Validators process transactions and receive fees from users (supply-side fees).

Solana is a smart contract platform for decentralized applications (a blockchain). Solana was founded by Anatoly Yakovenko, Greg Fitzgerald, Raj Gokal, etc. and launched in 2020.

SOL holders own and govern the protocol. They currently take a cut of the transaction fees paid by users (revenue). Solana’s investors include Polychain Capital, ParaFi capital, Passport capital, etc.

governance

github

twitter

discord

etherscan

website

Blockchains (L1)

Solana

# Solana Revenue Methodology

## 1. Overview

Revenue measures the portion of transaction fees that is permanently removed from circulation through the Solana burn mechanism. This value represents the protocol's economic take rate from network activity, as burned assets are effectively removed from the circulating supply. Revenue is derived from a fixed percentage of base fees generated by both vote and non-vote transactions processed on the network.

## 2. Data sources

- **Blockchain events**: Transaction fee metadata, priority fee components, and transaction-level configuration data captured from blocks and transactions, covering Solana
- **External data**: End-of-day price feeds for the native asset

## 3. Step-by-step calculation

### Component A: Transaction fee aggregation

- **Purpose**: Sum all transaction fees collected across the network to establish the base for revenue calculations
- **Logic**: Fees are aggregated from block-level data, including successful and failed vote transaction fees and successful and failed non-vote transaction fees. Priority fees, which are categorized as additional payments for transaction prioritization, are identified as a specific sub-component of the non-vote transaction fees.
- **Key fields**: `successful_vote_transactions_fee`, `failed_vote_transactions_fee`, `successful_non_vote_transactions_fee`, `failed_non_vote_transactions_fee`, and `non_vote_transactions_priority_fee`

### Component B: Priority fee adjustment calculation

- **Purpose**: Calculate adjustments to replace inferred block-level priority fees with actual configured priority fees for V1 transactions
- **Logic**: For V1 transactions starting September 15, 2026, priority fees are determined using transaction-level configuration fields. If explicit configuration fields (such as compute unit limits, loaded accounts data size limits, or heap sizes) are present but the priority fee is omitted, the priority fee is set to zero; otherwise, the inferred priority fee (calculated as the transaction fee minus 5,000 lamports per signature) is preserved. The adjustment is calculated as the difference between the configured priority fee and the inferred priority fee.
- **Key fields**: `transaction_config_priority_fee`, `transaction_config_compute_unit_limit`, `transaction_config_loaded_accounts_data_size_limit`, `transaction_config_heap_size`, `fee`, and `required_signatures_count`

### Component C: Protocol burn and revenue identification

- **Purpose**: Calculate the specific portion of fees retained by the protocol as revenue
- **Logic**: Revenue is determined based on the network's programmatic burn schedule. For historical data prior to the SIMD-0096 upgrade, a 50% take rate is applied to the total fees collected. For data following the implementation of the SIMD-0096 upgrade, revenue is calculated as 50% of the base fees. Base fees are isolated by subtracting 100% of the priority fees (including the priority fee adjustments for V1 transactions) from the total fee aggregate, as priority fees are distributed entirely to validators rather than being burned by the protocol.
- **Key fields**: `amount` (base fees), `priority_fee_adjustment`, and a constant fee cut of 0.5

### Component D: USD conversion and normalization

- **Purpose**: Normalize native asset values and convert them into USD for standardized reporting
- **Logic**: Native asset amounts are normalized by decimal precision. The resulting values are multiplied by end-of-day price feeds. All data is aggregated at a daily granularity using UTC day boundaries.
- **Key fields**: `price_usd` and `timestamp`

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

SolanaSOL

Revenue

Revenue

Competitive landscape