Paradigm New Article: MEV Tax and Prioritization

Original title: "Priority Is All You Need"

Original author: Dan Robinson , Dave White

Translation: Joyce, BlockBeats

Editor's Note:

On June 5, Paradigm's research director Dan Robinson and research partner Dave White published a research article proposing a miner's mineable value ( MEV) tax. This tax allows any application to capture its MEV while maintaining composability. The mechanism is now available on OP Mainnet, Base and Blast, as well as other OP Stack L2 platforms. The article proposes that smart contracts can capture MEV in transactions by charging a percentage of the transaction's priority fee.

The article also points out the limitations of the MEV tax, including that it relies on block proposers strictly following the competitive priority sorting rules, and that it may not work effectively on Ethereum L1. In addition, the article discusses how some of the shortcomings of the MEV tax can be mitigated by design, such as incentive incompatibility, full block problems, reverted transactions, leaking user intent, etc. BlockBeats compiled the article as follows:

Introduction

In this article, we will introduce the MEV tax, a mechanism that any application can use to capture its own MEV. This mechanism is now available on OP Stack L2 such as OP Mainnet, Base, and Blast, because block proposers on these chains follow a set of rules we call competitive priority sorting.

To impose a MEV tax on one of the chains, the smart contract charges a fee that is a function of the transaction priority fee. If the application charges $99 in MEV tax for every $1 in priority fee paid by the searcher, then it can capture 99% of the competing MEV for that transaction.

MEV taxes are a simple technique that opens up a vast design space. You can think of them as allowing any application on the chain to run its own custom MEV auction, without any off-chain infrastructure of its own, simply connecting to a single shared auction run by block proposers.

We lay out how MEV taxes can be used to solve three major problems in MEV research:

Decentralized Exchange (DEX) routers that optimize the prices received by exchangers;

Automated Market Makers (AMMs) that minimize the Loss and Rebalances (LVRs) experienced by liquidity providers;

Wallets that let users capture any “background” MEV created by their trades;

But there’s a catch. MEV taxes only work if block proposers strictly adhere to competitive prioritization rules, which include ordering transactions by priority fee and not censoring, snooping, or delaying any transactions. If block proposers deviate from these rules, they can evade MEV taxes and capture value for themselves. As a result, today, the MEV tax relies on trusted L2 collators, and may not work at all on Ethereum L1, where block construction is dominated by competitive builder auctions that maximize proposer revenue.

Nevertheless, the power and flexibility of the MEV tax suggests that prioritization may be the right choice for platforms that can currently offer this service. The relative simplicity of competitive prioritization suggests that there may be a viable way to enforce it in a decentralized manner without having to trust a single collator. We hope that this post inspires further research into this problem.

Priority Prioritization

When someone sends a transaction on Ethereum L1 or L2, they specify a priority fee, which is paid to the block proposer. You can imagine this being specified as priorityFeePerGas, a number that is multiplied by the Gas used in the transaction to get builderPriorityFee — the total payment expressed in ETH.

There is nothing in the Ethereum protocol that specifies that transactions in a block must be greedily sorted in descending priorityFeePerGas. However, this is a popular way to construct blocks - for example, it is the sorter of the OP Stack chain and the default algorithm used by geth and reth. Priority sorting not only allows transactors to effectively express the urgency of their transactions, but also naturally passes certain types of MEV to block proposers.

This happens because priority sorting turns the competition for MEV into a priority gas auction. When there is an opportunity to profit from interacting with a chain, such as arbitrage with centralized exchanges through an AMM, searchers will compete to get first dibs. If a chain uses priority sorting to determine transaction inclusion and ordering, searchers compete by setting high priority fees for their transactions.

In a competitive scenario where the risk-free profit is zero, the winning searcher should eventually pay the full MEV priority fee. So if there is a profit of 100 ETH to be gained by interacting with the contract, the first transaction to claim that profit will set a priority fee of 100 ETH. (We discuss some caveats in the limitations section).

MEV Tax

Suppose a smart contract wants to capture MEV from any transaction it interacts with. There is a ton of research on different application-specific ways that smart contracts can try to capture their own MEV.

But in fact, we don't necessarily need to know anything about the application. If we know that the block was built via competitive prioritization, then we have a general signal about the amount of MEV in a transaction: the priority fee.

