Flashbots Transparency Report — August & September 2022

The wait is over – Ethereum has transitioned to PoS, MEV-Boost is live and the Flashbots Transparency Reports are back! This edition will cover highlights from the weeks leading up to the merge until today, the start of Devcon VI in Bogota.


:person_raising_hand: Hi everyone! Fred here – newly appointed Community manager at the Flashbots collective and long-term Ethereum enthusiast. I’m very excited to help steward our community as we enter this new era for both Ethereum and Flashbots. As part of my role, I will work to reduce the information overload by publishing monthly reports that cover recent developments, research, discussions and events related to Flashbots.

I’m looking forward to having the Flashbots Transparency reports once again serve as both a snapshot on our journey and as a conversation starter for our community. The focus of this edition will be the Merge, the implications it has on MEV and the adoption of MEV-Boost.

With the merge behind us an important phase for Flashbots has come to an end. Mev-geth as a single client implementation has been replaced by MEV-Boost, a sidecar that can plug into any consensus client. The risk of validator centralization due to MEV extraction is being reduced by proposer builder separation and permissionless access to a competitive market for block building. At the time of writing, almost 50% of proposed blocks are being relayed through MEV-Boost and validators proposing blocks from MEV-Boost are on average earning almost 300% more in block rewards.

This report will start by recounting the final preparations leading up to the Merge and activation of MEV-Boost before taking a look at where we are today. We will also present our recently published research papers, and highlight community resources and ways to get involved.

The weeks leading up to the merge

MEV-Boost was thoroughly tested and optimized ahead of merge to work with all clients through collaboration with the Flashbots Eth2.0 Working Group. Achieving compatibility with every client is a major upgrade to the previous structure in proof-of-work Ethereum which required miners to run mev-geth in order to participate in the Flashbots auction.

To prepare searchers with regards to how MEV-Boost impacts their operations, Brock Smedley published Searching Post-Merge. The post explores the impact of proposer/builder separation and gives some considerations to keep in mind when choosing block builder. If you are a searcher reading this – make sure to also give the Searchers Self-Support part of the forum a visit!

Flashbots Protect – The Merge & Beyond by Angela Lu provides a year in review of Flashbots Protect and presents improvements that followed from the merge. Users of Flashbots Protect today will experience both faster time to inclusion and revert protection. MEV-Boost may also open the door for a couple of new UX features to Flashbots Protect such as account abstraction, sponsored transactions, fee payment in ERC20 tokens, user MEV kickbacks and more.

In response to the legal requirements for relay providers in their home jurisdictions, we decided to accelerate the release of our relay code as open source under a AGPL-license. This is core to our mission of minimizing MEV-related harms to public blockchains and their users. Additional context on how we are working to reduce the reliance on the Flashbots relay can be found at the end of the next section below.

The Merge and today

As the Ethereum community celebrated TTD and the first PoS block to include execution layer transactions, the pressure was not quite over for the Flashbots engineers and researchers. In order to reduce technical complexity and moving parts at the merge, MEV-Boost waited until 17 epochs had been finalized before activation. Just like the merge, activation of MEV-Boost went smoothly and the Flashbots MEV-Boost relay successfully started sending bids beginning at epoch 146,892.

A bug with the initial version of MEV-Boost was found shortly after activation which caused three missed slots when a deposit was included. The bug was resolved in MEV-Boost v1.3.1 the following day, a full post-mortem of the event and fix can be found here. Expect improvements to continue as we strive to optimize and make things even more efficient.

As of today, roughly a month after the Merge, MEV-Boost has reached 50% adoption from validators, earning them on average almost 300% more in block rewards.

From the MEV-Boost Dashboard by ChainsightAnalytics

From the Flashbots Transparency dashboard

The Merge and MEV-Boost brings significant technical and structural changes to how Ethereum’s MEV marketplace works. As part of our effort to illuminate this dark forest and provide transparency we have launched Flashbots Transparency dashboard and Flashbots MEV-Boost Relay to provide metrics related to the Flashbots MEV-Boost relay and builder. We will continue to improve the dashboard with additional metrics as more data becomes available. Our goal is to set a standard for open, transparent data policies that the wider community will adopt and continue to expand upon. For more details about the dashboard, please read the official announcement.

7 relayers have so far relayed blocks through MEV-Boost (Flashbots, BloXroute Max Profit, BloXroute Ethical, BloXroute Regulated, Blocknative, Manifold & Eden). To bootstrap relay competition we deliberately avoided enshrining the Flashbots relay as default in MEV-Boost. We do however see that the Flashbots relay is currently relaying 84% of MEV-Boost blocks, 42% of all blocks proposed on the network.

From the Flashbots Transparency dashboard

unique builders have so far had blocks proposed through MEV-Boost. The first days after the Merge the Flashbots builder was producing 80% of MEV-Boost blocks, the trend has been going down ever since and today that number is roughly 50%. Every block that is built by Flashbots contain a reminder of our commitments and our approach to mitigating the MEV crisis:

  • To Illuminate the Dark Forest,
  • To Democratize Extraction, and
  • To Distribute Benefits

From MEV-Boost Dashboard by ChainsightAnalytics

From @0xdef1

Toward an open research and development process for MEV-Boost

MEV-Boost is built by Flashbots in collaboration with the Ethereum Foundation and client teams as neutral infrastructure. Flashbots are committed to building an open, permissionless, and transparent MEV ecosystem and MEV-Boost is designed from the ground up with Ethereum security as the primary objective.

To reduce reliance on Flashbots and accelerate the on-going maturation of the market we will submit our builders’ blocks to other relays to help them bootstrap adoption. We will also be open sourcing more of our knowledge and infra in the coming weeks.

We will commit additional resources to research ways to limit builder power and centralization, for example by using inclusion lists. We are also issuing a grant for the development of a relay monitor, which will help the community impartially evaluate and monitor the performance of relays.

For additional context on MEV-Boost, our (currently) centralized infrastructure, and competition please see this note posted by Robert Miller.

The systemic importance of MEV-Boost makes it necessary to be thoughtful about how ongoing research and development should be organized. Chris Hager initiated a conversation on the forum to kickstart the discussion on what a collaborative, open and effective R&D process to MEV-Boost should look like. Please join the conversation and share your thoughts on how we can collectively navigate the path forward!

Flashbots Research

Order flow, auctions and centralisation

Quintus Kilbourn published a two-part article on order flow, auctions and centralisation. The first part describes the potential for exclusive order flow (EOF) to centralize the builder market and render it uncompetitive. Having uncontestable builders with disproportionate control over the incentives of the network would be a serious threat to PBS and the health of Ethereum.

The second part looks at order flow auctions as a way to counteract the dangers of EOF and describes how “explicit” and “implicit” auctions can help a user internalize MEV. The article argues that order flow auctions can address part of the EOF problem and explores meaningful differences between these two auction design types, while identifying similarities that point to a more fundamental problem.

Feel free to also watch the presentation from SBC-MEV and participate in discussion on the forum (part I, part II).

Modelling Realised Extractable Value in Proof of Stake Ethereum - an update of validator return post-merge.

Elaine Hu published a paper that presents three methodologies to model MEV using historical observed realized extractable value (REV) data. The model is able to estimate a range of validator returns under different network conditions and provides a new way to anticipate block rewards in proof of stake Ethereum. Elaine also gave a presentation on the topic at SBC MEV.

Can First Come First Served-Based Transaction Ordering Prevent Front-Running?

Robert Annessi explores what needs to be true for First Come First Serve (FCFS) ordering protocols to provide frontrunning resistance in a permissionless setting. The article highlights the importance of the front-runner’s position within the network, and how front-running mitigation can be improved if privileged positions within the network are hindered. It describes how FCFS-based ordering of transactions may reduce the downsides of specific front-running prevention mechanisms and how FCFS-based ordering can mitigate front-running to a certain extent but cannot prevent it completely. Feel free to also join the discussion on the forum.


