Introduction

Upon reflection, my favorite presentations from the MEV workshop at SBC were Vitalik’s distributed builder, which I reference several times in this article, and @0xQuintus warning about the rise of exclusive order flow.

The former put forth several new possible iterations that enhance PBS, while the later articulated the negative externalities of exclusive order flow.

Both presentations served as an inspiration for this article. In addition this should also be considered a follow up or complementary pairing to my previous article, Sharding the Builder.

One final note to the reader before beginning. The article contains thirty-seven links. I recommend you check out these great resources.

Conjecture

Payment for order flow is the endgame state which constitutes a Nash equilibrium for all actors in the MEV supply chain.

Through this looking glass, we will review the speculative design space that iterates on Proposer Builder Separation with an eye on addressing the potential negative externalities through incentive alignment, protocol design, and cryptography.

PBS

One of the core design elements of PBS involves splitting the role of the block proposer, who signs a valid transaction payload containing the highest bid from a builder received via the relay, and block builder who aggregates searcher bundles in addition to transactions from the mempool. The proposer does not have visibility into the transactions or ordering of the block unless they constructed the block themselves. In Mev-boost the role of the relay is a trusted third party, in PBS the relay is replaced with a size-256 committee of validators.

PBS positions the role of the Builder as a highly specialized and resource intensive entity compared to a proposer allowing any at home validator to participate in MEV extraction, a significant feature. It should be noted that there are additional benefits to a centralized builder which advance the design space of danksharding and weak statelessness for example while making validators highly decentralized.

“Even though PBS can improve validator decentralization it does have this extra consequence that leaves builders very centralized.”

The separation of roles along with a shifting equilibrium in the MEV Supply chain, induced by the transition to POS, opens the door to exclusive order flow.

Why?

If there is a dominant builder producing a significant portion of blocks, say n > 50% of blocks, then searchers are likely to send bundles their way due to higher probability of inclusion. This dominant builder would also likely endeavor to acquire order flow directly from wallets bypassing searchers completely. The builder could also cut side deals (bribes) with searchers.

Any application or wallet like MM may be highly incentivized to sell their order flow as it would allow them to capture MEV for themselves and offer users rebates of sorts in the form of gas-less trading and/or improved fills on swaps.

In this hypothetical, MM would now have a significant advantage over their competitors and thus ignite an arms race; who can sell their order flow and provide users with the best margins? For example MM may capture 10% of their MEV-rebate and return 90% to users vs a competitor who may decide to go all in on user acquisition and return 100% of order flow to users. This would create an expectation and incentive, from newer users especially, to use the wallet that gives them the best execution guarantees but also the best MEV-rebate.

This type of user expectation lock in will be difficult to unwind and ultimately reinforce unacceptable builder centralization.

How decentralized does the builder need to be in order to keep the MEV supply chain competitive, with low barriers to entry?

In practice its difficult to say, but the notion of one builder or several cartels is less than desirable for preserving the maximum competition in the supply chain. This dominant builder would continue to capture MEV at a higher rate than others and likely use this dominance to build out economies of scale across multiple domains leading to entrenched centralized block production in the multi-chain world. This actor would also use their resources to perform CEX to DEX arbitrage, dominating all domains.

Wat do?

Walk in, see this, Wat do?

Order Flow Auctions

Perhaps we can design an auction mechanism where any Searcher can bid for order flow. This auction would allow searchers to act as “solvers” in a similar manner to Cowswap by simulating bundles of transactions with the best MEV-rebates either via gas-less trades or no slippage fills. In this scenario wallets would be agnostic of which searcher wins any given auction and would simply accept the best bid for their order flow.

If amenable to users, who could choose to opt in as they ultimately are the kingmakers of their order flow, The Order flow Auctions could pool all participating wallet provider’s order flow allowing for maximally competitive sequential auctions with optimal price discovery. Users opting out would send their transactions to the general mempool, TIL.

Another construction may have wallets host their own auctions in parallel, which could be more efficient for submitting bundles to the aggregator (builder).

OFAs may introduce additional DOS attack vectors, however this would likely not be in the best interest of the attacker as long as the MEV per bundle remains > opportunity cost of DOSing the network with low quality bundles.

Searchers could also post a slashable bond to participate in Order Flow Auctions. However bonds prohibit the OFAs from open and permission-less participation which is also a necessity. Requiring Searchers to build VDF towers is an interesting Sybil resistance mechanism.