We propose that a smart contract can look at the priority fee of a transaction and charge its own fee as some increasing function of it. For example, a contract might require the caller to transfer applicationPriorityFee = 99 * proposerPriorityFee in ETH to the contract.

This new fee is paid by the searcher sending the transaction, so it affects the behavior of that searcher. If there are 100 MEV in the opportunity, the winning transaction will now only set a priority fee of 1 ETH, because this will result in a total payment of 100 ETH (1 ETH paid to the block proposer and 99 ETH paid to the smart contract). Any higher priority fee will make the transaction unprofitable; any lower priority fee will result in losing the opportunity to a competitor that set a higher fee. This means that the smart contract has already captured 99% of the MEV in the transaction.

We call this additional fee imposed by the smart contract the MEV tax. The MEV tax allows applications to hijack priority sorting for their own benefit, allowing them to recapture MEV for their users rather than leaking it to block proposers.

If this fee grows quickly enough as a function of priorityFeePerGas, then proposers will receive only a negligible amount of MEV. Since priorityFeePerGas is denominated in wei (one billionth of 1 ETH), we have a lot of precision to work with. For example, as long as the MEV tax is sensitive enough, a priorityFeePerGas of 50,000 will result in an excessively high tax, and the total amount paid to the proposer will be less than $0.01. (5)

However, there is an important caveat. As discussed in the “Limitations” section, the MEV tax only works if block proposers follow certain rules (which we call “competitive priority ordering”), and do not deviate from those rules to maximize their own revenue. Enforcing these rules in a trustless manner is an open problem.

Single-Application MEV Capture

Here, we outline how, on chains that guarantee block construction using competitive priority ordering, the MEV tax can be used to mitigate three important problems in MEV: allowing DEX interfaces to improve trade execution for exchangers, allowing AMMs to reduce arbitrage losses for their LPs, and allowing wallets to reduce users’ MEV leakage by selling users’ back-run rights.

Decentralized Exchange Routers

In intent-based DEX routing protocols like UniswapX and 1inch Fusion, a user (Alice) signs an intent to swap, and Seekers compete to route or fill that intent for Alice at the best price.

The current version of UniswapX uses two mechanisms to conduct competition: a Dutch auction, where Alice’s limit price changes over time until it is filled by Seekers, and an initial off-chain Request for Quote (RFQ) auction, which is used to set the starting price of the Dutch auction.

On a platform that guarantees competitive prioritization, UniswapX can replace these mechanisms with a single one: the MEV tax. It can do this by having users sign orders that can be filled instantly by anyone, but the execution price is set as a function of the priority of the trade.

For example, if Alice has a UniswapX order to sell 1 ETH, she could define the execution price of her order to be minimumPrice + ($0.01 * priorityFeePerGas). The minimumPrice might be some fixed value that she expects to be significantly lower than the current price.

Searchers will compete to fill Alice's order by submitting transactions. Whichever transaction has the highest priority fee and does not revert will fill the order, which should guarantee that the exchanger gets the best price the searcher can find. (Some exceptions are discussed in the "Limitations" section.)

If Alice's minimum price is $3,000, and the current price of ETH is $3,500, then the priorityFeePerGas in the winning transaction is about 50,000. (Note that in a transaction costing 200,000 gas, this would result in a payment of only about 10 billion wei (~$0.000035) to the block proposer.)

This has several potential benefits over the existing mechanism used in UniswapX.

Orders using the MEV tax can be filled faster and at a better price than orders using a Dutch auction. As discussed in the paper, on-chain Dutch auctions leak some value into MEV due to price movement between blocks, and can take many blocks to complete. In contrast, orders using the MEV tax can often be completed in the next block while capturing the vast majority of MEV.

Unlike off-chain asks, auctions for orders using the MEV tax will occur automatically when on-chain trades are executed. This means that the winning bidder is guaranteed to only commit to filling the order if the on-chain trade is successful. This can make it easier for on-chain liquidity such as AMMs to compete with off-chain liquidity, meaning UniswapX can act as a more efficient router for multi-pool systems such as Uniswap v4.

AMMs

Typically, AMMs leak value to arbitrageurs who trade against outdated prices at the top of the block, as discussed in the Losses and Rebalancing paper. We can use a MEV tax to allow AMMs to capture MEV. For simplicity, we’ll discuss how this works on AMMs without concentrated liquidity. (If you’re interested in how this sort of problem can be solved with concentrated liquidity, Sorella will be publishing a solution soon.)

