Flashbots

• Name: Flashbots
• URL: https://www.flashbots.net/
• Category: MEV research and execution infrastructure / block-production supply-chain middleware / transaction protection / builder-market infrastructure
• Tags: ethereum-ecosystem
• Summary: Flashbots is best kept as the umbrella project-family note for the public-facing Flashbots stack: MEV-Boost, Protect, BuilderNet, and adjacent builder / relay infrastructure. Its primary-source surface is much broader than a single relay or research paper, spanning validator-side middleware, user-facing private-orderflow protection, block-building infrastructure, and open research. The separate entity / operator boundary now lives in flashbots, which is the cleaner place to reason about hosted services, onboarding policy, BuilderNet infrastructure control, and the legal operating shell.
• What it does:
  • Builds MEV-Boost and related relay/builder infrastructure so Ethereum validators can access competitive block-building markets via out-of-protocol proposer-builder separation
  • Operates Flashbots Protect, a private transaction RPC that hides order flow from frontrunning/sandwich bots and offers MEV and gas-fee refund mechanisms
  • Maintains newer block-building infrastructure such as BuilderNet, rbuilder, and Rollup-Boost, extending the project beyond a single Ethereum relay into broader execution-layer infrastructure
  • Publishes open MEV research, Flashbots Research Proposals (FRPs), grants, and a public forum to shape protocol design and market structure around MEV
  • Maintains a large open-source GitHub surface that spans user protection, validator middleware, builder tooling, research, and coordination artifacts
• Key claims:
  • The official site and docs say Flashbots was formed to mitigate the negative externalities posed by MEV and organizes its work around three goals: Illuminate, Democratize, and Distribute
  • The docs explicitly segment Flashbots’ live operating surface across searchers, Ethereum users, and validators/builders/relayers, which is a strong signal that the project should be cataloged as ecosystem infrastructure rather than a single-product protocol
  • The MEV-Boost docs describe open-source middleware that lets validators access a competitive builder marketplace to improve competition, decentralization, and censorship-resistance on Ethereum
  • The Flashbots Protect docs say transactions are routed through a private Flashbots mempool, can receive MEV and gas-fee refunds, and are only included if they do not revert
  • BuilderNet’s official materials show Flashbots is still expanding the block-building stack, now framing part of the roadmap as a decentralized TEE-based builder network that shares MEV with the community
  • The public GitHub organization says Flashbots’ work is split across product, research, and coordination, with open-source repos, collaborative research processes, and grant pathways rather than a closed commercial product surface alone
• Whitepaper: No single canonical Flashbots company whitepaper or litepaper surfaced in this pass. The clearest current source of truth is the combination of the Flashbots site, docs, MEV-Boost and Protect docs, BuilderNet docs, GitHub organization, and major writings such as the mission and SUAVE essays; see ../whitepapers/flashbots-primary-sources-2026-04-27.md.
• Sources:
  • https://www.flashbots.net/
  • https://docs.flashbots.net/
  • https://docs.flashbots.net/flashbots-mev-boost/introduction
  • https://docs.flashbots.net/flashbots-protect/overview
  • https://buildernet.org/
  • https://github.com/flashbots
  • https://writings.flashbots.net/the-future-of-mev-is-suave

Internal linkages

• Keep the umbrella note on the clearest child surfaces: flashbots-auction, mev-boost, and buildernet.
• Separate the product-family lens from the operator lens: use flashbots when the question is who runs the services, controls BuilderNet infrastructure, or sets onboarding / policy for Flashbots-operated surfaces.
• Useful cut: lower-tier orderflow and rights-sale notes can point up into this stack; this note does not need to validate every descendant.

Project / company boundary

• Keep this project note on the reusable Flashbots stack as an ecosystem surface: MEV-Boost middleware, Protect as a user-facing private-orderflow product, BuilderNet and related builder infrastructure, and the research-and-design program shaping PBS-era execution markets.
• Use flashbots for the named operator boundary above that stack: hosted relays and Protect endpoints, onboarding and service-policy gates, BuilderNet provisioning and identity infrastructure, and the legal entity that can change or discontinue Flashbots-operated services.
• That split matters because what mechanisms does Flashbots popularize? and who runs the easiest production path for those mechanisms? are different questions. The project note should preserve the product-family and market-structure lens without collapsing everything into one company-controlled service shell.

Control surface

• At the project layer, the leverage sits in which builder / relay architecture gets normalized, how private-orderflow protection is packaged, which middleware becomes validator-default, and how research narratives steer ecosystem acceptance of PBS-style market structure.

• The hosted operator shell still matters, but that belongs mainly in flashbots. This note is the cleaner place to compare mechanism families and adjacent execution-supply-chain designs rather than just one organization’s service perimeter.

• Read this note when the question is what stack did Flashbots introduce and normalize across Ethereum's execution supply chain? Read the company note when the question is which operator controls the service, admission, and infrastructure boundary many users actually depend on?

• Last reviewed: 2026-08-09 UTC