Paradigm New Article: MEV Tax and Prioritization

Authors: Dan Robinson, Dave White

Compiled by: Joyce, BlockBeats

Introduction

In this article, we will introduce MEV tax, a mechanism that arbitrary applications can use to capture their own MEV. This mechanism is now available on OP Stack L2s such as OP Mainnet, Base, and Blast, as the block proposers on these chains follow a set of rules we call competitive priority ordering.

To impose an MEV tax on one of these chains, a smart contract will charge a fee that is a function of the transaction priority fee. If an application charges a $99 MEV tax for every $1 priority fee paid to the searcher, it can capture 99% of the competitive MEV from that transaction.

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

We outline how to leverage MEV tax to address three major issues in MEV research:

• Decentralized exchange (DEX) routers can optimize the price received by the trader;
• Automated market makers (AMM) can minimize the losses experienced by liquidity providers due to rebalancing (LVR);
• Wallets can allow users to capture any "backrunning" MEV created by their trades;

But there is a problem. MEV tax only works if block proposers strictly adhere to competitive priority ordering rules, which include sorting transactions by priority fee without censoring, front-running, or delaying any transactions. If block proposers deviate from these rules, they can evade MEV tax and extract value for themselves. Thus, today, MEV tax relies on trusted L2 sorters 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 MEV tax suggest that for platforms currently able to provide this service, priority ordering may be the right choice. The relative simplicity of competitive priority ordering indicates that there may be a viable way to enforce it in a decentralized manner without having to trust a single sorter. We hope this article inspires further research into this issue.

Priority Ordering

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

The Ethereum protocol does not mandate that transactions in a block must be greedily sorted in descending order of priorityFeePerGas. However, this is a popular way to build blocks—for example, it is the default algorithm used by the sorters of OP Stack chains as well as geth and reth. Priority ordering not only allows traders to effectively express the urgency of their transactions but also naturally passes certain types of MEV to block proposers.

This happens because priority ordering turns the competition for MEV into a priority gas auction. When there is an opportunity to profit from interactions with the chain, such as arbitraging between an AMM and a centralized exchange, searchers compete to get ahead. If the chain uses priority ordering to determine which transactions to include and how to sort them, searchers compete by setting high priority fees for their transactions.

In a competitive scenario where risk-free profit competition is zero, the winning searcher should ultimately pay the full MEV priority fee. Therefore, if a profit of 100 ETH can be obtained by interacting with a 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 interacting with it. There is a wealth of research on different specific applications that smart contracts can attempt to capture their own MEV.

But in fact, we do not necessarily need to know anything about the application. If we know that the block is built using competitive priority ordering, then we have a universal signal about the amount of MEV in the transaction: the priority fee.

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

This new fee is paid by the searcher sending the transaction, so it will affect that searcher's behavior. If there is 100 MEV in the opportunity, the winning transaction will now only set a priority fee of 1 ETH, as this will lead to a total payment of 100 ETH (1 ETH paid to the block proposer, 99 ETH paid to the smart contract). Any higher priority fee would render the transaction unprofitable; any lower priority fee would result in losing the opportunity to a competitor setting a higher fee. This means that the smart contract has 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 ordering for their own benefit, enabling 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 trivial amount of MEV. Since priorityFeePerGas is denominated in wei (one billionth of 1 ETH), we need to deal with a lot of precision. For example, as long as the MEV tax is sensitive enough, a priorityFeePerGas of 50,000 will lead to an excessive tax, such that 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, MEV tax only works if block proposers follow certain rules (which we call "competitive priority ordering") and do not deviate from these rules to maximize their own revenue. Enforcing these rules in a trustless manner is an open question.

Single Application MEV Capture

Here, we outline how MEV tax can be used to mitigate three important issues in MEV on chains that guarantee block construction using competitive priority ordering: allowing DEX interfaces to improve the execution of trades for traders, allowing AMMs to reduce the arbitrage losses of their LPs, and allowing wallets to reduce user MEV leakage by selling users' backrunning rights.

Decentralized Exchange Routers

In intent-based DEX routing protocols like UniswapX and 1inch Fusion, users (Alice) sign swap intents, and searchers compete to route or fill that intent for Alice at the best price.

The current version of UniswapX uses two mechanisms to facilitate competition: Dutch auctions, where Alice's limit price changes over time until a searcher fills it; and initial off-chain request for quote (RFQ) auctions to set the starting price for the Dutch auction.

On platforms that guarantee competitive priority ordering, UniswapX can replace these mechanisms with a single mechanism: MEV tax. It can achieve this by allowing users to sign orders that anyone can fill immediately, but with the execution price set as a function of the transaction priority.

For example, if Alice has an order to sell 1 ETH on UniswapX, she can define the execution price of the order as minimumPrice + ($0.01 * priorityFeePerGas). The minimumPrice could be some fixed value that she expects to be significantly below 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 complete the order, which should ensure that the trader receives the best price that the searcher can find. (The "Limitations" section discusses some exceptions.)

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

This has some potential advantages compared to the existing mechanisms used in UniswapX.

Orders using MEV tax can be filled faster and at better prices than those using Dutch auctions. As discussed in this article, on-chain Dutch auctions leak some value to MEV due to price fluctuations between blocks and may take many blocks to complete. In contrast, orders using MEV tax can typically be completed in the next block while capturing the vast majority of MEV.

Unlike off-chain quotes, the auctions for orders using MEV tax will occur automatically when the on-chain transaction is executed. This means that the winning bidder is only committed to filling the order if the on-chain transaction succeeds. This can make on-chain liquidity, such as that of AMMs, more competitive with off-chain liquidity, meaning UniswapX can serve as a more effective router for multi-pool systems like Uniswap v4.

AMM

Typically, AMMs leak value to arbitrageurs who trade based on outdated prices at the top of the block, as discussed in the Losses and Rebalancing paper. We can use MEV tax to allow AMMs to capture MEV. For simplicity, we will discuss how this can work without concentrated liquidity. (If you are interested in how to address such issues through concentrated liquidity, Sorella will soon release a solution.)

AMMs can capture MEV by charging an additional fee as a function of the transaction priority fee, allowing them to auction the right to trade first in the block. There are various ways to calculate and price this fee. We will discuss one that can be considered neutral—using pool liquidity as a unit, sqrt(xy). The winning transaction will be the one that maximizes the liquidity of the mining pool.

When the first transaction is executed on the pool in the block, the pool can enforce the condition (setting a as some constant) instead of enforcing the condition xend * yend > xstart * ystart:

xend * yend > (sqrt(xstart * ystart) + a * priorityFeePerGas)^2

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

After the first transaction, trades can proceed as they do on Uniswap v2, with fixed swap fees. Uninformed trades wanting to trade in the pool without paying the additional MEV tax will set lower priority fees.

There are many other ways to implement MEV tax on AMMs, which would yield different effects. For example, MEV tax could be priced in terms of the input or output tokens being swapped, potentially affecting the percentage of swap fees applied by the pool, or it could determine the minimum price for user trades. We believe this is an interesting design space worth exploring.

Backrunning Auctions

The above description shows how to design certain applications to avoid MEV leakage. However, what if a wallet wants to try to help users capture the MEV they create from interacting with any application, even those that do not include MEV tax?

For example, when Alice makes a large trade on an AMM, she sometimes creates arbitrage opportunities for "backrunners" to pull the price back. This often leaks to MEV rather than 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.

Combining MEV tax with intent-based smart contract wallets allows us to build an alternative system to capture backrunning MEV for Alice. Suppose Alice does not create a transaction to trade on the AMM but instead signs an intent that anyone can submit to Alice's smart contract wallet to take that action. Alice's smart contract wallet charges MEV tax to anyone submitting that transaction, which is paid to Alice.

Searchers submitting Alice's intent will have the proprietary right to backrun her, as they can automatically execute this in the same transaction. Therefore, if the search is competitive, all of Alice's profits should be returned to her through the MEV tax.

Note that this system does not necessarily protect users from attacks involving front-running user trades, as front-running user trades may be able to avoid paying MEV tax to that user. This issue (and some possible mitigations) will be discussed in more detail in the limitations section. Nevertheless, this could at least be an improvement over systems that use public mempools with no mitigations.

Other Use Cases

In addition to these examples, other potential uses for MEV tax could include almost anything currently using off-chain or Dutch auctions, such as:

• Oracles capturing the extractable value created by their predictions, such as Oval;
• Refinancing auctions for NFT lending protocols like Blend;
• Leaked value from lending protocol liquidations being lower than Dutch auctions;

Cross-Application MEV Capture

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

If only one of these applications has an MEV tax, then all MEV in the transaction should go to the application with the MEV tax, regardless of how high or low the MEV tax is.

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

In this case, the relative amount of excess MEV captured by each application depends on how these applications set their MEV tax. If the value charged as MEV tax by appi is given by the function taxi(priority), then the priority of the winning transaction can be determined by solving for the priority in the following equation:

tax1(priorityPerGas) + tax2(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 may be negligible in normal circumstances.)

