Ethereum validators use MEV-boost to outsource their block construction to a marketplace of relays and builders, including the Flashbots Builders. This dashboard only captures metrics about the Flashbots Builders.

Flashbots is a research and development organization formed to mitigate the negative externalities posed by Maximal Extractable Value (MEV) to stateful blockchains, starting with Ethereum. Flashbots operates a block builder and an MEV-boost relay on Ethereum.

The Flashbots team and investors own the Flashbots Builder. Currently, Flashbots does not take a cut of the fees paid by searchers. Flashbots' investors include Paradigm, among others.

governance

github

discord

etherscan

website

Infrastructure

Flashbots

# Flashbots Active users (weekly) Methodology

## 1. Overview

The Flashbots Weekly Active Users (WAU) metric measures the number of unique validator fee recipients that received builder payments within a 7-day rolling window. This metric tracks ecosystem participation in the Ethereum MEV (Maximal Extractable Value) supply chain by counting distinct validators who received payments from block builders through the Flashbots infrastructure. The calculation uses HyperLogLog sketches for efficient approximate distinct counting and provides dimensional breakdowns by chain, user type, and product.

## 2. Data sources

The metric relies on three core Ethereum blockchain data sources:

- **Ethereum beacon chain blocks**: Beacon chain block data containing fee recipient addresses, transaction counts, and extra data fields that identify the validator receiving block rewards
- **Ethereum mainnet blocks**: Execution layer block data providing block numbers, transaction counts, and block metadata for correlation with beacon chain data  
- **Ethereum mainnet transactions**: Individual transaction records including block timestamps, transaction hashes, value transfers, sender/receiver addresses, and transaction indices within blocks

## 3. Step-by-step calculation

### Component A: Validator payment identification
- **Purpose**: Identifies transactions that represent builder payments to validators in the MEV supply chain
- **Logic**: Combines beacon chain blocks with mainnet blocks and transactions by matching block numbers. Focuses specifically on the last transaction within each block (highest `transaction_index`) as these typically represent builder payments to fee recipients. Applies special handling for Ultrasound relay payments by filtering for transactions where the `fee_recipient` equals the `from_address`, or where the sender is one of the known Ultrasound relay addresses (beaver, rsync, or titan variants). Converts payment values from Wei to WETH denomination by dividing by 10^18.
- **Key fields**: `block_timestamp`, `fee_recipient` (validator address), `value` (payment amount), `from_address`, `transaction_index`

### Component B: User classification and daily aggregation  
- **Purpose**: Classifies fee recipients as users and aggregates them into daily distinct counts
- **Logic**: Takes validator fee recipients from payment transactions and classifies them as 'builder' type users in the 'infrastructure' market sector with 'other' business segment. All activity is attributed to the 'ethereum' chain. Aggregates users by truncating timestamps to daily boundaries and calculating distinct user addresses per day using the user address as the distinct identifier.
- **Key fields**: `user_address` (fee recipient), `chain` (ethereum), `user_type` (builder), `block_timestamp` truncated to day

### Component C: HyperLogLog sketch generation
- **Purpose**: Creates efficient approximate distinct count data structures for the daily user data
- **Logic**: Transforms the daily distinct users into HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. Groups data by timestamp, timestamp grain (day), chain, user type, and product dimensions to create HLL sketches that can be efficiently merged for rolling window calculations.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp_grain` (day), dimensional grouping fields

### Component D: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for each timestamp to calculate weekly active users
- **Logic**: Generates a continuous datespine of daily timestamps from the earliest available data to yesterday. For each timestamp in the datespine, creates a 7-day lookback window by generating timestamps from 6 days prior through the current day. Joins this window structure with the daily HLL sketches to create a dataset where each row represents one day's HLL sketch within a 7-day window for a specific timestamp.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within window), dimensional breakdowns

### Component E: Dimensional WAU calculation
- **Purpose**: Calculates WAU across multiple dimensional breakdowns
- **Logic**: Merges HLL sketches within each 7-day window using `hll_count.merge_partial` to combine daily sketches, then extracts the final distinct count using `hll_count.extract`. Creates separate dimensional views: project-level (all dimensions null), chain-level (ethereum), user type-level (builder), and product-level (null since no product differentiation). Each breakdown groups by the relevant dimensions while nullifying others.
- **Key fields**: `user_wau` (final weekly active user count), `dimensions` (breakdown type), dimensional identifier fields

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project, chain, user_type, product_id) into a single result set with standardized schema
- **Currency conversion**: Not applicable - this metric counts users rather than monetary values
- **Time aggregation**: Uses 7-day rolling windows with daily granularity, where each day represents the count of unique users active in the preceding 7-day period
- **Final calculation**: The final WAU value represents the approximate distinct count of fee recipient addresses that received builder payments within any 7-day rolling window, calculated by merging HyperLogLog sketches and extracting the distinct count estimate

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

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

Flashbots

Active users (weekly)

Active users (weekly)

Competitive landscape