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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average revenue generated per active user on the Flashbots platform. This metric is calculated by dividing total revenue by the number of daily active users. In the current implementation, revenue is set to zero across all dimensions, making the ARPU effectively zero. The metric tracks validator fee recipients who interact with Flashbots builders as the user base.

## 2. Data sources

The calculation relies on several blockchain data sources:
- **Ethereum beacon chain blocks**: Beacon chain block data containing fee recipients, transaction counts, and extra data fields
- **Ethereum mainnet blocks**: Ethereum execution layer blocks with block numbers and transaction counts
- **Ethereum mainnet transactions**: Individual Ethereum transactions including timestamps, values, addresses, and transaction indices
- **Hardcoded relay addresses**: Specific addresses for Ultrasound relay variants (Beaver, Rsync, Titan) used for bid adjustment identification
- **Token constants**: WETH contract address used for fee denomination

## 3. Step-by-step calculation

### Component A: Validator payment identification
- **Purpose**: Identifies payments made by Flashbots builders to validators
- **Logic**: Joins beacon chain blocks with Ethereum execution blocks on `block_number`, then matches with Ethereum transactions. Filters to include only the last transaction in each block by matching `transaction_index` with `transaction_count - 1`. This captures the builder payment transaction which typically occurs at the end of the block. Additional filtering includes transactions where the `fee_recipient` equals the transaction `from_address`, or where the `from_address` matches specific Ultrasound relay addresses (Beaver, Rsync, Titan)
- **Key fields**: `block_timestamp` for daily aggregation, `fee_recipient` as user identifier, `value` for payment amounts, `token_address` set to WETH address

### Component B: Fee calculation and conversion
- **Purpose**: Converts raw payment values to standardized fee amounts
- **Logic**: Takes the transaction `value` field and divides by 10^18 to convert from wei to ETH denomination. Associates all fees with the WETH token address. Applies daily timestamp truncation for aggregation boundaries
- **Key fields**: `fees` as the converted payment amount, `block_timestamp` truncated to day level, `token_address` for WETH

### Component C: Daily active user calculation
- **Purpose**: Counts distinct validator fee recipients per day
- **Logic**: Aggregates the validator payment data by truncating `block_timestamp` to day boundaries. Uses HyperLogLog algorithm to count distinct `user_address` values (fee recipients). Categorizes all users as `builder` type within the `infrastructure` market sector. Applies chain availability filters to ensure data completeness
- **Key fields**: `user_dau` as the distinct user count, `timestamp` at daily granularity, `chain` set to ethereum

### Component D: Revenue calculation
- **Purpose**: Calculates total revenue from all sources
- **Logic**: Takes fee data and sets revenue to zero across all dimensions including `product_id`, `chain_id`, and time periods. Uses the same timestamp and dimensional structure as the fee calculation but hardcodes revenue values to 0
- **Key fields**: `revenue` hardcoded to 0, `timestamp` at daily grain, dimensional breakdowns

### Final aggregation
- **Combining components**: The ARPU macro combines the daily active user count with revenue data by matching on timestamp and dimensional attributes
- **Currency conversion**: Not applicable since revenue is set to zero
- **Time aggregation**: Both components use daily timestamp truncation to ensure alignment
- **Final calculation**: Applies the formula ARPU = revenue / daily_active_users. Since revenue is hardcoded to 0, the resulting ARPU is 0 for all time periods and dimensional breakdowns. The calculation includes data validation and gap-filling strategies using the `fill_zeros` approach

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

Flashbots

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape