Priority Is All You Need
Authored by Dan Robinson and Dave White, Paradigm’s research director and research partner, respectively, published a research article on June 5 proposing the imposition of Miner Extractable Value (MEV) tax. This tax allows any application to capture its MEV while maintaining composability. The mechanism is now available on OP Mainnet, Base, Blast, and other OP Stack L2 platforms. The article suggests that smart contracts can charge a certain percentage of fees based on transaction priority fees to capture MEV in transactions.
The article also points out the limitations of MEV tax, including its reliance on block proposers strictly adhering to competitive priority ordering rules and potential ineffectiveness on Ethereum L1. Furthermore, the article discusses how to mitigate some drawbacks of MEV tax through design, such as incentive incompatibility, complete block problems, reverted transactions, and leakage of user intent. BlockBeats has translated the article as follows:
In this article, we introduce MEV tax, a mechanism that allows any application to capture its own MEV. This mechanism is now available on OP Mainnet, Base, Blast, and other OP Stack L2 chains, where block proposers follow a set of rules we call competitive priority sorting.
To levy MEV tax on a chain, smart contracts charge a fee that is a function of transaction priority fees. If an application charges 99% MEV tax for every $1 priority fee paid by the searcher, it can capture 99% of the competitive MEV in that transaction.
MEV tax is a simple technology that opens up a wide design space. You can view it as allowing any application on a chain to run its own custom MEV auction without needing any off-chain infrastructure, connecting only to a single shared auction run by block proposers.
We explain how to use MEV tax to address three main issues in MEV research:
– Optimizing the prices received by traders through Decentralized Exchange (DEX) routers;
– Minimizing losses and rebalancing for liquidity providers in Automatic Market Makers (AMM);
– Allowing wallets to capture any “back-running” MEV created by their transactions.
However, there is a catch. MEV tax only works if block proposers strictly follow competitive priority sorting rules, which include prioritizing transactions based on priority fees without censoring, peeking, or delaying any transactions. If block proposers deviate from these rules, they can evade MEV tax to profit for themselves. Therefore, MEV tax now relies on trusted L2 sorters and may not work effectively on Ethereum L1, where block building is dominated by competitive auctioneers to maximize proposers’ income.
Despite this, the power and flexibility of MEV tax collections suggest that prioritization may be the right choice for platforms that can currently provide this service. The relative simplicity of competitive priority sorting implies a possible way to enforce it in a decentralized manner without trusting a single sorter. We hope this article will inspire further research on this issue.
When someone sends a transaction on Ethereum L1 or L2, they specify a priority fee and pay it to the block proposer. This can be thought of as priorityFeePerGas, a number multiplied by the gas used in the transaction to get builderPriorityFee – the total payment in ETH.
While the Ethereum protocol does not mandate transactions in a block to be greedily sorted by priorityFeePerGas in descending order, it is a common way to build blocks. For example, it is the default algorithm used by OP Stack chains, as well as geth and reth. Priority sorting allows traders to express the urgency of their transactions effectively and naturally pass on certain types of MEV to block proposers.
This happens because priority sorting turns MEV competition into a priority gas auction. When there is an opportunity to profit from interacting with the chain, such as arbitrage between AMM and centralized exchanges, searchers compete to seize the opportunity. If the chain uses priority sorting to determine transaction inclusion and ordering, searchers compete by setting high priority fees for their transactions.
In a competition scenario where there is no risk-free profit, the winning searcher should ultimately pay the full MEV priority fee. Therefore, if a transaction can yield 100 ETH profit through interaction 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).
Suppose a smart contract wants to capture MEV from any transaction it interacts with. There is a lot of research on different specific ways smart contracts can try to capture their own MEV.
However, in reality, we do not necessarily need to know any information about the application. If we know that the block is constructed through competitive priority sorting, we have a general signal about the amount of MEV in transactions: the priority fee.
We suggest that smart contracts can look at the priority fee of a transaction and charge their own fee as a function of it. For example, the contract may require the caller to transfer applicationPriorityFee = 99 * proposerPriorityFee in ETH.
This new fee is paid by the searcher sending the transaction, so it affects the behavior of that searcher. If there is 100 MEV in the opportunity, the winning transaction will now only set a 1 ETH priority fee, as this will lead to a total payment of 100 ETH (1 ETH to the block proposer, 99 ETH 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 with a higher fee. This means that the smart contract has captured 99% of the MEV in the transaction.
We call this additional fee collected by smart contracts the MEV tax. MEV tax allows applications to hijack priority sorting for their own benefit, enabling them to recapture MEV for their users rather than leaking it to block proposers.
If this fee grows fast enough as a function of priorityFeePerGas, then proposers will only receive negligible MEV. Since priorityFeePerGas is priced 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 result in excessive tax, and the total amount paid to the proposer will be less than $0.01.
However, there is an important caveat. As discussed in the “Limitations” section, MEV tax only works if block proposers follow certain rules (referred to as “competitive priority order”) and do not deviate from these rules to maximize their income. Enforcing these rules in a trustless manner is a pending issue.
Here, we outline how, on platforms that guarantee block construction using competitive priority sorting, MEV tax can be used to mitigate three key issues in MEV: improving trader execution on DEX interfaces, reducing arbitrage losses for AMMs, and reducing user MEV leakage by selling the right to back-run users.
In intent-based DEX routing protocols like UniswapX and 1inch Fusion, users (Alice) sign exchange intents, and searchers compete to route or fill Alice’s intent at the best price.
The current version of UniswapX employs two mechanisms for competition: Dutch auctions, where Alice’s limit price changes over time until a searcher fills it; and Initial On-Chain Quote (RFQ) auctions used to set the starting price for Dutch auctions.
On platforms that guarantee competitive priority sorting, UniswapX can replace these mechanisms with a single one: MEV tax. This can be achieved by allowing users to sign orders that anyone can immediately fill, with the execution price set as a function of 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 may be a fixed value 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 is not reverted will complete the order, ensuring the trader gets the best price the searcher can find. (Some exceptions are discussed in the “Limitations” section).
If Alic
