Part I of this MEV Series focused on blockspace markets across ecosystems, specifically:
The rise of MEV on Ethereum, R&D efforts around incentivizing decentralization and competition in these markets.
The proliferation of PBS (proposer-builder separation) across ecosystems including Solana and Cosmos.
An overview of distinct approaches to MEV-related challenges that we see emerging within these various ecosystems.
Part II will focus on the order flow side of the market, specifically: providing a framework for thinking through the challenges associated with extracting value from user order flow, exploring technical & design implications of these challenges, and finally highlighting promising R&D efforts, as well as outstanding challenges.
Framing the Problem: Extracting Value
Just as value can be extracted through auctioning off privileged access to blockspace, the same is true for order flow. This extraction can take a direct form, such as searchers bundling user transactions into sandwiches, or a more indirect form, where information asymmetries are acquired through exclusive access to order flow.
When thinking through the problems associated with this value extraction, it’s important to note that not all order flow is created equally. For example, we know from TradFi that professional market makers and high-frequency trading firms are willing to pay a premium for exclusive access to non-toxic retail order flow. This reality creates a scarcity dynamic that mirrors the other end of the MEV supply chain, where blockspace is generally abundant but market participants are willing to pay a premium for blockspace that is perceived as “more secure” or ”higher quality.” It goes without saying that scarcity dynamics such as these tend to foster intense competition, which if unchecked, can lead to intense centralization.
The reality is that order flow originators (users/wallets/dApps/RPCs) all want a cut of MEV extracted from order flow and should be expected to exercise whatever leverage they posses to (1) monetize their access to order flow (2) limit the access of perceived competitors. Some obvious and highly plausible examples of how this might manifest include:
Users/Wallets/dApps/RPCs selling exclusive order flow to a single trusted builder (or small set of trusted builders)
Users/Wallets/dApps/RPCs vertically integrating (opting to control some other part of the MEV stack, i.e. operating a builder and/or proposer node)
Out of all the problematic vertical integration scenarios outlined in this fantastic post on the topic, Builder-Validator collusion stands out as the most likely, primarily due to the immense value of privacy and inclusion guarantees in what is becoming an increasingly complex and specialized MEV supply chain. Not only this, but as Flashbots has demonstrated, creating trust-minimized and decentralized methods for achieving such guarantees is no trivial feat.
Ultimately, the major challenge of order flow extractable value is the same as MEV more broadly – identifying and designing for some incentive aligned equilibrium where:
Users receive the best UX, execution & routing
Validators (including smaller, long-tail) are sufficiently compensated
Rent seeking (between the points of tx origination and inclusion) is minimized
Centralizing forces are mostly tamed and kept at bay
This has several implications worth exploring from different angles.
Implications: The MEV-aware design space
Design Philosophy
After accepting that some amount of MEV is inherent to (truly decentralized) blockchains, the next important step is to decide which of the following design philosophies to work with (not mutually exclusive):
Capture + Redistribute → extract as much MEV as possible, then decide how to redistribute those profits.
Mitigate → reduce the extent to which MEV can be captured as much as possible (typically uses privacy-enhancing technologies, discussed further below).
Leverage → aligning the incentives of MEV supply chain actors to (especially searchers & builders) to provide order flow originators with optimal routing & best execution (especially for complex, expressive transactions preferences).
As noted above, these philosophies are not mutually exclusive, as projects like Osmosis are experimenting with features like threshold encryption (mitigate) and protocol-owned-builders (capture + redistribute). Future iterations of this series may explore the trade offs across these approaches.
Technical Design
Although there is an ever-growing number of MEV-related experiments being run in the wild, the focus here will be on two major, overarching technical designs for addressing order flow value extraction: OFAs & PETs.
Order Flow Auctions (OFAs)
Before digging into OFAs specifically, it is worth reiterating the importance of auctions in facilitating democratized access to MEV (and public goods in general) and highlighting why getting auction design right is of critical importance:
On Auction Fairness → Many people think of the web2 analog to MEV as being high-frequency trading (HFT), however given the increasingly critical role of auctions in the MEV supply chain, advertising auctions may be a better analogy. If you doubt this, look no further than the masters of auction manipulation: Google & Facebook, two of the most profitable companies of the last twenty years. In January of this year, the DOJ announced a landmark lawsuit against Google for “anti-competitive auction manipulation,” specifically accusing the tech giant of abuses such as “limiting real-time bidding on publisher inventory to its ad exchange,” and “manipulating auction mechanics across several of its products to insulate [itself] from competition.” Given this, the failure of MEV auction providers to credibly decentralize should be considered a genuine risk given that the government has actually demonstrated a meaningful level of sophistication in understanding and adjudicating these issues.
On Best Execution → It’s worth keeping in mind that part of the reason why business models such as payment for order flow (PFOF) are even legal in TradFi is because there are legal requirements around providing users with “best execution.” In addition to registering with the SEC, broker-dealers also have to provide the SEC with quarterly reports on how client orders are being routed, while FINRA (Financial Industry Regulatory Authority) conducts regular audits of these firm’s reported best execution practices. The key implication here is that viable designs for MEV auctions and routing systems must carefully consider what it means and looks like to provide users with best execution. We could (but won’t) dedicate an entire series to exploring the problems with how financial regulators measure and enforce these “best execution” policies, however the general point still holds. This is also what makes crypto-native approaches such as DFlow, which provide users with cryptographic guarantees around best execution, so exciting.
Back to OFAs…
When it comes to the specific problem of monetizing user order flow, OFAs have emerged as a dominant design for auctioning off the right to execute user orders and facilitate MEV capture & redistribution to originators.
OFAs come in various flavors, each with distinct design trade offs around considerations such as how access/participation is permissioned, types of orders supported, information disclosure, bid selection process, and more. However, in a recently published deep-dive into the OFA design space, Stephane & Ankit highlight four primary design implementations which they expect to become dominant:
It’s safe to say there is (currently) no single best “one-size-fits-all” approach to OFA design, however it is easy to see how:
RFQ + Batch auctions → may be particularly attractive to professional market makers, considering the emphasis on last-look privileges and/or avoidance of toxic flow.
Trusted Execution Environments + Blockspace aggregators → may be particularly attractive to end-users and/or user-facing applications that are willing to pay a premium for reliable inclusion guarantees to make UX as smooth & seamless as possible.
Privacy-enhancing technologies (PETs)
Despite the name, privacy-enhancing technologies in this context are less about preserving privacy as an end goal, and more about bringing the cost of collaboration (not collusion) down as much as possible.
A crude example of this which exists in production today would be the Flashbots Relay, which as a trusted piece of infrastructure, plays a key role in enforcing the integrity of blockspace auctions – specifically fair payload routing for builders, and block validity, accuracy and DoS protection for proposers.
With the unveiling of SUAVE, Flashbots has also begun invoking the concept of “programmable privacy,” which (1) acknowledges the trade off space between privacy (low info disclosure) and efficiency / execution quality (2) aims to create flexibility and optionality within that trade off space.
Some popular & commonly discussed PETs include:
Trusted Execution Environments (TEE) → allows for running computations on private data inside a secure enclave, such that these computations cannot be accessed by anyone or anything except for the enclave itself. What happens in the enclave stays in the enclave. TEEs can be used for everything from simply running trusted portions of applications, to whole applications, to whole virtual machines. Intel’s SGX is one of the most popular and widely used TEEs, and will actually be used in the initial implementations of SUAVE to support an encrypted mempool.
Multiparty Computation → allows for splitting input data into different shares and applying operations to those shares before recombining to obtain some result. Secure MPC implementations are being explored for a number of use cases, perhaps most notably distributed block-building.
Fully Homomorphic Encryption → makes it possible to perform arithmetic operations on ciphertext and receive the same outputs as running the sequence of operations on plaintext. FHE is currently less accessible to the average developer, as it requires expressing problems as circuits, but does provide desirable security assumptions (believed to be post-quantum secure). Most importantly, FHE may be a very powerful tool for navigating the privacy-execution trade off space.
Final Thoughts
It would be a profoundly reactionary goal - and against the ethos of crypto - to simply recreate the same norms and power dynamics of TradFi with crypto assets. Even worse would be to leverage the most undesirable aspects of both crypto and TradFi (re: Arbitrum sequencer latency wars) without genuinely attempting to build something fundamentally better.
Designing and building provably fair and decentralized auctions, especially around user order flow, will undoubtedly be one of the major challenges for crypto finance over the coming 12-18 months. However, the implications of success here extend far beyond narrow conceptions of MEV and crypto finance.
Huge thank you to Tarun, Tom & Nitesh for reviewing this piece & providing thoughtful edits.
If you’re thinking about or building in any of these verticals, want to chat or collaborate on further writing, feel free to reach out via DM or to natalie@volt.capital!
Citations
Toxic Order Flow – https://deepwaters.xyz/learn/toxic-order-flow
The Orderflow Auction Design Space – https://frontier.tech/the-orderflow-auction-design-space
Distributed Block Building – https://github.com/flashbots/mev-boost/issues/139
The Joys and Challenges of Adopting PETs – https://www.youtube.com/watch?v=4iy8zSl96Ck
Order flow, Auctions & Centralization – https://www.youtube.com/watch?v=ilc3EoSMMDg
Why Privacy in MEV – https://www.youtube.com/watch?v=cJ_c-69neUQ
Encrypted Mempools – https://www.youtube.com/watch?v=XRM0CpGY3sw
Privacy Tradeoffs – https://www.youtube.com/watch?v=ueZMJHGsQzc&t=493s
Justice Department Sues Google for Monopolizing Digital Advertising Technologies – https://www.justice.gov/opa/pr/justice-department-sues-google-monopolizing-digital-advertising-technologies