AMMs can capture MEV by charging an additional fee as a function of a transaction priority fee, allowing them to auction the right to be first in a block. There are multiple ways to calculate and denominate this fee. We’ll discuss one that is arguably neutral — in units of pool liquidity, sqrt(xy). The winning transaction will be the one that increases the pool’s liquidity the most.

When the first transaction is executed on the pool in a block, instead of enforcing the condition x_end * y_end > x_start * y_start , the pool can enforce the condition (with a as some constant):

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2

This formula will incentivize arbitrage traders to trade at the real price, and after that transaction, the midpoint price in the pool should be the real price.

After the first trade, trades can proceed just like on Uniswap v2, with a fixed swap fee. Uninformed traders who want to trade in the pool without paying the additional MEV tax will have a lower preferred fee set.

There are many other ways to implement a MEV tax on an AMM that would have different effects. For example, the MEV tax could be denominated in the input or output tokens of a swap, could affect the swap fee percentage applied by the pool, or could establish a minimum price for users to trade. We think this is an interesting design space to explore.

Reverse Auctions

The above description shows how some applications can be designed to avoid MEV leakage. However, what if a wallet wanted to try to help users capture the MEV they create from arbitrary transactions interacting with any application, even those that do not include a MEV tax?

For example, when Alice makes a large trade on an AMM, she sometimes creates arbitrage opportunities for “backrunners” that pull the price back. This is typically leaked to MEV, not to Alice.

MEV-Share and MEVBlocker are two protocols that allow users to capture MEV from trades, but they rely on complex off-chain auction systems. The order flow auction design space describes some other solutions.

The MEV tax combined with intent-based smart contract wallets allows us to build an alternative system to capture MEV for Alice from backrunning. Suppose that Alice does not create a transaction to make a trade on the AMM, but instead signs an intent that anyone can submit to Alice’s smart contract wallet to have it take that action. Alice’s smart contract wallet charges a MEV tax to anyone who submits that transaction, which is paid to Alice.

The backrunner who submitted Alice’s intent would have the exclusive right to backrun her, because they can do so automatically in the same transaction. Therefore, if the search is competitive, then all of Alice's profits should accrue to Alice via the MEV tax.

Note that this system does not necessarily protect users from attacks involving front-running a user's transactions, as the front-running user's transactions might be able to avoid paying the MEV tax to that user. This issue (and some possible mitigations) is discussed in more detail in the Limitations section below. Nonetheless, this can at least be an improvement over systems that use a public mempool and do not have any mitigations.

Other Use Cases

Beyond these examples, other potential uses for the MEV tax could include pretty much anything that currently uses off-chain or Dutch auctions, such as:

Protocols where oracles capture the oracle-extractable value of their creations, such as Oval;

Refinancing auctions for NFT collateralized lending protocols like Blend;

Lending protocols where liquidations have less leakage value than Dutch auctions;

Cross-Application MEV Capture

The above solutions are designed to capture MEV interactions with a single application. But sometimes a seeker might be able to extract more value by interacting with multiple applications in the same transaction.

If only one of those applications has a MEV tax, then all MEV in the transaction should go to the application with the MEV tax, no matter how high or low the MEV tax is.

But what if the seeker’s transaction interacts with two applications that use the MEV tax? For example, what if there is some MEV that can only be captured by filling one of the above MEV-taxed UniswapX orders against an AMM that pays the MEV tax?

In this case, the relative amount of excess MEV captured by each application depends on how those applications set their MEV taxes. If the value app_i taken as MEV tax is given by the function tax_i(priority), then the priority of the winning transaction can be determined by solving for the priority in the following equation: tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV (technically we could add a third term for priorityPerGas * gasUsed to account for the priority fee paid to the block proposer, but we will ignore this as it is probably negligible in normal circumstances) In the simple case where the MEV tax is linearly related to priorityPerGas (so tax_1(priorityPerGas) = a_1 * priorityPerGas), you can solve for the share of MEV received by each application:

a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Applications face a tradeoff when setting their own MEV tax - a higher tax lets it get a larger share of cross-application MEV when it occurs, but it means it may miss out on some cross-application MEV if there are competing ways to extract it. For example, if there is an AMM that charges a MEV tax on every trade, then a MEV-taxed UniswapX order might be more likely to be filled by a different AMM or off-chain filler.

