Blast batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense). Bridge depositors deposit ETH or stablecoins to Blast and receive a yield from ETH staking or T-bill strategies.

Blast is an L2 smart contract platform for decentralized applications on Ethereum. Blast has an inherent yield generation mechanism, coming from ETH staking and RWA protocols. Blast was founded by Pacman and launched in 2023.

Blast team and investors currently own and govern the protocol. Blast's investors include Paradigm, Standard Crypto, Santiago, etc.

twitter

discord

website

Blockchains (L2)

Blast

# Blast Active users (weekly) Methodology

## 1. Overview

Blast weekly active users (WAU) measures the number of unique users who initiated at least one transaction on the Blast blockchain within a rolling 7-day window. This metric uses probabilistic counting with HyperLogLog sketches to efficiently calculate unique user counts across overlapping time windows. The metric provides breakdowns by different dimensions including overall project level, chain, user type, and product to enable comprehensive analysis of user engagement patterns.

## 2. Data sources

- **Blast blockchain transactions**: Complete transaction records from the Blast blockchain including sender addresses, timestamps, and transaction metadata
- **Table metadata**: Incremental processing metadata to optimize query performance and ensure data freshness

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identify unique users active each day as the foundation for WAU calculation
- **Logic**: Extract distinct transaction sender addresses from Blast blockchain transactions, grouping by day. Each unique `from_address` that sent at least one transaction on a given day is counted as a daily active user. Users are classified as "Transaction sender" type and assigned to the "blockchains_l2" market sector and "blockchain" business segment. Timestamps are truncated to day boundaries to ensure proper daily grouping.
- **Key fields**: `from_address` as user identifier, `block_timestamp` truncated to day level, static classification fields for user categorization

### Component B: HyperLogLog initialization for efficient counting
- **Purpose**: Convert daily user sets into probabilistic data structures for efficient set operations
- **Logic**: Transform the daily active user data into HyperLogLog (HLL) sketches using `hll_count.init` with 15-bit precision. This allows for efficient counting of unique users across overlapping time windows without storing actual user addresses. Each day's user set becomes an HLL sketch that can be merged with other sketches to count unique users across multiple days.
- **Key fields**: `hll` containing the HyperLogLog sketch, maintaining dimensional grouping by chain, user type, and product

### Component C: Continuous date spine creation
- **Purpose**: Ensure complete time series coverage without gaps for rolling window calculation
- **Logic**: Generate a continuous sequence of daily timestamps from the earliest available data through yesterday using `generate_timestamp_array`. This datespine ensures that WAU is calculated for every day, even when no transactions occurred on specific dates. For incremental processing, the date range is optimized based on the last modification time with appropriate lookback periods.
- **Key fields**: `timestamp` representing each calendar day in the analysis period

### Component D: Rolling 7-day window construction
- **Purpose**: Create overlapping 7-day periods for each date to capture weekly active users
- **Logic**: For each date in the datespine, generate a 7-day lookback window using `generate_timestamp_array` from 6 days prior through the current date. This creates overlapping windows where each date has its own 7-day period. The windows are structured to join with the daily HLL data, allowing aggregation of unique users across each 7-day period.
- **Key fields**: `timestamp` for the reporting date, `joinday` for each day within the 7-day window

### Component E: Window aggregation with HLL merging
- **Purpose**: Combine daily user data across 7-day windows while maintaining dimensional breakdowns
- **Logic**: Join the rolling windows with the daily HLL sketches, matching on the specific days within each window. This creates a dataset where each row represents a day within a 7-day window, preserving the HLL sketches and dimensional attributes (chain, user type, product). Incremental processing filters ensure only necessary data is processed based on modification timestamps.
- **Key fields**: Reporting `timestamp`, dimensional grouping fields, and `hll` sketches ready for merging

### Component F: Dimensional breakdown calculations
- **Purpose**: Calculate WAU at different analytical granularities
- **Logic**: Process the windowed data through four separate dimensional aggregations:
  1. **Project level**: Aggregate all users regardless of chain, user type, or product to get overall project WAU
  2. **Chain level**: Group by chain identifier to show WAU per blockchain
  3. **User type level**: Group by user type to separate different categories of users
  4. **Product level**: Group by product identifier for product-specific analysis
  
  Each breakdown uses `hll_count.merge_partial` to combine HLL sketches within each group, then `hll_count.extract` to get the final unique user count. Unused dimensions are set to null in each breakdown.
- **Key fields**: `user_wau` containing the final unique user count, dimensional identifier fields, `dimensions` indicating the breakdown type

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using `UNION ALL` to create a comprehensive dataset with multiple analytical views of the same underlying WAU data
- **Currency conversion**: Not applicable for user counting metrics
- **Time aggregation**: Daily reporting with each date representing the count of unique users active in the 7-day window ending on that date
- **Final calculation**: The `finalize_metric_user_wau` macro applies standard schema formatting, fills missing dates with zero values, and ensures consistent output structure across all Token Terminal user metrics

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

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

BlastBLAST

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown