Skip to main content

Overview

Flashbots Auction is a permissionless, transparent, and fair ecosystem for efficient MEV extraction and frontrunning protection which preserves the ideals of Ethereum. Flashbots Auction provides a private communication channel between Ethereum users and validators for efficiently communicating preferred transaction order within a block.

Flashbots Auction started with mev-geth, a patch on top of the go-ethereum client, along with the mev-relay, a transaction bundle relayer.

In PoS Ethereum, the Flashbots Auction is built on mev-boost, an implementation of proposer-builder separation for Ethereum.

Why Flashbots Auction?​

Throughout the second half of 2020 and begining of 2021, a spike in Ethereum usage has revealed a set of negative externalities brought by MEV. These include network congestion (i.e. p2p network load) and chain congestion (i.e. block space usage) caused by inefficient communication between PGA bot operators and (PoW) miners for transaction order preference. These negative externalities create a deadweight loss which is shouldered by regular Ethereum users though high gas price volatility and artificially scarce blockspace.

The incentives around MEV extraction pose an existential risk to Ethereum consensus security due to the incentivization of chain history re-orgs for extraction of past MEV (e.g. through time-bandit attacks) and incentivization of transaction routing centralization for privacy, low latency, and ordering control. These risks are considered to be existential for Ethereum as they undermine the principles of finality and permissionlessness.

We have observed and are concerned about the active development of permissioned and exclusive transaction routing infrastructure as it holds the potential to erode the neutrality, transparency, decentralization, and fairness of Ethereum today. Flashbots Auction is an open-sourced, democratic, and credibly neutral alternative which aims to mitigate the aforementioned negative externalities and existential risks.

Timeline​

How does it work?​

Flashbots Auction provides a private transaction pool + a sealed bid blockspace auction mechanism which allows block proposers (validators; previously "miners" in PoW) to trustlessly outsource the work of finding optimal block construction.

In the regular Ethereum transaction pool, users broadcast transactions to the public peer-to-peer network and specify a gas price which indicates how much they are willing to pay for each unit of computation on the ethereum chain. Block builders receive these transactions, order them by gas price, and use a greedy algorithm to produce a block which attempts to maximise the value received through transaction fees. This mechanism is a mix between an English auction and an all-pay auction where bidding for blockspace is performed in the open, the top bidder captures the opportunity, and all participants incur a cost.

Here are the key issues with this mechanism:

  1. the open nature of the regular transaction pool causes bidding wars for blockspace which create unnecessary p2p network load and volatility in gas prices, as well as disadvantages less sophisticated network participants who do not have access to advanced bidding strategies
  2. the all-pay nature of the auction causes failed bids to revert on chain, thus unnecessarily consuming blockspace and causing bidders to underprice their bids due to execution risk, ultimately leading to artificial blockspace scarcity and lower validator (previously "miner") revenues
  3. the reliance on gasPrice makes it impossible for bidders to express granular ordering preferences as they are restricted to bidding for the top position in the block, this leads to alternative strategies like spam to increase likelihood of winning thus further increasing deadweight loss

Instead, the Flashbots Auction infrastructure uses a first-price sealed-bid auction which allows users to privately communicate their bid and granular transaction order preference without paying for failed bids. This mechanism maximizes validator payoffs, while providing an efficient venue for price discovery on the value of a given MEV opportunity. Crucially, this mechanism eliminates frontrunning vulnerabilities.

Roadmap​

The Flashbots team is taking an iterative approach to decentralizing the Flashbots Auction architecture. As mentioned in our initial ethresearch post, there remain some key research questions to be answered.

Ultimately, the design goals are the following:

  • Pre-trade privacy: implies transactions only become publicly known after they have been included in a block. This excludes intermediaries such as relays & block builders.
  • Failed trade privacy: implies losing bids are never included in a block, thus never exposed to the public.
  • Efficiency: implies MEV extraction is performed without causing unnecessary network or chain congestion.
  • Bundle merging: implies it is possible to merge multiple incoming bundles without conflict.
  • Finality protection: implies it is impractical for Flashbots blocks containing Flashbots bundles to be modified once propagated to the network. This would protect against time-bandit chain re-org attacks.
  • Complete privacy: implies intermediaries like relays and validators cannot observe the content of transactions until included on chain.
  • Permissionless: implies there are no trusted intermediaries which can censor transactions.
StagePGADarkPool⚡🤖 v0.1⚡🤖 v0.2⚡🤖 v0.3⚡🤖 v0.4⚡🤖 v1.0
Pre-trade privacy❌✅✅✅✅✅✅
Failed trade privacy❌❌✅✅✅✅✅
Efficiency❌❌✅✅✅✅✅
Bundle merging❌❌❌✅✅✅✅
Finality protection❌❌❌❌❌❌✅
Complete privacy❌❌❌❌❌❌✅
Permissionless✅❌❌❌❌❌✅

Technical Architecture​

The Flashbots Auction architecture proposes a network with three distinct parties who specialize in performing a subset of the work required for sustaining this communication channel. Block builders are responsible for building full blocks which validators will propose.

Auction Architecture

Flashbots Auction introduces a new eth_sendBundle RPC which standardizes the message format in the communication channel. This message is called a "Flashbots Bundle".