Xinyan published a post on the Arbitrum research forum that presents FBA-FCFS (frequent batch auction first come first serve) and argued for why it maintains the same no-frontrunning guarantee to users, while improving UX and fairness guarantees.

Public appearances, podcasts and events

Flashbots and the Ethereum Foundation hosted SBC-MEV on September 1 – A one day event with talks and workshops focused on the latest questions around MEV & PBS. Recording and slides from the 13 talks can be found here.

Flashbots joined the Encode x WinterMute MEV Hackathon as an education partner and hosted four virtual MEV workshops:

Flashbots mates also gave talks and joined panel discussions at Dappcon, Mainnet and Ledgerfest. (Recordings of these will be added here once they are made available.)

:calendar: In order to stay up to date on any upcoming events feel free to subscribe to the Flashbots Collective calendar!


Below are a collection of publications and dashboards from the broader community in last month on the topic of MEV, PBS and Flashbots:

Get involved

At Flashbots, we research and build systems around MEV, and we would love to collaborate with you. We are a distributed organization with the principles of a pirate hacker collective, and have several open positions. We also issue grants to external researchers doing work aligned with ours, please find out more in our Research repository. Make sure to also take a look around here on our brand new forum and join the conversation!

If you’re in Bogota this week Flashbots is hosting a full day of MEV Workshops on Oct 14, right next to DevCon venue! :zap::robot:


This “transparency” report rings incredibly hollow when it doesn’t mention FB Relay censorship at all. Real transparency would mean including a list of all censored transactions, along with reason for censoring each, the algorithms/mechanisms used to determine whether a transaction should be censored, and recordings/summaries of all internal discussions that occurred that lead to the decision to censor.

Transparency doesn’t mean just presenting the good stuff and/or a progress report. It means actually being transparent about your internal practices, decision making processes, and the things that you would rather people be unaware of.

Thanks for your comment and for engaging here!

First off, want to say you are 100% correct, any community questions that are important to answer, including ones around our blocking infrastructure, should be included here to the maximum extent we are possibly able to do. Over the next week or two we will discuss what specific information we can synthesize and provide. At minimum, this report should likely have included the ETH/OFAC tracker, and your reaction in feeling it was sanitized is completely valid. I hope you believe us that this was not the intent – these updates started as a way for people to get insight into our organization and engage with it, not to provide transparency on legal/regulatory matters, so there’s some discontinuity in the purpose they served before vs. now. We didn’t fully anticipate the extent of the discontinuity, and we should have.

In terms of recordings/summaries/etc, we are engaging the community to provide context on our internal decision making. I did a panel at Devcon about this yesterday, I am personally engaging the community in person, and my talk on Friday (recorded) will address many questions I am sure the community has.

That being said, we should be realistic of what we can/can’t provide also. It is not feasible or IMO optimal for the community to open source things like legal advice, as this is an active grey area we are working with counsel and many, many parties to illuminate. I still intend to answer all the relevant questions for the community surrounding our strategy. I hope over time you will see that we intend to go above and beyond most companies in the space on that front.

Some of what is in your ask is already present to the legally maximal possible extent. For example, we already do open source the bulk of the centralized compliance infrastructure in question in our public repositories. We are also working to open-source much of the infrastructure used in our builder for this. Finally, we do use standard, Cloudflare-style IP geofencing on our centralized endpoints for jurisdictions such as North Korea and Iran.

We really appreciate your feedback here a lot. I really believe we are all aligned, and look forward to you continuing to hold us to the highest possible standard, and for us all to discuss in good faith.


Also, let me add that this is work in progress:

First we are defining what is trust. In parallel, we are implementing the processes and APIs that will make us earn that trust and that will set the expectations for how other parties playing this game should behave. Next, we are working on minimizing the parts of our operation that require trust.

Expect more info about this in the following transparency reports, as we ship more things.

I personally request a kinder tone from you. That would make this journey a lot easier for me.

1 Like