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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Thruster decentralized exchange. The metric is calculated by dividing total daily revenue by the number of daily active users. This provides insight into user monetization and protocol efficiency on Thruster's AMM-based DEX operating on the Blast blockchain. ARPU combines revenue from trading fees, flash loan fees, and native yield distributions to capture the complete revenue picture per user.

## 2. Data sources

The ARPU calculation relies on several blockchain data sources:

- **Blast blockchain swap events**: Parsed `Swap` events from Thruster's Classic AMM pairs and concentrated liquidity (CLAMM) pools, containing token exchange amounts and user addresses
- **Blast blockchain flash loan events**: Parsed `Flash` events from Thruster pools showing flash loan amounts and borrowers
- **Blast blockchain yield claim events**: Parsed `ClaimYieldAll` events capturing native yield distributions for WETH, USDB, and gas tokens
- **Blast transaction records**: Transaction data providing user addresses (`from_address`) for all protocol interactions
- **Trading pair creation events**: `PairCreated` and `PoolCreated` events from Thruster factory contracts defining valid trading pairs, tokens, and fee tiers
- **Protocol fee configuration events**: `SetYieldCut` events defining protocol fee rates over time
- **End-of-day token price feeds**: USD price data for all tokens to convert trading volumes to dollar values
- **Token metadata**: Decimal precision and symbol information for proper amount normalization

## 3. Step-by-step calculation

### Component A: Trading fee revenue calculation

- **Purpose**: Calculate revenue from DEX trading fees based on swap volumes and fee rates
- **Logic**: Extract `Swap` events from both Thruster Classic AMM pairs (`Pair03_Swap_event`, `Pair1_Swap_event`) and CLAMM pools (`Pool_Swap_event`). For Classic AMM, calculate token amounts as the difference between `amount0In` minus `amount0Out` and `amount1In` minus `amount1Out`. For CLAMM pools, use `amount0` and `amount1` directly. Join with trading pair metadata to get token addresses, decimals, and fee tiers. Normalize token amounts by dividing by 10 raised to the token's decimal precision. Convert both token amounts to USD using end-of-day price feeds, then take the lesser of the two USD values to filter out price manipulation attempts. Multiply the USD trading volume by the fee tier percentage and protocol fee tier to calculate trading fees. The protocol fee tier is 0% before April 10, 2024 (fee switch activation) and varies by pair afterward based on `SetYieldCut` events.
- **Key fields**: `amount0In`, `amount0Out`, `amount1In`, `amount1Out` for Classic AMM; `amount0`, `amount1` for CLAMM; `fee_tier` from pair metadata; `protocol_fee_tier` from yield cut configuration

### Component B: Flash loan fee revenue calculation

- **Purpose**: Calculate revenue from flash loan fees charged on borrowed amounts
- **Logic**: Extract `Flash` events from Thruster pools containing `amount0` and `amount1` borrowed amounts. Join with trading pair metadata to identify token addresses, decimals, and fee tiers. Normalize token amounts using decimal precision and convert to USD values using end-of-day price feeds. Sum both token amounts in USD to get total flash loan volume per transaction. Apply the same fee calculation logic as trading fees: multiply flash loan volume by fee tier and protocol fee tier to determine flash loan revenue.
- **Key fields**: `amount0` and `amount1` for borrowed amounts; `fee_tier` and `protocol_fee_tier` for fee calculation

### Component C: Native yield revenue calculation

- **Purpose**: Capture revenue from Blast's native yield mechanism distributed to Thruster pools
- **Logic**: Extract `ClaimYieldAll` events which distribute native yield in three token types: WETH (`0x4300000000000000000000000000000000000004`), USDB (`0x4300000000000000000000000000000000000003`), and gas tokens. Each event contains `amountWETH`, `amountUSDB`, and `amountGas` fields representing yield distributions. Normalize amounts using token decimals and convert to USD using end-of-day price feeds. These yield claims represent direct revenue to the protocol from Blast's native yield features.
- **Key fields**: `amountWETH`, `amountUSDB`, `amountGas` from yield claim events

### Component D: Daily active users calculation  

- **Purpose**: Count unique users interacting with Thruster protocol daily for the ARPU denominator
- **Logic**: Identify unique user addresses from two sources: trading activity and flash loan activity. For trades, extract the `from_address` from Blast transactions containing `Swap` events. For flash loans, extract the `from_address` from transactions containing `Flash` events. Combine both address sets and count distinct addresses per day using HyperLogLog algorithm for efficient computation. Users are classified as "Trader" type and can be segmented by product (thrusterclassic, thrusterclamm) and chain.
- **Key fields**: `from_address` from transaction data; `block_timestamp` for daily grouping

### Final aggregation

- **Combining components**: Sum all revenue sources (trading fees + flash loan fees + native yield claims) by day to get total daily revenue. Count distinct active users by day to get daily active user totals.
- **Currency conversion**: All token amounts are converted to USD using end-of-day price feeds matched by token address, chain, and timestamp. Decimal normalization occurs before USD conversion.
- **Time aggregation**: All data is aggregated using daily boundaries via `timestamp_trunc(block_timestamp, day)` to align revenue and user counts to the same time periods.
- **Final calculation**: ARPU is calculated as Total Daily Revenue divided by Daily Active Users. The calculation handles cases where user count is zero to avoid division errors, and applies a fill strategy to populate missing days with zero values for consistent time series data.

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

ThrusterTHRUST

Archived

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape