MEV Order Flow: The Weapon of Block Builders

Original author: noxx Original compilation: Block unicorn · After the merge, the royal battle of block builders. With just over two weeks until the merge, it will forever change the landscape of Ethereum MEV. Block builders, a new entity in the post-merge world, are about to enter a brutal royal battle game. And the weapon they choose is------order flow. In this article, we will discuss how builders weaponize their order flow, the risks it brings to the Ethereum chain, and take a glimpse into the potential future that lies ahead of us.

Game State: Pre-Merge

Before we look at how things will unfold post-merge, it’s best to understand the current situation.

The image below shows a user's Uniswap transaction, highlighting the roles involved in the process from the user to the miner, and displaying some paths the transaction takes to enter the chain.

1. A user has some "intent," in this case, the intent is to trade some tokens on Uniswap.

2. The user navigates to the application he wants to use and connects with his wallet provider; in this example, we assume he is using Metamask.
3. The user specifies the trade he wants to make: 10 ETH to buy 20,000 DAI. The application constructs some call data for him to sign (0x5ae4…000), creating a transaction that represents his trade, and this signed data will be sent to the RPC endpoint in the next section. 4. We assume the user has not changed any default settings on Metamask, particularly the RPC endpoint for the Ethereum network. If so, the RPC endpoint will be set to https://mainnet.infura.io/v3/. This means the transaction will be sent to Infura.

Block unicorn notes:

Infura: In simple terms, Infura is a platform that allows your DApp to quickly connect to Ethereum without needing to run a local Ethereum node.
RPC: Remote Procedure Call, a protocol that allows a program to request a service from a program located on another computer on a network without having to understand the network's technology. (A simple explanation: for example, today you went out to work and forgot to do laundry, you call your family to help you wash the clothes, that’s a remote procedure call.) 5. Infura then propagates this transaction to other nodes in the Ethereum network. When the transaction lands on each node, it is placed in the public mempool, which is a staging area for transactions before they are submitted to the chain. The transaction will stay here until it is sorted into a block. 6. Miners create blocks by selecting and sorting transactions in their memory pools. Typically, they prioritize high Gas (transaction fee) transactions. 7. The user may not know that another group of actors known as seekers is monitoring the memory pool. They are looking for valuable transactions. When they see the user's ETH→DAI trade, their bots will sandwich it, giving him the worst execution price while they pocket the maximum profit. 8. They do this by submitting transaction bundles to Flashbots relayers, where they are guaranteed to be at the top of the block, and either all transactions in the bundle execute or none do. 9. These block bundles are aggregated by Flashbots and sent to whitelisted miners to be included at the top of the block (allowing miners to quickly package their transactions). 10. If we look back at the beginning of our journey, the user can change his RPC endpoint in Metamask settings. He can switch to a private RPC endpoint, an endpoint that bypasses the mempool. An example of a private RPC endpoint is Flashbots Protect, which guarantees no front-running bots or sandwich attacks, allowing you to avoid the monsters in the dark forest. 11. Private RPCs are set to route to designated miners, where agreements can be made on transactions. These miners typically have a custom client (i.e., mev-geth), which allows them to have a private memory pool that does not broadcast transactions sent there. Miners extract as much "ethical" value (i.e., through backrunning) as possible and sort in the block. The purpose of this is to show you the existing order flow. I highlighted "user public order flow," which comes from the public memory pool, "user private order flow," which comes from private RPC endpoints, and "seeker order flow," which comes from seeker auctions/relayers.

Public user order flow is available to everyone.

On the other hand, seeker and private user order flows are "exclusive" to the entities that establish these private relayers/RPC endpoints.

It is this exclusive order flow that has the power to change the game.

Post-Merge World

Well, this is what happens in the pre-merge world, but what will happen in the post-merge world? To help us understand, there are two important changes that occur during the merge that we need to review.

PBS, the separation of proposer and builder, and the concept of blind blocks; let’s start with PBS.

Proposer-Builder Separation (PBS)

PBS is the ability to separate block builders from block proposers; let’s look at each one. Block Builders

Block building involves sorting/ordering transactions within a block. It’s a game where hardware, algorithms, and information determine your success.

This is a competitive game, meaning you need to upgrade your hardware, improve your algorithms, and obtain the best order flow (information) to stay in the game.

These requirements mean that block building has a high barrier to entry.
Block Proposers

Block proposing requires you to stake 32 ETH and run some client software. Currently, the hardware requirements for this software are low, allowing each participant to maintain their own validator.

The only way you can compete is by putting in more ETH; as you increase the number of validator nodes, the computational demands do not increase significantly.

While the initial stake of 32 ETH may deter many, the computational requirements remain low enough for individual stakeholders to compete in block proposing.
MEV Blocks Let’s first consider what happens if validators both build and propose code blocks simultaneously.

Individual validators cannot obtain the hardware, algorithms, and information needed to build MEV blocks, so they can only build a regular block. This regular block uses the default sorting logic of the execution client, sorting transactions by Gas price.

MEV validators will be larger existing entities that can obtain the hardware, algorithms, and information necessary to produce these more valuable MEV-based blocks.
MEV Yield

It is estimated that MEV can earn validators 60% of their yield in a year. This means that if our individual validator earns 4% annually with their vanilla blocks, then MEV validators with their MEV blocks will earn 10%.

The chart below shows how this yield difference impacts individual validators over time.

Let’s break down what’s happening here: 1. This equation represents the compounding for individual validator nodes.
a. 1.04 represents a 4% annual yield.

b. x represents the number of years the node has been running.

c. Note that in reality, staking does not automatically compound your rewards; you need to take out what you earn and create a new validator node/purchase more liquid staking tokens.

2. This equation represents the compounding for MEV validators.

· 1.10 represents a 10% annual yield.

3. The chart shows the yield of two validator nodes over 30 years. We can clearly see that as the yield difference increases, the performance of MEV validators begins to significantly surpass that of individual validators. Over time, this situation will worsen at an accelerated rate.

4. Over a 30-year period, individual validators have earned 2.25 times their initial investment, while MEV validators have earned 16.5 times.

a. MEV validators have been able to capture these profits and launch new validators at a faster rate than individual validator nodes, thereby reducing their market share.

b. It’s clear that if the entire validator group is split 50/50, with half being individual validator nodes and the other half being MEV validator nodes, then MEV validator nodes will quickly gain dominance in the validator group.

This chart shows us how much centralization power MEV can have if block building and block proposing are combined.

Now you might think that if you separate the roles, you are just shifting this centralization power to builders instead of validators, and you are correct.

The implicit meaning in the design of PBS is that MEV is a concentration of power, but we prefer that concentration to occur at the builder level rather than the validator level.

With PBS, a new entity formally enters the Ethereum ecosystem, an entity focused on building modules.

Block Builders

Block builders already exist, with mining pools having dedicated search teams for private relayers. Flashbots receives search bundles of block packages through Flashbots auctions. Both entities have a set of transactions/block packages and sort them in a way that maximizes value.

Mining pools build blocks, while Flashbots build for their giant mining pools.

Pre-Merge: Trust-Based System

Before the merge, these "builders" would only delegate their "building" to themselves or miners they had agreements with, which is a trust-based system.

If we look at builders like Flashbots, they must send their large sums of money to miners and trust that they won’t steal the MEV from them.

Miners hold the ultimate power, as post-merge validators will hold the ultimate power.

If a seeker sends a $10 million liquidation transaction, theoretically, the miner could call the liquidation through their address at the top of the block, thus stealing the opportunity.

To prevent this, they establish partnerships with large mining pools, where the incentive means that stealing individual transactions is not worth jeopardizing the relationship with Flashbots and losing access to the MEV bundles.

For individual miners, these incentives do not exist, as given their low frequency of winning blocks, stealing MEV and jeopardizing relationships may yield the highest expected value.

The result is a permissioned system where only certain miners can access Flashbots MEV order flow and profits.

Post-Merge: Trustless System

In Ethereum, the post-merge builder/validator relationship (similar to the pre-merge builder/miner relationship) is closer to a trustless model.

This is achieved through a new feature of Ethereum called "blind blocks."

Blind blocks refer to blocks that only include the block headers present in Ethereum blocks, without sending any transactions along with the data block.

After validators sign the blind block and send it to builders, transactions are sent. Since builders will send this signed block to the network, it means that validators cannot steal the MEV contained within before the block starts propagating to other nodes.

At this point, if a validator proposes a new block that "steals" an MEV opportunity, it will "propose two different blocks at the same height," and they will be penalized by losing the staked 32 Ethereum.

Moreover, there is no guarantee that a block claiming to have an MEV opportunity will ultimately become a canonical block. There is a 50/50 chance it is the original, and the validator gets slashed (penalized) and cannot seize the MEV opportunity again.

This serves as a deterrent for validators, as the high penalty costs may outweigh the potential gains from stealing MEV. (The situation being investigated is that the highest expected value is to attempt to steal MEV, but this is not common.)

Ethereum Specification - Blind blocks can only access transaction roots.

Note that when we say this relationship is closer to a trustless model, it applies in the direction from builders to validators.

Since blocks are shielded, validators cannot ascertain whether it is a valid block; they must trust the block that the builder has sent.

Builders are clearly incentivized to send valid blocks; if they do not, they will lose the value they might have gained and could potentially be blacklisted in the future.

Fortunately, the loss for validators is limited to missing their block proposal, as invalid blocks are not a punishable offense.

In the post-merge world, any validator can connect with any builder and access these MEV transactions through blind blocks.

This puts individual validators on equal footing with large entities, as both can now obtain more rewards through MEV.

MEV Supply Chain

Next, let’s look at the MEV supply chain post-merge, particularly the builders. We will use "Flashbots builders" as an example to showcase some different areas where they can compete.

Exclusive Transaction Order Flow

▲ Seeker order flow - Flashbots Relay

▲ User private order flow - Flashbots (MEV bot auctions) protection

Internal MEV

▲ Identifying MEV not in your "seeker order flow"

▲ Capturing ethical MEV from "user private order flow"

Latency

▲ MEV auctions will introduce some additional latency from network hops.

▲ Vertical integration/co-location can limit the time of these hops.

▲ This can give builders more time to see transactions/calculate the best block before submission deadlines.

Block Building Algorithms

▲ More efficiently packaging a block to include the most value.

Among all these, "exclusive transaction order flow" is almost certainly the most important factor.

Let’s revisit the Uniswap transaction depicted earlier, but now in the builder/validator model.

The white box shows where most of the changes occur. I omitted the relayer, which acts as an aggregator for block builders, delivering the most profitable blocks to validators.

1. Here, this private RPC endpoint represents Flashbots Protect, where previously these order flows were sent to whitelisted miners. Now, they will become exclusive order flows for Flashbots builders, meaning other competitors cannot access them.

2. The seeker order flow here is the bundled block packages received by Flashbots Relay. Again, this will be an exclusive order flow that only Flashbots builders can access.

3. The public order flow found in the mempool, which Flashbots generators can also access, but other generators can access as well, meaning it does not provide a competitive advantage.

4. Validators running mev-boost (MEV auctions) will be able to connect to this builder network. They will receive blind blocks from builders and propose blocks that provide them with maximum value.

This example is specifically for Flashbots, but we can expect every builder to have the same theme. They will have their own seekers and private transaction endpoints, and they will try to encourage people to use these services, which are their unique order flows and key competitive advantages.

Here’s an excellent chart from Flashbots that details the white dashed box above.

Now let’s zoom in on "private RPC endpoints" and the benefits they provide to users.

Benefits of Private RPC Endpoints

Private RPC endpoints can offer many benefits to users, some of which we have already mentioned; let’s take a look at these benefits:

Pre-Transaction Privacy

• Protection against front-running/sandwich attacks.

Transaction Simulation

• Recovery protection------if it fails/reverts, never include.

Comprehensive Protection (in the future)

• If you send tokens to a known honeypot address, a warning will be issued.
• If the gas paid is very high, check carefully with the user, as this may not be their intent.

So, with all these great features, why aren’t all users using them? It mainly comes down to knowledge and friction in the setup process.

If we look at knowledge, many users are unaware of the existence of this feature and do not know there are ways to solve some of their problems. They do not realize they are being front-run or sandwiched. They do not know they can prevent that costly revert during the NFT minting process.

To clarify the friction, let’s take Metamask as an example and see how we set this up on Metamask.

Users must go to Metamask wallet settings → Networks → Ethereum Mainnet (Networks) → New RPC URL and change that URL.

This may sound easy to you, but for a new user, it can feel uncomfortable or they may want to play with the defaults.

It can be said that this is not something users should have to deal with; it requires too much knowledge to make an informed decision.

So how do we solve this problem? One way is for wallet providers (like Metamask) to change their global default settings to private relays.

Metamask: The Sleeping Kingmaker

Let’s think about how powerful this ability to change the global default endpoint is for wallet providers like Metamask.

Consider how much public memory comes from Metamask wallets. Some studies suggest that up to 70% of transactions on Ethereum are conducted through Metamask.

How much are builders willing to pay to monopolize that order flow, or how easily could Metamask dominate if it decided to create its own building entity?

In other words, Metamask seems to be a "sleeping kingmaker," and if it wishes, it can crown itself; it’s a tough road for Metamask.

They gain tremendous value from their order flow, but they want to ensure they do not harm the user experience and that the community agrees with any changes being made.

If Metamask uses a default private RPC, and the builders on the other end are not consistently winning builds, then users may wait for many blocks to confirm their transactions.

Since their transactions are not in the mempool, they cannot go on-chain until the Metamask builder wins a build opportunity.

To limit this waiting time, Metamask could easily embed some default logic. One example is that if a transaction is not included within 3 blocks, it will be sent to the public memory pool.

Monetizing Order Flow

Wallet providers are considering monetizing their order flow, allowing them to capture MEV value and return it to their users. They can do this through gas discounts, token releases representing shares of the value obtained, etc.

If mainstream wallets decide not to monetize order flow, we may see wallets that acknowledge and leverage order flow pivoting significantly.

To me, the payment solutions for order flow exist at the application and wallet level; the best applications and wallets will be those that can return the maximum value to their users. ------Stephane Gosselin - Flashbots - Unchained Podcast

Does this force the hand of dominant wallet providers into the order flow game? Is there too much value to ignore?

Let’s see how these order flows can be sold.

Exclusive Agency Agreements

The simplest way for wallet providers (Metamask) to sell order flow is through some agreements, providing exclusive order flow to one or more builders.

These agreements will have terms of service:

• No malicious MEV, including front-running transactions, sandwich attacks.

• Transactions will be released to the mempool after 3 blocks.

• 6-month contracts.

I believe this practice will be very concentrated in the builder market. If only one builder can access the Metamask order flow, then the game may be over for everyone else.

Order Flow Auctions

Another possibility is the concept of individual transaction auctions.

Wallets can provide auction services for all builders, where they expose an unsigned transaction flow for bidding.

The auctions will have time limits to ensure inclusion, and only builders registered with the next proposing validator can bid.

If no bids are received for the transactions, those transactions will be sent to the public memory pool, with known transactions that have no "MEV value," such as simple ETH transfers, also set to default to the memory pool.

When a builder successfully wins a bid, they will pay a fee and receive the already signed transactions. Similar to "exclusive agreements," there will be auction terms of service, such as Tx being sent to the memory pool after 3 blocks, etc. Builders will need to write algorithms/models to automatically price different transactions and determine bids.

Wallet providers can take a small cut from these auctions and return the remainder to users for specific transactions. The higher the value of the user’s transaction, the higher the bids from builders, and the higher the returns they receive. This auction method fixes the issue of distributing MEV to different addresses when a batch of transactions is sold.

Psychological Tactics

Another thing we can see from order flow auctions is that builders can predict based on the available unsigned transactions, just like bots look at the order book of exchanges.

Can entities fake transactions in the auction to gain some advantage? It will depend on the wallet provider/auctioneer to prevent this from happening.

Centralization Power

Let’s look at what happens when one builder monopolizes most transactions on Ethereum.

For example, 20 builders can access 300 transactions in the mempool. There is a single builder that can monopolize 700 transactions from Metamask in addition to the 300 mempool Txs, giving them 1000 transactions to build.

This builder of 1000 blocks can build most blocks, giving them a larger search space to construct blocks and monopolize some value.

Slowly, those block builders with only mempool access will go out of business. They will not win enough blocks, and any exclusive order flow agreements they may have signed will not be renewed or will be terminated.

The frequency with which builders win blocks directly impacts their user experience; ultimately, they cannot compete and cannot operate profitably.

"In the coming years, exclusive order flow poses a significant risk and danger in the MEV space." ------Hasu - Flashbots - Wintermute MEV Hackathon

A world where a block builder competes on exclusive order flow is one with a strong gravitational pull towards a winner-takes-all effect among block builders.

MEV Dystopia

The following diagram comes from Stephane's talk on MEV Utopia and Dystopia, highlighting the decentralized MEV supply chain. The red boxes I added indicate areas that can be vertically integrated through exclusive order flow.

Let’s run a simulation where Metamask creates its own builder and see what happens. Metamask controls 70% of the public order flow; they make this exclusive order flow their own and can quickly dominate the block building space.

Since they dominate block building, seekers have no choice but to send their packages to the Metamask builder. If they do not, they can only access the MEV on the blocks currently won by builders, as the proportion of the Metamask domain is very low.

Metamask begins to build an internal seeker team that learns from the seeker order flow they have access to.

The internal seeker team can extract value from 70% of Ethereum transactions without competition, while external seekers can only compete for value in the remaining 30% in the mempool.

By dominating the builder space, Metamask can also retain more MEV for itself rather than passing it on to validators.

In a competitive market, profits are squeezed, and most of the value ultimately falls into the hands of validators.

In a monopoly, Metamask only needs to ensure that their block building pays slightly more than the next best builder. Soon, Metamask has begun to dominate the wallet, search, and building markets.

The community's reaction will be interesting; likely, Metamask will have to self-regulate like mining pools and validator pools. The following diagram by Jon Charbonneau illustrates the feedback loop discussed above, which can quickly lead to centralization.

Application-Level Optimizations, Cross-Chain, and CEX

There are many factors I have not touched on that will influence the development of this future. Let’s briefly discuss each factor and provide a high-level overview.

Application Optimization

Decentralized applications like Uniswap and Sushiswap have strong incentives to reduce the MEV exposed by their protocols. Ideally, they can capture value for themselves and their users at the Tx source.

A great example of this is the collaboration between Sushiswap and Manifold Finance (Manifold aims to be one of the main block builders post-merge). Sushiswap will replace their "transaction router" at the protocol level with Manifold's "MEV router."

The "MEV router" aims to capture arbitrage opportunities when users transact and return value to the protocol. These application/builder relationships will be another area of competition for builders.

Cross-Chain MEV

Cross-chain MEV has emerged, but we can expect it to become more competitive in the future. Cross-chain MEV is non-atomic, has higher execution risks, involves inventory management, and requires deep knowledge of multiple chains.

Therefore, its barrier to entry is much higher. Everything we have discussed has a rough reflection on other chains. Imagine the opportunity to obtain order flow from Solana (SOL), Avalanche (AVAX), etc.

Order flow on other chains will affect what can be done on Ethereum, increasing the search space for valuable transactions, always favoring the discovery of the highest-value combinations. How significant the impact of this "other chain" order flow will be on the builder network remains to be seen, but in a hyper-competitive environment, it will provide an advantage.

Centralized Exchanges (CEX)

Like cross-chain MEV, we have already seen opportunities for on-chain/off-chain MEV being exploited. Through centralized exchanges, builders will have to minimize latency through custody and negotiated trades to achieve the lowest trading fees.

If one builder agrees to a 0.02% trading fee while another builder's fee is 0.08%, what impact does this have on the on-chain/off-chain opportunities available to them? This will be another area where builders can compete and try to find their advantages.

Unknown Future

Who knows what will happen in the future; this is an active area of research with many changes. The following statement from Stephane reflects the reality of the builder market while also reflecting the community's mission to keep things as decentralized/flat as possible.

"Ultimately, the builder market will likely have some power-law distribution, where top builders accumulate most of the proposal rights, but we hope to keep this distribution as flat as possible." ------Stephane Gosselin - Flashbots - Bankless

Who knows, maybe there is light at the end of the tunnel.