website

twitter

Infrastructure

Helio

# Helio Revenue Methodology

## 1. Overview

Heliopay revenue represents the total USD value of fees collected by the Heliopay protocol on the Solana blockchain. Revenue is calculated by identifying all token transfers (both native SOL and SPL tokens) sent to Heliopay's designated fee collection address, aggregating them daily, and converting to USD values. The metric captures the protocol's fee generation from payment processing activities.

## 2. Data sources

- **Solana native transfers**: Native SOL token transfers on the Solana blockchain, capturing recipient addresses and transfer amounts
- **Solana SPL token transfers**: SPL (Solana Program Library) token transfers, including recipient owner addresses and token-specific transfer amounts  
- **End-of-day price feeds**: Token price data used for USD conversion
- **Token metadata**: Token decimal precision information for accurate amount calculation

## 3. Step-by-step calculation

### Component A: Native SOL fee collection
- **Purpose**: Captures fees paid to Heliopay in native SOL tokens
- **Logic**: Filters native SOL transfers where the recipient address matches the Heliopay fee collection address `FudPMePeNqmnjMX19zEKDfGXpbp6HAdW6ZGprB5gYRTZ`. Excludes transfers where the transaction signer is also the fee collection address to avoid counting internal protocol movements. Records the transfer amount, transaction details, and hard-codes the token address as the native SOL identifier `So11111111111111111111111111111111111111112`
- **Key fields**: `block_timestamp`, `transaction_id`, `transaction_signer`, `amount`, and hard-coded `token_address`

### Component B: SPL token fee collection  
- **Purpose**: Captures fees paid to Heliopay in various SPL tokens
- **Logic**: Filters SPL token transfers where the recipient owner address matches the Heliopay fee collection address `FudPMePeNqmnjMX19zEKDfGXpbp6HAdW6ZGprB5gYRTZ`. Excludes transfers where the transaction signer is the fee collection address to prevent double-counting internal transfers. Records the actual token address from the transfer data along with amounts and transaction details
- **Key fields**: `block_timestamp`, `transaction_id`, `transaction_signer`, `token_address`, and `amount`

### Component C: Daily fee aggregation
- **Purpose**: Combines native SOL and SPL token fees into unified daily totals
- **Logic**: Unions the native SOL and SPL token fee datasets, then groups by day (truncating timestamps), chain identifier, product identifier, and token address. Sums the transfer amounts to calculate total daily fees for each token. Sets timestamp grain to 'day' and chain identifier to 'solana'
- **Key fields**: `timestamp`, `timestamp_grain`, `chain_id`, `product_id`, `token_address`, and aggregated `fees`

### Final aggregation
- **Currency conversion**: Applies decimal correction using token metadata to ensure accurate token amounts, then converts all fee amounts to USD using end-of-day price feeds matched by token address and date
- **Standardization**: Processes the converted amounts through finalization macros that ensure consistent schema structure, validate data identifiers, and forward-fill any missing days with zero values to maintain complete time series
- **Revenue aliasing**: The final revenue metric simply renames the standardized and USD-converted fees as revenue, maintaining the same calculation logic and values
- **Final calculation**: Revenue equals the sum of all USD-converted token transfers received by the Heliopay fee collection address on each day, excluding internal protocol transfers

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

Helio

Revenue

Revenue

Competitive landscape