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 (monthly) Methodology

## 1. Overview

Thruster monthly active users (MAU) measures the number of distinct users who interact with the Thruster decentralized exchange over a 30-day rolling window. The metric captures users who perform trading activities (both classic AMM swaps and concentrated liquidity swaps) or use flash loans on the platform. The calculation uses HyperLogLog (HLL) sketches for memory-efficient distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following blockchain data sources:
- **Thruster V1 swap events**: Parsed `Swap` events from Thruster V1 classic AMM pairs (`Pair03_Swap_event` and `Pair1_Swap_event`) and concentrated liquidity pools (`Pool_Swap_event`) on the Blast network
- **Thruster V1 flash loan events**: Parsed `Flash` events from Thruster V1 pools (`Pool_Flash_event`) on the Blast network  
- **Blast transaction records**: Transaction data from the Blast network used to identify user addresses who initiated the transactions
- **Event log data**: Smart contract event logs containing transaction details, token amounts, and contract addresses

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Identifies all trading activity on Thruster's classic AMM and concentrated liquidity products
- **Logic**: Extracts swap events from multiple Thruster V1 contract types on Blast network. For classic AMM pairs (`Pair03_Swap_event` and `Pair1_Swap_event`), calculates net token amounts by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For concentrated liquidity pools (`Pool_Swap_event`), uses `amount0` and `amount1` directly. Each event is classified with product_id as either 'thrusterclassic' or 'thrusterclamm' and categorized under 'exchanges' market sector and 'dex' business segment.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for event identification, `address` as contract address, `sender` as contract user address, and token amounts for trade size tracking

### Component B: Flash loan event extraction  
- **Purpose**: Captures users who utilize Thruster's flash loan functionality
- **Logic**: Extracts flash loan events from Thruster V1 pool contracts (`Pool_Flash_event`) on Blast network. Events include the borrower address (`sender`) and borrowed amounts for both tokens (`amount0` and `amount1`). All flash loan activity is categorized under 'exchanges' market sector and 'dex' business segment with null product_id.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `sender` as contract user address, and `amount0`/`amount1` as borrowed token amounts

### Component C: User address resolution
- **Purpose**: Identifies the actual user addresses who initiated the transactions rather than contract addresses
- **Logic**: Joins both trade and flash loan events with Blast transaction records using `transaction_hash`. Extracts the `from_address` field from transactions as the true user address, which represents the externally owned account that initiated the transaction. This ensures user counting captures end users rather than intermediate smart contracts.
- **Key fields**: `from_address` as the resolved user address, `transaction_hash` for joining events to transactions

### Component D: Daily user aggregation
- **Purpose**: Creates daily distinct active user counts across multiple dimensions
- **Logic**: Groups all user activity by `timestamp_trunc(block_timestamp, day)` to create daily boundaries. Combines users from both trading and flash loan activities using `union distinct` to avoid double-counting users who perform multiple activity types on the same day. All users are classified as 'Trader' type regardless of activity. Maintains dimensional attributes including `chain_id`, `product_id`, `market_sector_id`, and `business_segment_id` for breakdown analysis.
- **Key fields**: `timestamp` (daily), `timestamp_grain` ('day'), `chain_id`, `user_type` ('Trader'), `product_id`, and `user_address` as the distinct user identifier

### Component E: HLL sketch creation
- **Purpose**: Converts daily user lists into HyperLogLog sketches for efficient set operations
- **Logic**: Groups daily user data by timestamp, chain, user type, and product dimensions. Uses `hll_count.init(user_dau, 15)` to create HLL sketches with precision 15 from daily user address lists. This enables memory-efficient distinct counting when merging across time windows without storing complete user lists.
- **Key fields**: `hll` sketches containing encoded user sets, maintaining all dimensional grouping fields

### Component F: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation using a datespine approach
- **Logic**: Generates a complete datespine from the minimum date in the data to yesterday using `generate_timestamp_array` with daily intervals. For each date, creates joins to the previous 29 days using `unnest(generate_timestamp_array(timestamp_sub(datespine.timestamp, interval 29 day), timestamp, interval 1 day))`. Joins this expanded datespine with daily HLL sketches to ensure complete 30-day windows even when some days have no activity.
- **Key fields**: `timestamp` as the window end date, `joinday` for the 30 days within each window, and `hll` sketches for each day in the window

### Component G: MAU calculation across dimensions
- **Purpose**: Computes monthly active users across multiple dimensional breakdowns
- **Logic**: Creates four separate dimensional views by grouping the 30-day windowed data differently. For each dimension (project_dbt_tag, chain, user_type, product_id), merges HLL sketches across the 30-day window using `hll_count.merge_partial(hll)` and extracts the final distinct count with `hll_count.extract`. Sets non-relevant dimensional fields to null for each breakdown to maintain consistent schema.
- **Key fields**: `dimensions` field indicating the breakdown type, dimensional identifier fields, and `user_mau` as the final monthly active user count

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project_dbt_tag-level, chain-level, user_type-level, and product_id-level) into a single result set using `union all`
- **Time aggregation**: Uses 30-day rolling windows where each day represents the MAU for the current day plus the previous 29 days, providing a continuously updated monthly view
- **Final calculation**: The metric value is the distinct count of users extracted from merged HLL sketches, representing unique users who performed any Thruster activity (trading or flash loans) within the 30-day window
- **Schema standardization**: Applies the `finalize_metric_user_mau` macro with 'fill_zeros' strategy to standardize the output schema and fill missing days with zero values

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

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

ThrusterTHRUST

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape