The article “Priority Is All You Need” was published by Paradigm on June 4th, introducing the new mechanism MEV tax.
MEV tax is an innovative mechanism that allows applications to capture the MEV they generate, rather than leaking it to block proposers. This mechanism leverages the competitive priority sorting process during block construction. In this sorting method, transactions are arranged in descending order based on priority fees, with high priority transactions being packed first in the block. MEV tax achieves this by adding additional fees to transactions based on their priority fees. Applications can set their own fees based on transaction priority fees, capturing most or all of the MEV. This means that applications can run their custom MEV auctions without the need for any off-chain infrastructure, participating in a single shared auction run by block proposers.
The emergence of the MEV tax mechanism may impact the existing DeFi ecosystem in several ways:
1. Changing the traditional distribution of MEV: Traditionally, most MEV flows to block proposers, but the MEV tax allows applications to capture this value and redistribute it to their users or for other purposes.
2. Increasing application revenue and user experience: Applications can increase their revenue by implementing MEV tax while providing a better user experience, as users can benefit from higher transaction execution efficiency and better prices.
3. Addressing some issues in DeFi: Such as optimizing DEX routing, reducing AMM arbitrage losses, and reducing MEV leakage for wallet users. By introducing MEV tax, applications can improve their products and services, enhancing the efficiency and sustainability of the DeFi ecosystem.
In this article, we introduced the MEV tax, a mechanism that allows any application to capture its own MEV (Maximum Extractable Value).
This mechanism can be immediately implemented on OP Stack L2 chains (such as OP Mainnet, Base, and Blast) as the block proposers on these chains follow a set of rules we refer to as competitive priority sorting.
To implement the MEV tax on these chains, a smart contract charges a fee based on the priority fee of the transaction. We showed that if an application imposes a MEV tax of $99 on every $1 of priority fee paid by a searcher, it can capture 99% of the competitive MEV of that transaction.
MEV tax is a simple technology that opens up a wide design space. It allows any application on the chain to run its custom MEV auction without the need for any off-chain infrastructure, only connecting to a shared auction run by block proposers.
We demonstrated how the MEV tax can be used to address three main issues in MEV research:
1. Optimizing the decentralized exchange (DEX) router for exchange price received by traders.
2. Minimizing losses suffered by liquidity providers due to rebalancing in automated market makers (AMM).
3. Allowing users to capture any “rollback” MEV generated by their exchanges.
However, there is a caveat. MEV tax is only effective if block proposers strictly adhere to the competitive priority sorting rules, including sorting transactions by priority fee without censorship, peeking, or delay. If block proposers deviate from these rules, they can bypass the MEV tax to capture value. Therefore, today’s MEV tax relies on trusting L2 sequencers and may not work at all on the Ethereum L1, where block construction is primarily dominated by a competitive builder auction to maximize proposer revenue.
Nevertheless, the capabilities and flexibility of MEV tax suggest that priority sorting may be the right choice for platforms that can currently provide priority ordering. The relative simplicity of competitive priority sorting suggests that there may be a viable way to enforce it in a decentralized manner without trusting a single sequencer. We hope this article will inspire further research on this issue.
Priority Ordering
When someone sends a transaction on the Ethereum mainnet or L2, they specify a priority fee, which is paid to the block proposer. This can be thought of as specified through priorityFeePerGas, multiplied by the gas used in the transaction to get builderPriorityFee, the total ETH payment.
While the Ethereum protocol does not mandate that transactions in a block must be greedily sorted in descending order of priorityFeePerGas, it is a popular method for constructing blocks. For example, this is the sequencer used by the OP Stack chain and the default algorithm used by geth and reth. Priority sorting not only allows traders to effectively express the urgency of their transactions but also naturally channels certain types of MEV to block proposers.
This occurs because priority sorting turns the competition for MEV into a priority gas auction. When there is an opportunity to profit by interacting with the chain, such as arbitraging between AMMs and centralized exchanges, a searcher will compete to be the first to seize this opportunity. If the chain uses priority sorting to determine transaction packing and ordering, the searcher will compete by setting a high priority fee in their transaction.
In a competitive scenario where risk-free profits are compressed to zero, the winning searcher should ultimately pay the full MEV as a priority fee. Therefore, if a transaction can generate a profit of 100 ETH through interaction with a contract, the first transaction to seize the opportunity will set a priority fee of 100 ETH. (We discuss some caveats to this in the “Limitations” section).
MEV Tax
Suppose a smart contract wants to capture the MEV in transactions interacting with it. There is a wealth of research literature on specific ways in which smart contracts attempt to capture their own MEV.
However, in reality, we do not necessarily need to know any specific information about the application. If we know that blocks are constructed through competitive priority sorting, we have a unified signal to indicate 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 based on it, which is an increasing function of the priority fee. For example, the contract may require the caller to transfer applicationPriorityFee = 99 * proposerPriorityFee ETH to the contract.
This new fee is paid by the searcher sending the transaction, so it affects the behavior of the searcher. If an opportunity has a MEV of 100 ETH, the winning transaction will now only set a 1 ETH priority fee, as this will result in a total payment of 100 ETH (1 ETH to the block proposer, 99 ETH to the smart contract). Any higher priority fee would make the transaction unprofitable; any lower priority fee would result in the opportunity being taken by a competitor setting a higher fee. This means that the smart contract captures 99% of the MEV in the transaction.
We refer to this additional fee imposed by smart contracts as the MEV tax. The MEV tax allows applications to hijack priority sorting for their own benefit, enabling them to recapture MEV for users rather than leaking it to block proposers.
If the fee grows fast enough as a function of priorityFeePerGas, only negligible MEV will accumulate to the proposers. Since priorityFeePerGas is priced in wei (one trillionth of an ETH), we have a lot of precision to work with. For example, as long as the sensitivity of the MEV tax is high enough that a priorityFeePerGas of 50,000 would result in a discouragingly high tax amount, the total amount paid to proposers would be less than $0.01.
However, an important caveat remains. As discussed in the “Limitations” section, the MEV tax is only effective if block proposers follow certain rules (referred to as “competitive priority sorting”) and do not deviate from these rules to maximize their own revenue. Enforcing these rules in a trustless manner remains an unresolved issue.
Single Application MEV Capture
On a chain guaranteeing block construction using competitive priority sorting, MEV tax can be used to mitigate three key issues with MEV: improving DEX interfaces for traders’ transaction execution, reducing AMM arbitrage losses for their LPs, and reducing MEV leakage for users through selling back their rights.
DEX Router Searcher
In intent-based DEX routing protocols (such as UniswapX and 1inch Fusion), a user (Alice) signs an exchange intent, and a searcher competes to route or fill that intent at the best price.
The current version of UniswapX uses two mechanisms to operate this competition: a Dutch auction where Alice’s limit price changes over time until filled by a searcher, and an initial off-chain quote request (RFQ) auction to set the starting price of the Dutch auction.
On a platform guaranteeing competitive priority sorting, UniswapX can replace these mechanisms with one: the MEV tax. This can be achieved by having users sign an order that can be immediately filled by anyone, but the execution price is a function of the transaction’s priority fee.
For example, if Alice has a UniswapX order to sell 1 ETH, she can define the execution price of the order as minimumPrice + ($0.01 * priorityFeePerGas). The minimumPrice can be a fixed value significantly lower than the current price she expects.
Searchers will compete to fill Alice’s order by submitting transactions. Any transaction with the highest priority fee and no rollback will fill the order, ensuring the trader gets the best price the searcher can find. (Some exceptions to this are discussed in the “Limitations” section).
If Alice’s minimum price is $3,000 and the current ETH price is $3,500, the priorityFeePerGas in the winning transaction is approximately 50,000. (Note that in a transaction costing 200,000 gas, this would result in only about 100 billion wei (about $0.000035) paid to the block proposer).
With Uniswa