website

twitter

Infrastructure

SolTradingBot

# SolTradingBot Revenue Methodology

## 1. Overview

The soltradingbot revenue metric measures the total fees collected by the soltradingbot protocol on Solana, expressed in USD. This metric captures the protocol's revenue generation by tracking native SOL transfers to designated fee collection addresses. The calculation identifies fee payments from users to the protocol and aggregates them daily, providing insight into the protocol's revenue performance and user activity levels.

## 2. Data sources

- **Solana native transfers**: Native SOL transfer records showing sender, recipient, amount, and transaction details
- **End-of-day price feeds**: Daily closing prices for SOL token to enable USD conversion
- **Token metadata**: Protocol-specific information including designated fee collection addresses

## 3. Step-by-step calculation

### Component A: Fee collection identification
- **Purpose**: Identify and extract fee payments made to the soltradingbot protocol
- **Logic**: Filter Solana native transfers to capture only those sent to two specific fee collection addresses: `F34kcgMgCF7mYWkwLN3WN7KrFprr2NbwxuLvXx4fbztj` and `96aFQc9qyqpjMfqdUeurZVYRrrwPJG2uPV6pceu4B1yb`. Exclude transfers where the transaction signer is one of these fee addresses to avoid counting internal protocol transfers or refunds. Each qualifying transfer represents a fee payment from a user to the protocol.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as the fee payer, `amount` in lamports (native SOL units), and `to_address` for fee collection address validation

### Component B: Daily aggregation and unit conversion
- **Purpose**: Aggregate fee collections by day and convert from native units to standard SOL denomination
- **Logic**: Group all qualifying transfers by day using timestamp truncation to daily boundaries. Sum the total `amount` values for each day and convert from lamports to SOL by dividing by 1,000,000,000 (1e9), as there are 1 billion lamports per SOL. This produces daily total fees collected in SOL units.
- **Key fields**: `timestamp` truncated to day granularity, `fees` as the aggregated SOL amount, `chain_id` as 'solana', and `token_address` as the native SOL token identifier

### Component C: USD conversion
- **Purpose**: Convert SOL-denominated fees to USD values for standardized reporting
- **Logic**: Apply end-of-day price feeds to convert each day's SOL fee total to USD equivalent. Use the closing price for SOL on each respective day to ensure consistent valuation timing. The conversion maintains the same daily granularity while expressing values in USD for cross-protocol comparison.
- **Key fields**: `fees` converted to USD amounts using daily SOL closing prices

### Final aggregation
- **Combining components**: The revenue metric directly maps from the USD-converted fees without additional aggregation, as revenue equals fees collected for this protocol
- **Currency conversion**: Uses end-of-day SOL price feeds to convert native token amounts to USD at daily closing prices
- **Time aggregation**: Maintains daily boundaries with timestamp truncation to day granularity, ensuring consistent daily reporting periods
- **Final calculation**: Revenue equals the sum of all SOL fee payments to designated collection addresses on each day, converted to USD using end-of-day prices, with standardized schema formatting and zero-fill strategy for missing data points

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

SolTradingBotSTBOT

Revenue

Revenue

Competitive landscape