Whilst wallets would be agnostic, they could also cut back door deals with searchers. Let’s recall, If the MEV opportunity >= cost of bribes for a targeted opportunity, the bride will always be attempted. A social reputation system of sorts would need to be established which transparently quantifies searcher/wallet relationships.

Another drawback is the auctions in theory could hyper accelerate builder centralization as all searchers would be likely to choose a builder who guarantees tx inclusion and pre-confirmations.

The Enshrined Builder

What if instead we enshrine a builder algorithm (see Vitalik’s presentation on the distributed builder) into the protocol that aggregates bundles from searchers. The enshrined builder would receive bundles encrypted to a threshold key from searchers, state access lists, and a SNARK proving correctness. The builder would then choose the total bid maximizing the disjoint set of bundles, merge them, and send the tx payload to the proposer. The state root would be computed after the proposer makes an off-chain commitment to the merged execution block to prevent MEV stealing by the proposer.

The enshrined builder (distributed) would be composed of a rotating subset of all opt in validators in the network. The enshrined builder is responsible for data availability of the merged bundles, erasure coding the execution block, and distributing chunks over a p2p subnet to all 256 committee members (relay role) who decrypt the chunks and pre-attest to the tx payload header. If the block is signed by 2/3 of committee and is the highest bid, the proposer accepts the tx payload (see single slot PBS).

Another alternative which parallels the idea I touched on in the Sharding the Builder article would be for the enshrined builder to host the searcher auctions sequentially and send those winning chunks to proposers which can be pre-confirmed upon sending to a proposer and aggregated by the proposer once they receive all chunks. Searchers could only send 1 encrypted bundle per slot, potentially mitigating DOS attack vectors.

If there is a latency issue for a particular block then the proposer would release their partially aggregated block with m/n bundles, or in extreme scenario miss their slot and fail to propose a block. This approach may be unacceptable for user experience depending on the implementation.

Transaction Inclusion List (crList)

TIL transactions could be included automatically as a TIL bundle by the enshrined builder or by the proposer, giving the proposer agency (see Sreeram’s presentation). This is feasible as over 80% of blocks produced today are not full.

Hybrid Searchers

The overlap between searchers and builders is inevitable as the race to become a dominant builder unfolds with the rise of exclusive order flow. If Searchers are sending bundles to an aggregator they are effectively building portions of the block. Not all searchers today have the skill-set required depending on their specialization. But as the Searcher and builder role overlap this type of construction emerges.

Long-tail Searchers

The alpha is in the Long-tail. Not all Searchers will be interested in OFAs (Order flow auctions) and instead focus on constructing smaller bundles. Searchers sending bundles below a specific threshold say 5M gas would need to send to another builder/searcher entity to be merged.

It is also possible for the enshrined builder to save a portion of the block say 5M gas for merged bundles from specialized searchers. This could help prevent a handful of larger searcher/builders dominating the market because they could be bypassed.

Another solution would be for Long-tail searchers to include TIL transactions in their bundles to be included regardless of gas threshold as long as all TIL txs are included.

Parallelism

Block-STM provides another potential complimentary option for parallel execution. Block-STM (software transactional memory) is a known parallel execution engine that optimistically executes chunks (txs) of a block concurrently.

“Parallel execution of the block must yield the same deterministic outcome that preserves block pre-order, exactly the same read/write sets as sequential execution.”

                           Txj → Txk

Since searcher bundles could be encrypted and provide access lists as described above, the invariant can be satisfied. However, the conflict rate for optimistic execution grows with demand for block space.

Unlike Block STM if searchers provide state access lists then disjoint bundles can be aggregated more efficiently.

Conclusion

• Exclusive order flow will likely accelerate builder centralization, as the current set of incentives suggest this.

• Order flow auctions combined with a distributed builder, enshrined or not, could allow for an incentive structure which creates maximum competition for user order flow by hybrid searcher/builders.

• The builder simply becomes an in protocol aggregator and eliminates the need for competing builders.

• OFAs could help unlock parallel execution starting with parallel order sequencing

Open Questions

• Is an enshrined builder feasible?

• Is there non dystopian equilibrium that doesn’t include payment for order flow?

• Are order flow auctions open or closed bid, sequential or run in parallel?

• How will account abstraction impact order flow?

• How do the externalities of Proto-DS, eg. cheap rollup txs, impact order flow?

• Does PFOF invite regulatory enforcement?