Liquidity providers deposit funds into Thruster, receive trading fees from traders (supply-side fees).

Thruster is a non-custodial exchange protocol built on Blast. Thruster was launched in 2024.

Thruster team and investors own and govern the protocol. They currently take a cut of the total trading fees paid by traders, and earn native yield (revenue). Thruster's investors include Mirana Ventures, Manifold, OKX Ventures, etc.

twitter

discord

website

Exchanges (DEX)

Thruster

# Thruster Revenue Methodology

## 1. Overview

Thruster revenue represents the total daily revenue generated by the Thruster decentralized exchange on Blast, combining three distinct revenue streams: trading fees from DEX operations, flash loan fees, and native yield distributions from Blast's yield-bearing infrastructure. The metric calculates protocol-level revenue by applying fee rates and protocol fee shares to trading volumes and direct yield claims.

## 2. Data sources

The calculation relies on several types of raw blockchain data and external feeds:

- **DEX trading events**: Parsed `Swap` events from Thruster's classic (v2-style) and CLAMM (v3-style) liquidity pools on Blast, capturing token amount changes for each trade
- **Flash loan events**: Parsed `Flash` events from Thruster's pool contracts, recording borrowed token amounts and associated fees
- **Yield claim events**: Parsed `ClaimYieldAll` events from multiple Thruster contract types, tracking distributions of native Blast yield in WETH, USDB, and Gas tokens
- **Pool configuration data**: Factory contract events including `PairCreated` and `PoolCreated` events that establish trading pairs, fee tiers, and pool parameters
- **Fee configuration updates**: `SetYieldCut` events that modify protocol fee sharing rates over time
- **Transaction records**: Blast transaction data for user address identification and transaction context
- **Token metadata**: Token contract information including decimal places and symbols for proper amount normalization
- **End-of-day price feeds**: Daily USD price data for all tokens involved in trading, flash loans, and yield distributions

## 3. Step-by-step calculation

### Component A: Trading fee revenue
- **Purpose**: Calculate revenue from DEX trading fees based on trading volume and applicable fee rates
- **Logic**: Extract `Swap` events from both classic and CLAMM pool types, capturing the absolute change in token amounts for each trade. Join with trading pair dimension data to obtain fee tier information (typically 0.3% for classic pools, 1% for v1 pools, variable for CLAMM pools). Apply protocol fee tier based on timing logic - before the fee switch activation date of April 10, 2024, protocol fees were 0%; after this date, protocol fees default to 50% (0.5) of total fees, with specific rates determined by `SetYieldCut` events. Convert token amounts to USD using end-of-day price feeds, taking the minimum USD value between `token0_amount` and `token1_amount` to prevent price manipulation. Aggregate daily by product type (`thrusterclassic` or `thrusterclamm`). Calculate revenue as: `trading_volume × fee_tier × protocol_fee_tier`
- **Key fields**: `token0_amount` and `token1_amount` from swap events, `fee_tier` from pool configuration, `protocol_fee_tier` from yield cut settings, `trading_volume` after USD conversion and aggregation

### Component B: Flash loan fee revenue
- **Purpose**: Calculate revenue from flash loan fees based on borrowed amounts and fee rates
- **Logic**: Extract `Pool_Flash_event` data capturing flash loan transactions with borrowed token amounts. Join with the same trading pair configuration to apply consistent fee tiers and protocol fee rates using identical timing logic as trading fees. Convert both `token0_amount` and `token1_amount` to USD using end-of-day price feeds, then sum both values (unlike trading which uses minimum) since flash loans involve borrowing the full amounts of both tokens. Aggregate daily by account and pool. Calculate revenue as: `flash_loan_volume × fee_tier × protocol_fee_tier`
- **Key fields**: `token0_amount` and `token1_amount` from flash events, `fee_tier` from pool configuration, `protocol_fee_tier` from yield cut settings, `flash_loan_volume` as sum of both token USD values

### Component C: Native yield revenue
- **Purpose**: Track direct revenue from Blast's native yield feature distributed to the protocol
- **Logic**: Extract `ClaimYieldAll` events from multiple contract types (Pair03, Pair1, Pool contracts), capturing yield distributions in three token types: WETH (address `0x4300000000000000000000000000000000000004`), USDB (address `0x4300000000000000000000000000000000000003`), and Gas (using WETH address). Aggregate daily claim amounts by account address and token type. Apply decimal correction using token metadata and convert to USD using end-of-day price feeds. The yield claim amounts represent direct protocol revenue without additional fee calculations
- **Key fields**: `amountWETH`, `amountUSDB`, and `amountGas` from claim events, `amount` after decimal correction and USD conversion

### Final aggregation
- **Combining components**: Union all three revenue components (trading fees, flash loan fees, native yield) into a single dataset, with each component tagged by `market_sector_id` ('exchanges'), `business_segment_id` ('dex'), and appropriate `product_id` values ('thrusterclassic', 'thrusterclamm', 'nativeyield')
- **Currency conversion**: All amounts converted to USD using end-of-day price feeds aligned to the same daily timestamp grain as the revenue calculation
- **Time aggregation**: Daily aggregation using timestamp truncation to day boundaries, ensuring consistent time grouping across all components
- **Final calculation**: Apply the `finalize_metric_revenue` macro to ensure proper schema compliance, validate product and segment IDs, and fill any data gaps with zeros using the 'fill_zeros' strategy. Filter results by chain availability to include only supported blockchain networks

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

ThrusterTHRUST

Archived

Revenue

Revenue

Competitive landscape