In the simple case where MEV tax is linearly related to priorityPerGas (thus tax1(priorityPerGas) = a1 * priorityPerGas), you can solve for the share of MEV received by each application:

a1 * priorityPerGas + a2 * priorityPerGas = MEV
priorityPerGas = MEV/(a1 + a2)
tax1(priorityPerGas) = (a1/(a1+a2)) * MEV
tax2(priorityPerGas) = (a2/(a1+a2)) * MEV

When setting their own MEV tax, applications face a trade-off—higher taxes allow them to capture a larger share when cross-application MEV occurs, but this means they may miss out on some cross-application MEV if there are competitive ways to extract it. For example, if there is an AMM that charges MEV tax on every transaction, then MEV tax UniswapX orders may be more likely to be filled by different AMMs or off-chain fillers.

In many cases, there may be an equilibrium where both applications design their MEV taxes to share MEV in a way that maximizes their respective profits. For example, an MEV tax AMM may want to extract value from a single informed trader near the top of the block but then want to provide liquidity to other traders and applications (including those using MEV tax) at a lower fixed rate. 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 the block, and then not charge MEV tax on subsequent trades in the block. Applications like UniswapX that want to interact with the AMM can set a higher MEV tax (e.g., $0.01 * priorityFeePerGas) to ensure their trades are included after the pool has already arbitraged. Given these relative taxes, even if there is only $1 of MEV in the UniswapX order and $50,000 of MEV, the AMM will ultimately be arbitraged first.

We believe this is a vast design space worth exploring in future research.

Limitations

MEV tax has some complexities and drawbacks, which we believe are interesting areas for future research.

Incentive Incompatibility

MEV tax is not incentive-compatible for monopolistic block proposers. They only work when there is fair competition for transaction inclusion, which only occurs when block proposers follow the rules we call "competitive priority ordering" and do not deviate from these rules to maximize their own revenue. Informally, some suggested rules include, but are not limited to, the following:

• Priority Ordering. Transactions in the block must be sorted in descending order of priorityFeePerGas.
• Censorship Resistance. If the block proposer receives transaction t1 during the block and that block is not full or contains certain transactions t2, such that t2.priorityFeePerGas < t1.priorityFeePerGas, then that block must include transaction t1.
• Pre-Transaction Privacy. Block proposers must accept transactions through private endpoints and must not share such transactions with anyone else before they are submitted to the block or use the content of these transactions as input to build their own transactions.
• No Last Censorship. Block proposers must set a clear block time before which they accept transaction requests from anyone; after this time, they will no longer accept transaction requests from anyone.

If any one or more of these properties are violated, it may undermine the effectiveness of MEV tax. Block proposers violating censorship resistance can evade most MEV tax by excluding competitive transactions and submitting zero-priority transactions that benefit themselves. Block proposers violating pre-transaction privacy can steal MEV from other transactions or see their priority fees to know exactly how high they need to set their fees, while block proposers able to submit transactions later than others will gain free "last looks" to see if they can get in at a higher price than others, both of which can create adverse selection problems that ultimately hinder competition.

Unfortunately, while the first property is easy to enforce at the protocol layer, enforcing the other properties in a trustless manner is an open question.

