A New Architecture to Mitigate MEV

tldr;

• Status quo:
• Transaction reordering MEV is bad. MEV from censorship or arbitrary inclusion is equally bad. If the dYdX Chain can’t prevent both kinds, the playing field could be tilted in a way that harms liquidity and price formation.
• Solution:
• Use Cosmos’s ABCI++ vote extensions for collaborative block building and introduce frequent batch auctions (FBA) to neutralize transaction sequence effects.
• Process:
• Validators vote on order inclusion before a block is produced, the block proposer runs an auction with majority-backed orders, and validators verify the results, which are deterministic, unlike proposer-led block building.
• Benefits:
• Proposers can't unilaterally control inclusion (no inclusion MEV), order sequencing doesn’t matter (no reordering MEV), and proposer colocation is less valuable (the latency race is more fair). Positive externalities of high-frequency maker-taker competition manifest through price improvement, not value leaked to proposers.

Overview

The initial version of the dYdX Chain employs a social mitigation strategy to curb maximal extractable value (MEV). In this post geared toward technical readers, we’ll propose a new design for order matching and consensus which eliminates transaction reordering and censorship MEV.  This is a more robust solution which helps further level the playing field for traders on the dYdX Chain.

MEV in order-driven markets

Before delving into our proposed architecture, it's essential to understand the kinds of MEV that are most important in order-driven markets.

MEV arises when block proposers change transaction inclusion and order to their benefit. Much has been said about reordering MEV, but arbitrary inclusion is just as important, especially in order-driven markets.

Indeed, we expect a large fraction of MEV to derive from CEX-DEX arbitrage, and more generally from competition between sophisticated makers and takers, which is sensitive to inclusion guarantees. The protocol must ensure that this competition is fair and results in deep liquidity at reasonable prices.

Although solutions like Flashbots MEV-Boost foster fair competition, they also risk creating a two-tiered order submission system. This system diverts value away from the protocol towards block proposers. Ideally, makers and takers should compete solely on order prices, not on privileged access costs, thereby channelling value exclusively towards liquidity and price formation.

Think of order-driven markets as a game between high-frequency makers and takers:

1. Makers compete to be first in line to offer liquidity at good prices, and to react first when prices change.
2. Takers race with each other to trade against mispriced orders before makers are able to cancel.
3. This race occurs countless times per second, all day, every day. Small changes in winning odds result in large profits or losses.

In this context, MEV may involve proposers subtly tipping this competitive balance, which is perfectly achievable even without granular transaction reordering. This is why our MEV solution must go beyond the prevention of sandwiching.

To see why, consider what a malicious proposer can achieve purely through the censorship or arbitrary inclusion of transactions.

The importance of censorship and arbitrary inclusion for MEV

When building a block, a proposer typically has the power to censor transactions or include new ones at the last instant.

For any block, there is a public transaction submission deadline followed by a period where only the proposer can act. During this interval, proposers can exploit arbitrary inclusion power to act on new information first, inserting transactions into the block to trade against stale orders.

Worse still, a taker permitted to censor competing taker orders or maker cancels could extract even more MEV from stale orders. And a maker with the same power would have the option to withdraw from unfavorable trades just before broadcasting a block.

Given these challenges, curbing MEV requires a mechanism that does not concede unilateral censorship and inclusion powers to proposers.

Solution: collaborative block building and frequent batch auctions

Our solution has two components:

1. Collaborative block building. Typically, a proposer has sole responsibility for a block’s contents, which makes it impossible to prevent MEV from censorship or arbitrary inclusion. Cosmos’s new ABCI++ includes a feature called vote extensions, which allows multiple validators to jointly decide a block’s contents.
2. In Frequent Batch Auctions (FBA), orders are grouped together in batches. Each batch undergoes an auction and a single uniform price is chosen to maximize traded volume. Orders whose limit prices cross the uniform price are matched by price priority. If multiple orders share the same price, they participate in trades pro-rata. The key advantage for MEV mitigation is that the sequence in which transactions arrive doesn't influence how they're matched.

In our proposed architecture, the process of building a block at height h and settling trades is:

1. At block height h - 1, validators sign vote extensions containing hashes for each order seen to match in the FBA ending at vote extension time.
2. The proposer of block h includes ≥ 2/3rds of vote extensions by stake weight, which is the same proportion needed to approve a block. These are the “included” vote extensions.
3. For block h, the proposer runs a FBA. They include an order only if its hash appears in over half the included vote extensions by stake weight, then add all trades to the block.
4. Since block h’s trades result deterministically from the included vote extensions and the underlying orders, each validator can verify the computation independently.

This algorithm has various implementations with different tradeoffs. For example, one variation reduces the size of vote extension data but introduces a slight delay. If the FBA is defined to end at block proposal time, instead of vote extension time, and the proposer at h - 1 references orders for inclusion in block h’s auction, validators can then vote yes/no on the proposed orders with a series of 0 or 1 bits, and only include full hashes for orders excluded by the proposer. The optimal implementation will ultimately depend on the performance characteristics of vote extensions.

Properties

This architecture provides the following benefits:

1. The proposer does not have unilateral control over inclusion. Any order referenced in ≥ 2/3rds of all vote extensions is guaranteed inclusion, and any order not referenced in at least 1/3rd cannot be included.
2. High-frequency makers and takers still compete amongst themselves, but they compete on price, to the benefit of other market participants.
3. The value of colocation with the proposer is greatly reduced. Winning the latency race means disseminating a transaction to a majority of the network, not just one participant.
4. In the same vein, this design disrupts order submission timing games — since the time it takes for a transaction to reach 2/3rds of the network is inherently variable — which improves the visibility of the market state throughout the auction. This has a similar effect to
5. the London Stock Exchange’s randomization of auction timing

Looking ahead

As vote extensions enter the Cosmos ecosystem, we're excited to roll up our sleeves and prototype this architecture to understand its impact on trading beyond MEV, before recommending it for adoption by the dYdX Chain. Our commitment remains unwavering: to continually assess challenges facing the dYdX Chain and tackle them head-on. Onwards.

Disclaimer and Terms

This document may provide information with respect to the default settings of dYdX Trading Inc. (”dYdX”) v4 software (”dYdX Chain”) or non-mandatory guidelines and suggestions that may help with using v4 software. dYdX does not deploy or run v4 software for public use, or operate or control any dYdX Chain infrastructure. dYdX is not responsible for any actions taken by other third parties who use v4 software. dYdX services and products are not available to persons or entities who reside in, are located in, are incorporated in, or have registered offices in the United States or Canada, or Restricted Persons (as defined in the dYdX Terms of Use). The content provided herein does not constitute, and should not be considered, or relied upon as, financial advice, legal advice, tax advice, investment advice or advice of any other nature, and you agree that you are responsible to conduct independent research, perform due diligence and engage a professional advisor prior to taking any financial, tax, legal or investment action related to the foregoing content. The information contained herein, and any use of v4 software, are subject to the v4 Terms of Use.