The bundle includes an array of arbitrary signed Ethereum transactions along with some metadata describing under what conditions these transactions should be included.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendBundle",
  "params": [
    {
      txs,               // Array[String], A list of signed transactions to execute in an atomic bundle
      blockNumber,       // String, a hex encoded block number for which this bundle is valid on
      minTimestamp,      // (Optional) Number, the minimum timestamp for which this bundle is valid, in seconds since the unix epoch
      maxTimestamp,      // (Optional) Number, the maximum timestamp for which this bundle is valid, in seconds since the unix epoch
      revertingTxHashes, // (Optional) Array[String], A list of tx hashes that are allowed to revert
    }
  ]
}

Searchers​

Searchers are Ethereum users who, for whatever reason, prefer to use the Flashbots private transaction pool over the regular p2p transaction pool. These users monitor the state of the chain and send bundles to relayers.

Typically, searchers will be one of the following types:

  1. Ethereum bot operators looking for fast, and risk free access to blockspace (for example, arbitrage and liquidation bots)
  2. Ethereum users looking for frontrunning protection on their transactions (for example, Uniswap traders)
  3. Ethereum Dapps with advanced use cases like account abstraction or gasless transactions

Searcher Architecture

Searchers create bundles with information from various sources and send them to a block builder.

By submitting bundles directly to block builders instead of through the p2p network, searchers obtain Pre-trade privacy as their transactions cannot be seen by the rest of the network. The searchers express their bids for inclusion through their Ethereum transactions as either gas price, or direct eth transfer to the coinbase address. Using direct payments instead of gas price allows users to make payments conditional on their transaction succeeding, thus avoiding having to pay for failed bids.

See the searcher quick-start guide to learn how to get started.

Block Builders​

Block builders ("builders") are specialists who accept transactions from users and searchers, and try to build the most profitable block possible from those transactions. These blocks are then sent via an mev-boost relay to validators. See Relays for a deeper explanation of what relays do. Searchers send bundles to one or more builders.

Block Builder Flow

Block builders create blocks using bundles from searchers and transactions (not shown here) from the mempool.

⚠️ Not all builders can be trusted ⚠️

Builders have full view of incoming transactions, which gives them the power to frontrun, censor, etc. When choosing a builder, there are a few criteria to look for:

  • Are they committed to fair and unbiased execution?
    • A good builder will not front-run, sandwich or censor bundles, or otherwise engage in activities that abuse privileged data access.
  • Do they connect to a trusted relay (or relays)?
    • Keep in mind that the relay can also see raw transactions, which gives them the ability to front-run, censor, etc.
  • Do their relays connect to enough validators?
    • The more validators a relay connects to, the more slots will generally be available for builders connected to that relay. When you're targeting a specific block/slot, it's imperative that you send your transactions to a builder which is connected to the validator responsible for proposing a block in that slot. More validators ⇒ better inclusion rates.
    • Note: Any validator can use mev-boost to connect to the Flashbots relay and other relays.
    • It's also worth considering how much collective stake the validators connected to a relay have. Generally speaking, if more than one block is proposed to the network (unusual but possible), the block with the most collective stake attesting to it will be included. This scenario is explained in greater detail in the Ethereum docs.

Also note that block builders have the freedom to specialize. You may find that one builder is more or less friendly to your strategy than others. Builders are competing with each other, so they are all incentivized to include your bundles in their blocks, but you may find that some builders will prioritize certain strategies over others regardless of potential profits. Builders might also censor certain bundles due to local regulations or corporate strategies and policies. There are a lot of variables in play here, so I recommend trying a few trustworthy builders and seeing how your mileage varies first-hand.

Learn more about the trust assumptions of the Flashbots Alpha.

Relays​

Relays are a component of PBS which are responsible for escrowing blocks from builders for validators.

Relay Flow

Relay selects most profitable block from its builders and escrows it for the validator.

With mev-boost, validators choose the most profitable block from a number of relays. Each relay keeps the contents of a block private until the validator commits to proposing it to the network for inclusion.

Specifically, relays do the following:

  • accept new blocks from builders
  • send header of most profitable block to a validator upon request
    • the validator locks in their commitment to propose the full block by signing this header
  • send full block to validator after receiving block header signed by the validator
  • perform all of this quickly and reliably, so that validators don't miss proposal deadlines

For a deeper explanation of mev-boost and relays, Check out @thegostep's ethresear.ch post.

For more information about how bundles are sent post-merge, see this forum post.

Learn more about the trust assumptions of the Flashbots Alpha.

Validators​

Validators (AKA "proposers") in PoS Ethereum are responsible for proposing blocks to the network, and appending blocks to the chain. You can learn more about validators in the Ethereum docs.

Validator Flow

Validator uses mev-boost to choose the most profitable block to propose from multiple relays.

When builders include MEV-yielding transactions, the blocks they produce will be more profitable on average. By sourcing the most profitable blocks from these builders, validators earn more profit just by using mev-boost. You can learn more about mev-boost at boost.flashbots.net.

Learn more about the trust assumptions of the Flashbots Alpha.

Trust Assumptions​

The current version of Flashbots Auction contains technical limitations which prevent the network from operating in a fully trustless manner. Specifically, the properties of complete privacy and permissionlessness are required for Flashbots to be fully decentralized.

In the future, the Flashbots Auction roadmap aims to replace these trust guarantees with cryptographic and cryptoeconomic guarantees of full privacy. We invite privacy researchers and interested community members to review our proposed architecture and contribute to building a more robust and decentralized system.