In the absence of enforcement at the protocol layer, there is a need to trust a single sorter that commits to not deviating from these rules, and if proposers outsource block construction to competitive revenue-maximizing auctions (such as Ethereum L1's MEV-Boost), the blocks may not follow them.

These issues could be "solved" by a single trusted sorter that commits to building blocks using competitive priority ordering. They could also be addressed through some combination of decentralized mechanisms using consensus, cryptography, and/or trusted execution environments, such as Sorella's Angstrom, Flashbots' SUAVE, leaderless auctions, or multi-signature.

Full Blocks

An exception occurs when blocks are completely full, where MEV tax operates normally. In this case, block proposers may have to drop lower-priority transactions rather than simply including them in the block. Since transactions interacting with MEV tax applications may have very low priority fees, these applications may be squeezed out by applications that do not use MEV tax or have very low MEV tax. However, in chains using mechanisms like EIP-1559 to set separate base fees, the situation of blocks being completely filled should be relatively rare. Additionally, considering that some transactions need to be delayed when the block is full, it may be reasonable to delay lower-urgency transactions by setting a higher MEV tax.

Reverted Transactions

MEV tax effectively relies on single-block auctions where each "bid" is a transaction. One drawback of these auctions is that failed bids often lead to reverted transactions being included on-chain, paying some base fees and causing chain congestion.

If sorters could completely exclude failed transactions, this would alleviate the problem, although it is difficult to achieve even with centralized sorters. (It would also not strictly adhere to the aforementioned anti-censorship properties, although that definition could be adjusted.) More sophisticated sorters could optimize this process by allowing transactions to specify which contentious auctions they are participating in, giving the sorter enough information to skip subsequent transactions it knows will fail.

Leakage of User Intent

MEV tax only works when there is competition among searchers, meaning that this opportunity needs to be somewhat widely known. For applications like AMMs, opportunities are visible on-chain, which should happen naturally. But for applications like intent-based routing or backrunning auctions, this means that applications may need to share users' intents with searchers.

In some cases, the temporary privacy loss caused by leaking user intent before it is realized may leak value in ways that MEV tax cannot recover.

For example, suppose Alice wants to use the aforementioned backrunning auction protocol to buy low liquidity tokens. She posts a signed intent from her smart contract wallet to buy that token on an AMM and sets a certain slippage tolerance. Searchers can compete in high-priority transactions to push the price of that token up to her slippage tolerance without filling the user's order. Then, the winning bidder Bob can satisfy Alice's intent in a non-competitive manner by including and backrunning it in a low-priority transaction, thus sandwiching Alice's trade and giving her a worse price while evading her MEV tax. Similar issues may arise when purchasing NFTs.

It is important to note that such an attack is risky for Bob, as he cannot guarantee the atomicity between buying the token and selling it to Alice. A naive Bob may fall into a "sandwich tear" trap: Alice first posts an intent to buy a worthless token from herself, and Bob buys that token to sandwich her trade, but before Bob completes the sandwich, Alice withdraws her intent.

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

MEV tax could also be combined with privacy-aware builder features, as envisioned by Flashbots for SUAVE.

Finally, if Alice believes that the cost of sharing her intent exceeds the benefits of competitive searching, she can build the transaction herself and submit it directly to the block. As mentioned above, the ideal implementation of competitive priority ordering would provide block proposers with pre-transaction privacy.

Related Discussions

Priority gas auctions. The Flash Boys 2.0 paper studies some dynamics of priority ordering in decentralized blockchains, coining the term "miner extractable value." The paper notes that Ethereum miners (when the network used proof of work) already prioritized transactions, and arbitrageurs relied on this behavior to participate in "priority gas auctions," where they bid for the right to be included in the first block, leading to most of the MEV from decentralized exchange arbitrage being captured by miners.

First-Come, First-Served. Some attempts to mitigate MEV through transaction ordering rules, such as Themis or the current sorters of Arbitrum One, focus on executing different ordering rules, first-come, first-served (sometimes referred to as "fair ordering"), where block proposers must sort transactions in the order they see them.

Priority ordering takes a different approach—treating transactions arriving within a given time equally and sorting them by their declared priority.

First-come, first-served is difficult to execute or even define in a real network environment with multiple validators. Even with a single trusted sorter, it may lead to wasted latency competition and spam. Ultimately, MEV tax may be able to eliminate certain types of MEV that first-come, first-served ordering cannot eliminate, such as arbitrage profits arising from asset price discontinuities or "jumps." The potential advantages of priority ordering over first-come, first-served ordering relate to the advantages of discrete time versus continuous time exchanges discussed in Budish, Cramton, Shim (2015).

Meanwhile, while priority ordering seems to leak value to MEV by default, this article demonstrates how to design applications to regain it.

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

MEV tax allows for similar arrangements (at least for priority fees), but can be implemented at the application layer on any chain using competitive priority ordering without requiring special support for fee sharing. They also allow applications to define their own tax as a custom function of priority fees, providing greater flexibility and potentially enhancing the composability of MEV-aware applications.

Trustless Solutions. This article focuses on the motivations for platforms using competitive priority ordering and methods for leveraging the platform, rather than discussing how to enforce it in a trustless manner.

Significant discussions have already taken place regarding each of the other properties required for competitive priority ordering. For example, in Fox, Pai, Resnick (2023), the authors discuss the vulnerabilities of on-chain auctions in the absence of censorship resistance and describe designs for anti-censorship auctions using multiple concurrent proposers. However, they do not suggest a specific ordering of transactions.

There is also ongoing research on building trust-minimized block construction mechanisms, including Flashbots' SUAVE, Sorella's Angstrom, leaderless auctions, Espresso, and Offchain Labs' decentralized Timeboost, as well as Péter Szilági's compulsory public transaction inclusion.

We hope this article encourages L2s to consider using priority ordering (which is supported by default in the OP stack) and encourages applications to experiment with MEV tax where supported. We also hope it inspires further research into trust-minimized competitive priority ordering protocols on both L1 and L2.