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 Revenue Methodology

## 1. Overview

Flashbots revenue represents the direct revenue earned by Flashbots from their MEV (Maximal Extractable Value) relay services. In Token Terminal's methodology, Flashbots revenue is set to zero for all periods, reflecting their business model as infrastructure that facilitates MEV extraction rather than directly monetizing users. While Flashbots processes significant MEV builder payments to validators (tracked separately as fees), these payments flow through to validators rather than being retained as Flashbots revenue.

## 2. Data sources

The calculation relies on several Ethereum data sources:
- **Ethereum beacon chain block data**: Block metadata including fee recipients, transaction counts, and extra data fields from proof-of-stake consensus layer
- **Ethereum mainnet block data**: Execution layer block information including block numbers and transaction counts 
- **Ethereum mainnet transaction data**: Individual transaction records including values, sender/recipient addresses, transaction indices, and timestamps
- **End-of-day token price feeds**: ETH to USD conversion rates for standardizing payment amounts to USD

## 3. Step-by-step calculation

### Component A: Validator payment identification
- **Purpose**: Identify MEV builder payments to validators processed through Flashbots relays
- **Logic**: Join beacon chain blocks with Ethereum mainnet blocks using block numbers to get complete block metadata. For each block, identify the final transaction (with highest `transaction_index` equal to `transaction_count - 1`) as this typically contains the builder payment to the validator. Filter transactions where the `fee_recipient` from the beacon block matches the transaction `from_address`, indicating direct validator payments, or where the `from_address` is one of three specific ultrasound relay addresses: Beaver (`0xa83114a443da1cecefc50368531cace9f37fcccb`), Rsync (`0x0affb0a96fbefaa97dce488dfd97512346cf3ab8`), or Titan (`0x9fc3da866e7df3a1c57ade1a97c9f00a70f010c8`)
- **Key fields**: Extract `block_timestamp`, `fee_recipient`, WETH token address (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`), and transaction `value` converted from wei to ETH by dividing by 10^18

### Component B: Fee aggregation and conversion  
- **Purpose**: Aggregate validator payments by day and convert to USD
- **Logic**: Group the identified validator payments by day using `timestamp_trunc` to daily boundaries. Convert ETH payment amounts to USD using end-of-day price feeds through the `convert_to_usd_and_correct_decimals` macro. Apply the `finalize_metric_fees` macro with zero-fill strategy to ensure consistent daily records and proper schema structure with standard dimension fields like `chain_id` (ethereum), `market_sector_id` (infrastructure), and `business_segment_id` (other)
- **Key fields**: Aggregated daily `fees` amounts in USD, along with standard temporal and dimensional metadata

### Component C: Revenue calculation
- **Purpose**: Generate revenue metric records with zero values
- **Logic**: Reference the fees calculation to obtain the same temporal structure and dimensional data (timestamps, chain identifiers, product classifications) but set the `revenue` field to 0 for all records. This maintains consistency with the fees data structure while explicitly indicating that Flashbots does not retain revenue from the MEV payments they facilitate
- **Key fields**: All dimensional fields from fees calculation (`timestamp`, `timestamp_grain`, `product_id`, `chain_id`) with `revenue` hardcoded to 0

### Final aggregation
- **Combining components**: The revenue metric uses the same temporal and dimensional structure as the fees metric but with revenue values set to zero
- **Currency conversion**: No currency conversion needed since revenue is zero, but maintains USD as the standard currency unit
- **Time aggregation**: Daily aggregation boundaries align with fees calculation using day-truncated timestamps
- **Final calculation**: Revenue equals 0 for all time periods and dimensional combinations, reflecting Flashbots' role as infrastructure that facilitates but does not monetize MEV extraction

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Flashbots

Revenue

Revenue

Competitive landscape