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

## 1. Overview

The Flashbots Monthly Active Users (MAU) metric measures the count of unique validator fee recipients who received builder payments over a rolling 30-day period. This metric tracks adoption and usage of the Flashbots builder infrastructure by Ethereum validators. The calculation uses a rolling window approach with HyperLogLog (HLL) sketching for efficient distinct counting and provides breakdowns across multiple dimensions including chain, user type, and product levels.

## 2. Data sources

The metric is built from the following raw data sources:

- **Ethereum beacon chain blocks**: Beacon chain block data containing `fee_recipient`, `transaction_count`, and `extra_data` fields for identifying validator payment information
- **Ethereum mainnet blocks**: Ethereum execution layer block data with block numbers and transaction counts for cross-referencing with beacon chain data
- **Ethereum transaction data**: Complete Ethereum transaction records including `block_timestamp`, `transaction_hash`, `value`, `from_address`, `to_address`, `input`, and `transaction_index` for identifying builder payment transactions
- **Token metadata**: WETH contract address and decimal information for payment value calculations

## 3. Step-by-step calculation

### Component A: Ethereum block data extraction
- **Purpose**: Extracts and joins beacon chain and execution layer block information to establish the foundation for identifying validator payments
- **Logic**: Combines beacon chain blocks data (containing fee recipient and transaction count information) with Ethereum mainnet blocks data (containing block numbers and transaction counts) to create a unified view of block-level information. The beacon chain data provides the validator fee recipient addresses while the mainnet data confirms transaction counts for payment identification.
- **Key fields**: `block_number`, `fee_recipient`, `transaction_count`, `extra_data`

### Component B: Transaction data processing  
- **Purpose**: Processes Ethereum transaction data to identify relevant payment transactions within blocks
- **Logic**: Extracts transaction data including timestamps, block numbers, transaction hashes, values, sender and recipient addresses, input data, and transaction indices. Applies incremental processing logic to handle only new or recently modified transactions, using partition-based filtering on `block_timestamp` to optimize processing.
- **Key fields**: `block_timestamp`, `transaction_hash`, `value`, `from_address`, `to_address`, `transaction_index`

### Component C: Validator payment identification
- **Purpose**: Identifies valid Flashbots builder payments to validators by matching specific transaction patterns
- **Logic**: Joins block data with transaction data to identify builder payment transactions. Focuses on the last transaction in each block (where `transaction_index` equals `transaction_count - 1`) as this is typically where validator payments occur. Filters for valid payments where the fee recipient matches the transaction sender address, or where the sender is one of specific ultrasound relay addresses (`0xa83114a443da1cecefc50368531cace9f37fcccb`, `0x0affb0a96fbefaa97dce488dfd97512346cf3ab8`, `0x9fc3da866e7df3a1c57ade1a97c9f00a70f010c8`). Converts payment values from Wei to ETH by dividing by 10^18.
- **Key fields**: `fee_recipient`, `value` (converted to ETH), `from_address`, `to_address`

### Component D: User classification
- **Purpose**: Classifies fee recipients as Flashbots users with appropriate categorization
- **Logic**: Takes validator payment data and classifies each `fee_recipient` address as a user. Assigns `user_type` as 'builder', `market_sector_id` as 'infrastructure', `business_segment_id` as 'other', sets `chain` as 'ethereum', and leaves `product_id` as null. Each fee recipient represents a unique user address in the Flashbots ecosystem.
- **Key fields**: `user_address` (fee recipient), `user_type`, `chain`, `block_timestamp`

### Component E: Daily active user calculation
- **Purpose**: Calculates daily active users by counting distinct fee recipients per day
- **Logic**: Groups user data by day using `timestamp_trunc` on `block_timestamp` to create daily boundaries. Counts distinct `user_address` values for each day, creating a daily active user (DAU) dataset. Maintains dimensional breakdowns by `chain`, `user_type`, and `product_id` for downstream aggregation flexibility.
- **Key fields**: `timestamp` (daily), `user_dau` (distinct user address), `timestamp_grain`, `chain`, `user_type`, `product_id`

### Component F: HyperLogLog preparation
- **Purpose**: Converts daily user counts into HyperLogLog sketches for memory-efficient distinct counting across time windows
- **Logic**: Takes the DAU data and applies HyperLogLog initialization using `hll_count.init` with precision parameter 15. This creates compact probabilistic data structures that allow efficient merging across time periods without storing individual user addresses. Groups data by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component G: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation using datespine methodology
- **Logic**: Constructs a datespine covering all days from the minimum timestamp in the DAU data to yesterday. Creates join relationships using `generate_timestamp_array` to produce 30-day windows, where each day is associated with the 30 days leading up to it (including itself). Uses an inner join between the datespine and a joinday array that spans from 29 days before each timestamp to the timestamp itself.
- **Key fields**: `timestamp` (end of window), `joinday` (individual days within window)

### Component H: Window aggregation with HLL
- **Purpose**: Aggregates HyperLogLog sketches across each 30-day window to calculate monthly active users
- **Logic**: Joins the rolling window structure with daily HLL data, matching on joinday to timestamp relationships. For each 30-day window endpoint, collects all HLL sketches from the constituent days. Groups by window endpoint and dimensional attributes, then merges HLL sketches using `hll_count.merge_partial` and extracts final distinct counts using `hll_count.extract`.
- **Key fields**: `hll` (merged across window), `timestamp` (window endpoint)

### Component I: Dimensional breakdowns
- **Purpose**: Creates multiple dimensional views of MAU data for different analysis perspectives
- **Logic**: Generates four separate dimensional breakdowns from the windowed data: project-level (aggregated across all dimensions), chain-level (grouped by chain), user-type-level (grouped by user type), and product-level (grouped by product). Each breakdown applies HLL merging and extraction to calculate the distinct user count for that dimensional view. Uses `safe_cast(null as string)` to standardize non-relevant dimensional columns.
- **Key fields**: `dimensions` (breakdown type), `user_mau` (distinct count), dimension-specific fields

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project-level, chain-level, user-type-level, product-level) into a single result set using `union all` operations
- **Currency conversion**: Payment values are converted from Wei to ETH during validator payment processing, with WETH token address (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`) used as reference
- **Time aggregation**: Uses daily boundaries for base calculations, then applies 30-day rolling windows for MAU calculation. Window endpoints align to daily boundaries, with each MAU value representing the distinct users active in the trailing 30-day period
- **Final calculation**: The final MAU value for each dimension and time period represents the HyperLogLog-estimated count of distinct fee recipient addresses that received Flashbots builder payments within the 30-day trailing window, providing an approximation of unique validators using Flashbots infrastructure

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

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

Flashbots

Active users (monthly)

Active users (monthly)

Competitive landscape