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

Stellar is a distributed ledger for transfer and store of value (a blockchain). Stellar was founded by Jed McCaleb launched in 2014.

XLM holders own and govern the protocol. They currently take all of the total transaction fees paid by users (revenue).

github

twitter

discord

etherscan

website

Blockchains (L1)

Stellar

# Stellar Revenue Methodology

## 1. Overview

Stellar revenue represents the total fees collected by the Stellar network from transaction processing. This metric treats transaction fees as the protocol's primary revenue source, measuring the value captured by the network for facilitating blockchain operations. The calculation aggregates all successful transaction fees, converts them from Stellar's native denomination (stroops) to USD, and presents them as daily revenue figures.

## 2. Data sources

- **Blockchain transaction records**: Stellar network transaction data containing fee information for all processed transactions
- **External price feeds**: End-of-day price feeds for XLM (Stellar Lumens) token to enable USD conversion
- **Transaction metadata**: Success/failure status and timestamp information for transaction validation

## 3. Step-by-step calculation

### Component A: Transaction fee extraction
- **Purpose**: Extracts and validates transaction fees from raw Stellar blockchain data
- **Logic**: The system processes all successful Stellar transactions and extracts the `fee_charged` field, which represents the fee paid for transaction processing. Only successful transactions (where `successful` equals true) are included, and transactions without fee information are filtered out. Each transaction's timestamp is truncated to daily boundaries to enable daily aggregation
- **Key fields**: `fee_charged` (transaction fee in stroops), `successful` (transaction status), `block_timestamp` (transaction timing)

### Component B: Daily fee aggregation
- **Purpose**: Aggregates individual transaction fees into daily totals
- **Logic**: All transaction fees within each calendar day are summed together to create daily fee totals. The aggregation also counts the number of transactions processed each day for additional context. Fees remain in stroops (Stellar's native unit) at this stage
- **Key fields**: `total_fees_stroops` (daily sum of fees), `transaction_count` (daily transaction volume)

### Component C: Unit conversion and standardization
- **Purpose**: Converts fees from native Stellar units to standard token amounts
- **Logic**: Transaction fees are converted from stroops to XLM by dividing by 10,000,000 (1 XLM = 10^7 stroops). The data is tagged with chain identifier ('stellar'), token information ('XLM'), and business classification metadata including market sector ('blockchains_l1') and business segment ('blockchain')
- **Key fields**: `fees_native` (fees in XLM), `chain_id`, `token_symbol`, `market_sector_id`, `business_segment_id`

### Component D: USD conversion
- **Purpose**: Converts native token fees to USD values using market prices
- **Logic**: The system applies end-of-day XLM price feeds to convert native token fees to USD amounts. This conversion uses the `convert_to_usd_and_correct_decimals` macro, which matches daily fee totals with corresponding XLM prices and applies the conversion
- **Key fields**: `fees` (USD-denominated fee values)

### Final aggregation
- **Combining components**: The revenue metric directly uses the USD-converted fee values from the fees calculation, treating all transaction fees as protocol revenue
- **Currency conversion**: Fees are converted from stroops to XLM using the fixed conversion rate (1 XLM = 10^7 stroops), then converted to USD using end-of-day price feeds
- **Time aggregation**: Data is aggregated at daily boundaries, with transaction timestamps truncated to calendar days
- **Final calculation**: Revenue equals the sum of all successful transaction fees for each day, converted to USD. The metric applies data validation, ensures no date gaps through zero-filling, and includes business classification metadata for reporting consistency

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

StellarXLM

Revenue

Revenue

Competitive landscape