In many cases, there may be an equilibrium where two applications design their MEV taxes so that MEV is shared in a way that maximizes their respective profits. For example, a MEV-taxing AMM may want to extract value from a single informed trader near the top of a block, but then want to provide liquidity to other traders and applications (including applications using the MEV tax) at a lower fixed rate fee. In this case, the AMM might set a relatively low MEV tax (e.g. $0.00001 * priorityFeePerGas) so that arbitrage trades (if any) occur early in a block, and then charge no MEV tax on subsequent transactions in the block. An application like UniswapX that wants to interact with the AMM could set a higher MEV tax (e.g. $0.01 * priorityFeePerGas) to ensure that its trades are included after the pool has already arbitraged. Given these relative taxes, the AMM will eventually be arbitraged first even if there is only $1 of MEV and $50,000 of MEV in the UniswapX order book.

We think this is a broad design space worthy of future research.

Limitations

The MEV tax has several complexities and shortcomings that we think are interesting areas for future research.

Incentive Incompatibility

MEV taxes are not incentive compatible for monopolistic block proposers. They only work if there is fair competition for transaction inclusion, and this only happens if block proposers follow a rule we call "competitive prioritization" rather than maximizing their own revenue. Informally, some suggested rules include but are not limited to the following:

Priority ordering. Transactions within a block must be sorted in descending order of priorityFeePerGas.

Censorship resistance. If a block proposer receives transaction t1 during a block, and the block is not full or contains some transaction t2, such that t2.priorityFeePerGas < t1.priorityFeePerGas, then the block must include transaction t1.

Pre-transaction privacy. Block proposers must accept transactions through a private endpoint and may not share such transactions with anyone else before submitting them to a block, or use the contents of these transactions as input to construct their own transactions.

There is no final censorship. Block proposers must set a clear block time before which they accept transaction requests from anyone and after which they no longer accept transaction requests from anyone.

Violating one or more of these properties may undermine the effectiveness of the MEV tax. Block proposers who violate censorship can avoid most MEV taxes by excluding competing transactions and submitting zero-priority transactions that benefit themselves. Block proposers who violate pre-transaction privacy can steal MEV from other transactions or look at their priority fees to know exactly how high they need to set their fees, while block proposers who are able to submit transactions later than others will get a free "last look" at whether to outbid others, both of which may create adverse selection problems and ultimately hinder competition.

Unfortunately, while the first property is easy to enforce at the protocol level, enforcing the others in a trustless manner is an open problem.

In the absence of enforcement at the protocol level, a single sequencer that commits to these rules needs to be trusted not to deviate from them, and if proposers outsource block construction to a competitive revenue maximization auction (such as Ethereum L1's MEV-Boost), blocks may not follow them.

These problems can be "solved" by a single trusted sequencer that commits to using competitive priority ordering for block construction. They can also be solved through decentralized mechanisms using some combination of consensus, cryptography, and/or trusted execution environments, such as Sorella's Angstrom, Flashbots' SUAVE, leaderless auctions, or multiplicity.

Full Blocks

One exception to the normal operation of the MEV tax occurs when a block is completely full. In this case, block proposers may have to discard lower priority transactions rather than simply include them in the block. Since transactions that interact with MEV tax applications may have extremely low priority fees, these applications may be squeezed out by applications that do not use the MEV tax or have extremely low MEV taxes. However, in a chain that uses a mechanism like EIP-1559 to set a separate base fee, the situation where a block is completely full should be relatively rare. Furthermore, given that some transactions need to be delayed when a block is full, delaying transactions that represent lower urgency by setting a higher MEV tax may be a reasonable outcome.

Reverted Transactions

The MEV tax actually relies on single-block auctions, where each "bid" is a transaction. One drawback of these auctions is that failed bids often result in the reverted transaction being included on the chain, paying some base fee and causing chain congestion.

If the sorter could exclude failed transactions entirely, this would mitigate this problem, although this is difficult to achieve even with a centralized sorter. (It would also not strictly adhere to the censorship-resistance property described above, although that definition could be tweaked.) More sophisticated sequencers could optimize this process by allowing transactions to specify which contested auctions they are participating in, giving the sequencer enough information to skip subsequent transactions that it knows will fail.

Leaking User Intent

The MEV tax only works if there is competition between searchers, which means that the opportunity needs to be known to some degree. For applications like AMMs, where the opportunity is visible on-chain, this should happen naturally. But for applications like intent-based routing or backend auctions, this means that the application may need to share the user’s intent with the searchers.

In some cases, the temporary loss of privacy incurred by broadcasting a user’s intent before it is fulfilled can leak value in ways that the MEV tax cannot recover.

For example, suppose Alice wants to buy a low-liquidity token using the backend auction protocol described above. She publishes a signed intent to the smart contract wallet to buy that token on the AMM, setting a certain slippage tolerance. Seekers can compete in high-priority transactions to drive the price of that token up to her slippage tolerance without filling the user's order. The winner, Bob, can then satisfy Alice's intent in a non-competitive manner by including it in a low-priority transaction and running it in reverse, thereby sandwiching Alice's transaction and giving her a worse price while evading her MEV tax. Similar problems can occur with NFT purchases.

Note that such an attack is risky for Bob, as he cannot guarantee atomicity between buying a token and selling it to Alice. A naive Bob could fall into a “pinch-and-tear” trap: Alice posts an intent to buy a worthless token from herself, Bob buys the token in order to pinch her transaction, but Alice withdraws her intent before Bob can complete the pinch.

Applications can also mitigate this by limiting the set of searchers with which they share an intent and monitoring their behavior, as many existing order flow auctions do.

It is also possible to combine a MEV tax with a privacy-aware builder function, as envisioned by Flashbots for SUAVE.

Finally, if Alice decides that the cost of sharing an intent outweighs the benefits of competitive searching, she can construct a transaction herself and submit it directly to the block. As described above, an ideal implementation of competitive prioritization would provide pre-transaction privacy to block proposers.

Related Discussion

Priority gas auctions. The Flash Boys 2.0 paper, which coined the term “miner extractable value,” examined some of the dynamics of priority ordering in decentralized blockchains. The paper noted that Ethereum miners (when the network used proof-of-work) already prioritize transactions, and that arbitrageurs rely on this behavior to participate in “priority gas auctions” in which they bid for the right to be included in the first block, which results in the majority of MEV arbitrage on decentralized exchanges going to miners.

First-come, first-served. Some attempts to mitigate MEV through transaction ordering rules, such as the current sorter for Themis or Arbitrum One (7), focus on enforcing a different ordering rule, first-come, first-served (sometimes called “fair ordering”), where block proposers must order transactions in the order they see them.

Priority ordering takes a different approach—treating transactions that arrive in a given time period equally and ordering them by their declared priority.

First-come, first-served is difficult to enforce or even define in a real network environment with multiple validators. Even with a single trusted sorter, it can lead to wasteful latency contention and spam. Finally, a MEV tax may be able to eliminate certain types of MEV that first-come, first-served sorting cannot, such as arbitrage profits from discontinuous "jumps" in asset prices. The potential advantage of priority sorting over first-come, first-served sorting is somewhat related to the advantages of discrete-time over continuous-time exchange discussed in Budish, Cramton, and Shim (2015).

Meanwhile, while prioritization by default appears to leak value to MEV, this post shows how applications can be designed to recapture it.

Fee Sharing. Blast is an Ethereum L2 that shares a portion of the priority fee and base fee with smart contracts accessed in transactions.

MEV taxes allow something similar (at least for the priority fee), but can be implemented at the application layer on any chain that uses competitive prioritization, without requiring special support for fee sharing. They also allow applications to define their own taxes as custom functions of the priority fee, allowing greater flexibility and potentially increasing the composability of MEV-aware applications.

Trustless Solutions. This post focuses on the motivations for platforms to use competitive prioritization and ways to leverage it, rather than discussing how to enforce it in a trustless manner.

Each of the other properties required for competitive prioritization has been discussed previously. For example, in Fox, Pai, Resnick (2023), the authors discuss the vulnerabilities of on-chain auctions in the absence of censorship resistance and describe a design for censorship-resistant auctions using multiple concurrent proposers. However, they do not recommend a specific ordering of transactions.

There is other research on building trust-minimized block construction mechanisms, including Flashbots’ SUAVE, Sorella’s Angstrom, Leaderless Auctions, Espresso and Offchain Labs’ decentralized Timeboost, and Péter Szilági’s Forced Public Transaction Inclusion.

We hope that this post encourages L2 to consider using prioritization (which the OP stack supports by default), and encourages applications to try MEV taxes if they support it. We also hope that it inspires further research on trust-minimized competitive prioritization protocols on both L1 and L2.

「 Original link 」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia