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 Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique user addresses that interact with the Thruster protocol within any 7-day rolling window. This metric captures user engagement across both trading activities (swaps on Classic and CLAMM AMMs) and flash loan usage. The calculation uses HyperLogLog probabilistic data structures to efficiently compute distinct user counts across rolling 7-day periods, providing multiple dimensional breakdowns including project-level, chain-level, user-type-level, and product-level aggregations.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Blast transaction records**: Transaction metadata including user addresses (`from_address`) who initiated blockchain transactions
- **Thruster Classic swap events**: Parsed `Pair03_Swap_event` and `Pair1_Swap_event` logs from Thruster's V2-style AMM pairs, containing swap amounts and contract addresses
- **Thruster CLAMM swap events**: Parsed `Pool_Swap_event` logs from Thruster's concentrated liquidity AMM pools, containing swap amounts and pool addresses  
- **Thruster flash loan events**: Parsed `Pool_Flash_event` logs capturing flash loan transactions with borrower addresses and loan amounts

## 3. Step-by-step calculation

### Component A: Trade activity extraction

- **Purpose**: Identify all users who executed swaps on Thruster's AMM protocols
- **Logic**: Extract swap events from both Thruster Classic (V2-style pairs) and Thruster CLAMM (V3-style pools) on the Blast chain. For Classic swaps, calculate net token amount changes by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For CLAMM swaps, directly use the `amount0` and `amount1` fields. Join swap event logs with Blast transaction records using `transaction_hash` to resolve the actual user address from the transaction's `from_address` field. Categorize all swap interactions under the 'dex' business segment with product IDs 'thrusterclassic' or 'thrusterclamm' respectively.
- **Key fields**: `user_address` (resolved from transaction records), `block_timestamp` (for daily aggregation), `product_id` (thrusterclassic/thrusterclamm), `chain_id` (blast)

### Component B: Flash loan activity extraction

- **Purpose**: Identify all users who utilized Thruster's flash loan functionality  
- **Logic**: Extract flash loan events from `Pool_Flash_event` logs on the Blast chain. Join flash loan event logs with Blast transaction records using `transaction_hash` to resolve the actual user address from the transaction's `from_address` field. Capture flash loan amounts for both tokens in the liquidity pair. Categorize flash loan interactions under the 'dex' business segment within the 'exchanges' market sector.
- **Key fields**: `user_address` (resolved from transaction records), `block_timestamp` (for daily aggregation), `token0_amount` and `token1_amount` (flash loan sizes)

### Component C: Daily active users calculation

- **Purpose**: Create daily distinct user counts combining all Thruster protocol interactions
- **Logic**: Combine trading and flash loan activities using union distinct operation to ensure users appearing in both activities on the same day are counted only once. Truncate all `block_timestamp` values to daily boundaries using timestamp truncation. Classify all users as 'Trader' type regardless of their specific activity (swaps or flash loans). Apply chain availability filtering to ensure data quality. Preserve dimensional attributes including `chain_id`, `product_id`, `market_sector_id`, and `business_segment_id` for downstream aggregations.
- **Key fields**: `user_dau` (distinct user addresses per day), `timestamp` (daily boundaries), `user_type` (always 'Trader'), dimensional breakdown fields

### Component D: HyperLogLog initialization  

- **Purpose**: Convert daily user sets into probabilistic data structures for efficient weekly aggregation
- **Logic**: Initialize HyperLogLog sketches from daily active user data with 15-bit precision to balance memory efficiency with accuracy. Group by timestamp, timestamp grain, chain, user type, and product ID. Create HLL sketches that can be efficiently merged across time periods while maintaining distinct count accuracy.
- **Key fields**: `hll` (HyperLogLog sketch of user addresses), grouping dimensions for aggregation

### Component E: Rolling window creation

- **Purpose**: Generate 7-day sliding windows for weekly active user calculations
- **Logic**: Create a continuous date spine covering the full date range from the earliest available data to yesterday. For each day in the date spine, generate a 7-day array including the current day plus the previous 6 days using timestamp array generation. Join this windowed date structure with the HLL daily data to ensure complete coverage and prevent gaps in rolling calculations.
- **Key fields**: `timestamp` (calculation day), `joinday` (days within the 7-day window), `hll` (daily HLL sketches)

### Component F: Weekly aggregation by dimensions

- **Purpose**: Calculate weekly active users across multiple dimensional breakdowns
- **Logic**: Merge HLL sketches across each 7-day rolling window and extract final distinct user counts. Create four separate dimensional views: project-level aggregation (all dimension fields null), chain-level aggregation (grouped by `chain_id`), user-type-level aggregation (grouped by `user_type`), and product-level aggregation (grouped by `product_id`). For each breakdown, merge partial HLL sketches using HLL merge functions and extract the final distinct count representing weekly active users.
- **Key fields**: `user_wau` (weekly active user count), `dimensions` (breakdown type identifier), dimension-specific grouping fields

### Final aggregation

- **Combining components**: Union all dimensional breakdowns (project-level, chain-level, user-type-level, and product-level) into a single result set with consistent schema
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows calculated daily, where each day's WAU represents unique users from that day plus the previous 6 days
- **Final calculation**: Extract distinct user counts from merged HyperLogLog sketches across 7-day windows, apply standardized metric schema formatting, and fill any missing days with zero values to ensure continuous time series data

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

Unique revenue-generating users over a rolling 7-day window.

ThrusterTHRUST

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape