Order Flows: Kingmaker of the Block Builders 👑
The Merge is just over 2 weeks away and it is set to change the Ethereum MEV landscape forever.
Block builders, a new entity in the post-merge world are about to enter a brutal game of battle royal.
And their weapon of choice - Order Flows.
In this article we’ll be discussing how builders will weaponise their order flows, the risks it poses to the Ethereum chain and take a peek at the potential futures that lay before us.
State of Play: Pre-Merge
Before we take a look at how things could play out post-merge it’s good for us to have an understanding of how things work at the moment.
The image below maps out a Uniswap trade from a user. It highlights the actors involved as the transaction makes its way from the user to the miner and shows some of the paths the transaction can take to get on-chain.
A User has some “intent” in this case the intent is to trade some tokens on Uniswap.
The User navigates to the app he wants to use and connects using his wallet provider, for this example let’s say he uses Metamask.
The user specifies the trade he wants to make 10 ETH → 20,000 DAI. The app constructs some call data for him to sign (0x5ae4…000) which creates a transaction that represents his trade. This signed data is what will be sent to the RPC endpoints in the next section.
Let’s Assume the user hasn’t changed any of the default settings on Metamask, specifically the RPC Endpoint for the Ethereum network. If this is the case RPC endpoint will be set to https://mainnet.infura.io/v3/. This means the transaction will be sent to Infura.
Infura will then propagate this transaction out to the rest of the nodes in the Ethereum network. When the transactions land at each node they are placed in the public mempool, a staging area for transactions before they are committed to the chain. The transaction will sit here until it is sequenced into a block.
Miners create blocks by selecting and sequencing transactions in their mempool. Typically they prioritise high gas transactions first.
Potentially unbeknown to this user another group of actors called searchers are monitoring the mempool. They are looking for valuable transactions. When they see the user’s ETH → DAI transaction their bot sandwichs it to give him the worst possible execution price and themselves the greatest profit.
They do this by submitting bundles of transactions to the Flashbots relay where they are guaranteed to be top of block and that either all the transactions in the bundle execute or none do.
These bundles are merged together by Flashbots into a megabundle and sent on to whitelisted miners to be included at the top of the block.
If we look back at the start of our journey the user could have changed his RPC endpoint in the Metamask settings. He could have switched to a private RPC endpoint, one that bypasses the mempool. An example of a private RPC endpoint is Flashbots Protect, they guarantee no front running or sandwiching enabling you to avoid the monsters in the dark forest.
The private RPC is set up to route to specific miners where agreements are made about what can be done with the transactions. These miners typically will have a custom client (ie mev-geth) which enables them to have a private mempool that doesn’t broadcast the transactions sent there. The miners extract as much “ethical” value (ie via back running) as they can and order them in the block.
The purpose of this is to show you the order flows that already exist. I have highlighted the “user public order flow” which comes from the public mempool, the “user private order flow” which comes via private RPC endpoints and the “searcher order flow” which comes via searcher auctions/relays.
The public user order flow is available to everyone.
The searcher & private user order flows on the other hand are “exclusive” to the entities that set up those private relays / RPC endpoints.
It’s this exclusive order flow that has the power to change the game.
Post-Merge World
Ok, that’s what happens in the pre-merge world but what happens in the post-merge one?
For us to understand that there are two important changes happening at the merge we need to review.
PBS, proposer builder separation and the concept of blinded blocks.
Let’s start with PBS.
Proposer Builder Separation (PBS)
PBS is the ability to separate block building from block proposal. Let’s take a look at each one.
Block Building
Block building involves ordering/sequencing transactions within a block. It is a game where hardware, algorithms and information determine your success.
It’s a competitive game, this means you will need to upgrade your hardware, improve your algorithms and get access to the best order flows (information) to stay in the game.
These requirements mean block building has a high barrier to entry.
Block Proposing
Block proposals require you to have put up some stake 32 ETH and run some client software.
The hardware requirements of this software are currently low enough that an individual staker can afford to maintain their own validator.
The only way you compete is by staking more ETH the computation requirements do not increase by much as you increase you’re validator count.
While the initial stake 32 ETH may be prohibitive for many, the computation requirements have been kept low enough for individual stakers to compete in block proposals.
MEV Blocks
Let’s think about what happens in a world where the validator both builds & proposes the block.
The individual validator, doesn’t have access to the hardware, algorithms & information required to build a MEV Block so instead builds a vanilla block.
This vanilla block uses the execution clients default sequencing logic for transactions ordering by gas price.
The MEV validators, who will be larger incumbent entities with access to the hardware, algorithms & information will be able to produce these more valuable MEV based blocks.
MEV Yield
There are some estimates that MEV could make up to 60% of a validator’s yield for the year.
This means that if our individual validator is making 4% per year with their vanilla blocks the MEV validators with their MEV blocks will be making 10%.
The diagram below shows what this yield delta can do to the individual validator over time.
Let’s run through what’s going on here.
This equation represents the compounding interest of the individual validator.
The 1.04 represents a 4% annual yield.
x represents the number of years the node has been running for.
Note in reality staking doesn't auto compound your rewards you need to take out what you have earnt and create a new validator / buy more liquid staking tokens.
This equation represents the compounding interest for the MEV validator.
The 1.10 represents the 10% annual yield.
The graph shows the returns of the 2 validators over the course of 30 years. We can clearly see that as the yield difference compounds the MEV validator begins to vastly outperform the individual validator. This gets worst at an accelerated rate as time progresses.
At the 30-year stage, the individual validator has earned 2.25x its original investment while the MEV validator has earned 16.5x.
The MEV validator has been able to take these profits and spin up new validators at a much faster rate than the individual validator reducing their market share.
It’s clear to see that if the entire validator set was split 50/50 with one half being individual validators and the other half being MEV validators the MEV validators quickly gain dominance in the validator set.
This graph shows us how much of a centralising force MEV could be if block building & block proposals are kept together.
Now you may be thinking if you split the roles you just move this centralising force to the builders rather than the validators and you would be right.
Implicit in the design of PBS is saying MEV is a centralising force but we would rather the centralisation happen at the builder level than at the validator level.
It’s through PBS a new entity officially enters the Ethereum ecosystem.
An entity focused solely on building blocks.
Block Builders
Block builders already exist today.
The mining pools that have private relays with dedicated searcher teams. Flashbots with the Flashbots auction that receives searchers bundles. Both of these entities are given a set of transactions/bundles and order them in a way that captures the most value.
The mining pools do this for the entire block and Flashbots do this for their megabundles.
Pre-Merge: Trust-Based System
Pre-merge these “builders” would only entrust their “builds” to themselves or miners they had agreements with. It was a trust-based system.
If we look at a “builder” like Flashbots, they had to send their megabundles to the miners and trust them not to steal the MEV contained within.
Miners have the ultimate power as validators will post-merge.
If a searcher sent a transaction for a $10 million liquidation in theory the miner could just call that liquidation with their own address at the top of the block stealing the opportunity.
To prevent this partnerships were formed with large mining pools where incentives meant stealing an individual transaction wasn’t worth damaging the relationship with Flashbots and losing their access to the MEV bundles.
These incentives didn’t exist for individual miners where stealing the MEV and damaging the relationship may yield the highest expected value given how infrequently they won a block.
The result of this was a permissioned system with only some miners gaining access to the Flashbots MEV orderflow and profits.
Post-Merge: Trustless System
In Ethereum post-merge the builder/validator relationship which is analogous to the builder/miner relationship pre-merge moves closer to a trustless model.
This is enabled via a new feature in Ethereum called “Blinded Blocks”.
Blinded blocks are blocks that only include the block headers present in an Ethereum block. No transactions are sent along with the block.
The transactions are sent after the validator signs the blinded block and sends it to the builder.
Since the builder will emit this signed block to the network it means the validator cannot steal the MEV contained within until the block has already begun propagating to other nodes.
At this point, if the validator were to propose a new block where it “stole” a MEV opportunity it would have “proposed two different blocks at the same height” which is a slashable offense.
Additionally, there is no guarantee that the block that claims the MEV opportunity ends up as the canonical one. There's a 50/50 chance the original does and the validator gets slashed and doesn’t manage to claim the MEV.
This provides a deterrent to validators since the cost of slashing is likely higher than the potential gain from stolen MEV. (People are looking into cases where the highest expected value is to attempt to steal the MEV however these instances will not be common)
Note that when we said that the relationship moves closer to a trustless model, this applies in the direction of the builder to the validator.
Since the block is blinded the validator can’t determine if it is a valid block. It has to trust that the builder has sent one.
The builder is obviously incentivised to send valid blocks, if it doesn’t it loses out on value it could have captured & may be blacklisted for the future.
Fortunately, the downside for the validator is limited to missing their block proposal as an invalid block is not a slashable offense.
In the post-merge world, any validator will be able to connect with any builder and access these MEV transactions via blinded blocks.
This puts an individual validator on an even playing field with the larger entities as both now have access to the enhanced rewards via MEV.
MEV Supply Chain
Next, let’s take a look at the MEV Supply chain in the post-merge world focusing specifically on Builders.
We’ll use the “Flashbots Builder” as an example and show some of the different fronts they can compete on.
Exclusive Transaction Order Flows
Searcher Order Flow - Flashbots Relay
User Private Order Flow - Flashbots Protect
Internal MEV
Identifying MEV that isn’t in your “Searcher Order Flow”
Capturing Ethical MEV from the “User Private Order Flow”
Latency
MEV boost will introduce some latency from the additional network hops.
Vertical integration / co-location could limit the time taken for these hops.
This could give the builder more time to see transactions / calculate the best block before the deadline to submit.
Block Building Algorithms
More efficiently packing a block to include the most value.
Of all of these “Exclusive Transaction Order Flows” will almost certainly be the most important factor.
Let’s revist the Uniswap trade that was mapped out earlier but now with the builder/validator model.
The white box shows where the majority of the change is occurring. I’ve omitted the relays which act as aggregators of the block builders and deliver the most profitable block to the validator.
Here this private RPC endpoint represents Flashbots Protect. Before these order flows were sent onto the whitelisted Miners. Now they will be exclusive order flows for the Flashbots Builder. Exclusive meaning other competing builders won’t have access to them.
The searcher order flow here is the bundles the Flashbots Relay receives. Again this will be an exclusive order flow, only the Flashbots Builder will have access to it.
The public order flow found in the mempool, the Flashbots Builder will also have access to these transactions however so will every other builder meaning it provides no competitive advantage.
Validators running mev-boost will be able to hook into this builder network. They will receive blinded blocks from the builders and will propose the block that delivers the most value to them.
This example looks specifically at Flashbots but we can expect the same themes to play out with every builder. They will have their own searcher and private transaction endpoints which they will be trying to incentivise people to use. This is their exclusive order flow and the key competitive advantage.
Below is an excellent diagram from Flashbots which shows the dotted white line box above in a bit more detail.
Let’s now zoom in on the “Private RPC Endpoints” and the benefits they offer to users.
Benefits of Private RPC Endpoints
Private RPC endpoints can provide a number of benefits to users some of which we’ve already touched on. Let’s run through them.
Pre Trade Privacy
Frontrunning / Sandwhich protection
Transaction Simulation
Revert Protection - Never include if it fails/reverts
Generalised Protection (In the Future)
Warn you if you are sending tokens to a known honey pot address
If Gas paid is extremely high double-check with the user this is their intention
So with all these great features why aren’t all users using them?
Primarily it’s down to knowledge & the friction in getting it set up.
If we look at knowledge a lot of users don’t know this exists or that there are solutions to some of their problems. They don’t know they’re being front-run or sandwiched. They don’t know that they could have prevented that expensive revert during an NFT mint.
To look at friction let’s see how we would set this up on Metamask as an example.
The user has to go into the Settings → Networks → Add Network and from there has to give the new “network” a name ie Ethereum(Custom RPC), add the RPC endpoint you want to use, with a chainID of 1 and currency of ETH.
An advanced DeFi user will understand how to do this and what they are doing. For casual users, this is a complicated process and they likely don’t want to play around with default settings.
One could argue this isn’t something the user should have to deal with, there’s too much knowledge required to make an informed decision.
So how do we resolve this?
One way would be for the wallet provider ie Metamask to change their global default setting to a private relay.
Metamask - A Sleeping Kingmaker
Let’s think about how powerful this ability to change the global default endpoint is for a wallet provider like Metamask?
Think about how much of the public mempool comes from a Metamask wallet. Some studies have said up to ~70% of the transactions being made on Ethereum are via Metamask.
How much would a builder be willing to pay for exclusive access to that order flow. Or how easily Metamask could dominate if they decided to create their own builder entity.
In other words, Metamask appears to be a “Sleeping Kingmaker” and one that could crown itself if it wanted to.
For Metamask it’s a difficult path to navigate.
They have access to this huge amount of value via their order flow but they want to make sure they don’t damage their users’ experience and that the community is on board with any changes that are being made.
If Metamask used a default private RPC and the builder on the other end wasn’t winning builds consistently users may be waiting many blocks for their transactions to confirm.
Since their transactions aren’t in the mempool they can’t get on-chain until Metamask’s builder wins a build.
To limit this wait time Metamask could easily embed some default logic. An example would be stating that transactions are sent to the public mempool if they haven’t been included within 3 blocks.
Monetising Order Flow
Wallet providers are thinking about monetising their order flows.
Monetising their order flows enables them to capture MEV value and give it back to their users.
They can do this via gas discounts, token emissions that represent a share of the value captured etc.
If the dominant wallets decide not to monetise order flows do we could see a great migration from those that ignore order flows to wallets that acknowledge and exploit it.
A payment for order flow solution to me exists at the application and wallet level, the best applications and wallets will be the ones that are able to return the maximum amount of value to their users
Stephane Gosselin - Flashbots - Unchained Podcast
Does it force the hand of the dominant wallet providers to enter the order flow game?
Is this too much value to ignore?
Maybe let’s take a look at how these order flows could be sold.
Exclusivity Agreements
The simplest way for a wallet provider (Metamask) to sell order flow would be via an agreement to provide exclusive order flow for one or more builders.
The agreement would have terms of service.
No Malicious MEV ie front-running, sandwiching
Tx will be emitted to the mempool after 3 blocks
6 month contract
etc.
I would argue that this approach would be very centralising for the builder market. If only one builder got access to Metamasks order flows that might be game over for everyone else.
Order Flow Auctions
Another possibility is the concept of individual tx auctions.
The wallet provide could provide an auction service to all builders where they exposed a stream of unsigned transactions to be bid on.
The auctions would be time bound to ensure inclusion and only builders who were registered with the validator that was up next to propose the block would be able to bid.
If no bids were received for a tx it could be emitted to the public mempool. Transactions known to have no “MEV value such as simple ETH value transfers could also be set up to default to them mempool.
When a builder successfully won a bid they would pay the fee and be sent the signed transaction.
Similar to the “Exclusivity Agreements” there would be terms of service with the auction ie No front-running sandwiching, Tx will be emitted to the mempool after 3 blocks etc.
The Builders would need to write algorithms/models to automatically price different transactions and determine what to bid.
The wallet provider could take a small percentage from these auctions and return the remainder to the user for that specific transaction.
The more valuable a user’s transaction, the more the builder will bid and the higher the payment back to them.
This auction method fixes the issue of attributing MEV to different addresses when a batch of transactions is sold.
In “Exclusivity Agreements” how can you determine which transactions generated the MEV and therefore which users should be compensated. Here we have a clear 1-to-1 mapping of Tx (user) to the price paid.
Whoever the auctioneer is in this model has a significant amount of power since they hold all the signed transactions.
While it would likely start as a centralised entity efforts would need to be made to decentralise/trust minimise that component.
Psyops
One other thing we could see with order flow auctions is builders making predictions based on the available unsigned transactions in the same way bots look at exchange order books.
Could entities spoof transactions in the auction to gain some advantage? It would be up to the wallet providers / auctioneer to prevent this from happening.
A Centralising Force
Let’s look at what happens when 1 builder has exclusive access to the majority of transactions on Ethereum.
Let’s say 20 builders have access to 300 Txs in the mempool. There is a single builder who has exclusive access to Metamask’s 700 Txs in addition to the 300 mempool Txs giving them 1000 Txs to build with.
The 1000 Tx block builder gets to build the majority of blocks. They have a larger search space from which to build a block and exclusive access to some of the value.
Slowly the block builders with mempool only access go out of business.
They’re not winning enough blocks. Any exclusive order flow agreements they may have had aren’t getting renewed or are being terminated.
How often a builder wins a block has a direct impact on their user’s experience, eventually, they are unable to compete, unable to operate at a profit.
Exclusive order flow is a very big risk and very big danger in the MEV space over the next couple years.
Hasu - Flashbots - Wintermute MEV Hackathon
A world where block builders compete on exclusive order flow is a world that gravitates strongly to a winner takes all effect occurring in block building.
MEV Dystopia
The image below is from Stephane’s MEV Utopia and Dystopia talk and highlights a decentralised MEV supply chain. The red block I have added represents the vertical integration that could occur via exclusive order flow.
Let's run a simulation where Metamask creates their own builder and see what could happen.
Metamask own 70% of the public order flow, they make this exclusive order flow to themselves and are able to quickly dominate the block building space.
Since they are dominating the block builds searchers have no choice but to send their bundles to the Metamask builder. If they don’t they’re only able to access MEV on the blocks their current builder wins which due to Metamasks dominance is a low percentage.
Metamask begins to build an internal searcher team who learns from the searcher order flow they have access to.
The internal searcher team gets to extract value from 70% of the Ethereum transactions with no competition while the external searchers are left to fight for the value in the remaining 30% in the mempool.
By dominating the builder space Metamask also gets to keep more of the MEV for itself rather than passing it on to the validator.
In a competitive market, margins are cut and the majority of value ends up in the validators hands.
In a monopoly, Metamask just needs to ensure their block build pays slightly more than the next best builder.
Very quickly Metamask has come to dominate the wallet, searcher & builder market.
How the community reacts would be interesting.
Likely Metamask would have to self-regulate in the same way mining pools and validator pools have had to.
The diagram below from Jon Charbonneau shows the feedback loop discussed above that can quickly lead to centralisation.
App Level Optimisations, Cross-Chain & CEX
There are lots of factors I haven’t touched on that will impact how this future plays out. Let’s briefly touch on each one and provide a high-level overview.
Application Optimisations
Decentralised applications such as Uniswap, Sushiswap, etc. have a huge incentive to reduce the MEV exposed by their protocol.
Ideally, they can capture the value for themselves and their users at the Tx origin.
A great example of this is the collaboration between Sushiswap & Manifold Finance (Manifold would like to be one of the main block builders post-merge).
Sushi is going to replace their “transaction router” with Manifolds “MEV router” at the protocol level.
The “MEV router” looks to capture arbitrage opportunities as the user makes the trade and return the value back to the protocol. You can read more about it here.
These application/builder relationships will be another area in which builders will compete.
Cross-Chain MEV
Cross-chain MEV is already occurring however we can expect it to get more competitive in the future.
Cross-chain MEV is non-atomic, has higher execution risk, involves inventory management and requires deep knowledge across multiple chains.
It, therefore, has a much higher barrier to entry.
Everything we have talked about is roughly mirrored on other chains. Image gaining access to Solana orderflow, Avalanche orderflow, etc.
The order flows on other chains will influence what can be done on Ethereum.
Increasing the search space of valuable transactions is always better for finding the highest value combination.
How big an impact this “other chain” order flow has on the builder network is yet to be seen but in an ultra-competitive environment it would provide an edge.
Centralised Exchanges
Like cross-chain MEV we are already seeing the on-chain/off-chain MEV opportunities be exploited.
With centralised exchanges, builders will have to minimise their latency through co-location and negotiate deals to get the lowest trading fee.
If one builder has negotiated a trading fee of 0.02% and another has a trading fee of 0.08% how does this impact the on-chain/off-chain opportunities available to them?
This will be another area in which builders can compete and try to find their edge.
An Unknown Future
Who knows how this future will play out, this is an active area of research that has lots of moving parts.
Stephane’s quote below captures the reality of the builder market but also the mission of the community to keep it as decentralised / flat as possible.
Ultimately it’s likely the builder marketplace is going to have some power law distribution where the top builders aggregate the majority of the proposal power but we want to keep this distribution as flat as possible.
Stephane Gosselin - Flashbots - Bankless
And who knows maybe there is light at the end of the tunnel.
Til next time
noxx
Follow me on Twitter @noxx3xxon
Great piece!!