Title: “Priority Is All You Need”
Author: Dan Robinson and Dave White
Translated by: Joyce, BlockBeats
On June 5th, Dan Robinson, the research director of Paradigm, and research partner Dave White published a research paper proposing the introduction of Miner Extractable Value (MEV) tax. This tax allows any application to capture its MEV while maintaining composability. The mechanism can now be used 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 limitations of the MEV tax, including its reliance on block proposers strictly following competitive priority ordering rules and potential issues with effective operation on the Ethereum L1. Additionally, the article discusses how to mitigate some drawbacks of the MEV tax through design, such as incentivizing incompatibilities, full block issues, reverted transactions, and leaked user intents. BlockBeats has translated the article as follows:
Table of Contents
Introduction
Priority Ordering
MEV Tax
Single-Application MEV Capture
Decentralized Exchange (DEX) Router
Automated Market Maker (AMM)
Reverse Auction
Other Use Cases
Cross-Application MEV Capture
Limitations
Incentivizing Incompatibility
Full Block
Reverted Transactions
Leaked User Intent
Related Discussions
Conclusion
In this article, we introduce the MEV tax, a mechanism that allows any application to capture its own MEV. This mechanism can now be used on OP Mainnet, Base, Blast, and other OP Stack L2 chains because block proposers on these chains follow a set of rules we call competitive priority ordering.
To levy the MEV tax on a chain, a smart contract charges a fee that is a function of transaction priority fees. If an application captures 99% of the competitive MEV in a transaction by charging 99 ETH of MEV tax for every $1 of priority fee paid by the searcher, then it can capture the majority of the MEV in that transaction.
The MEV tax is a simple technology that opens up a broad design space. You can think of it as allowing any application on the chain to run its own custom MEV auction without needing any off-chain infrastructure of its own, just by connecting to a single shared auction run by block proposers.
We discuss how to use the MEV tax to address three main problems in MEV research:
– Optimizing the price received by traders on DEX routers;
– Minimizing losses and rebalancing for liquidity providers in AMMs;
– Allowing wallets to capture any “back-running” MEV created by user transactions.
However, there’s a catch. The MEV tax only works if block proposers strictly adhere to competitive priority ordering rules, which involve sorting transactions based on priority fees without censoring, peeking, or delaying any transactions. If block proposers deviate from these rules, they can bypass the MEV tax to capture value for themselves. Therefore, the MEV tax currently relies on trusted L2 sorters and may not work at all on the Ethereum L1, where block construction is dominated by competitive auctioneers maximizing proposer revenue.
Despite this, the power and flexibility of the MEV tax revenue suggest that priority ordering may be the right choice for platforms currently able to offer this service. The relative simplicity of competitive priority ordering suggests that there may be a viable 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. You can think of this as being designated as priorityFeePerGas, a number multiplied by the gas used in the transaction to get builderPriorityFee— the total payment in ETH.
The Ethereum protocol does not dictate that transactions in a block must be greedily sorted by priorityFeePerGas in descending order. However, this is a popular way to construct blocks— for example, it is the default algorithm used by OP Stack chains as well as geth and reth. Priority ordering allows traders to effectively express the urgency of their transactions and naturally pass some types of MEV to block proposers.
This occurs because priority ordering turns the competition for MEV into a priority gas auction. When there’s an opportunity to profit from interacting with the chain, such as arbitraging between AMMs and centralized exchanges, searchers compete to seize the opportunity. If the chain uses priority ordering to determine transaction inclusion and ordering, searchers compete by setting high priority fee for their transactions.
In a zero-risk profit competition scenario, the winning searcher should eventually pay the full MEV priority fee. Therefore, if a transaction can yield 100 ETH in profit through 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).
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, we don’t necessarily need to know anything about the application. If we know the block was constructed through competitive priority ordering, we have a general signal about the amount of MEV in a transaction: 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 to the contract.
This new fee is paid by the searcher sending the transaction, so it affects the behavior of that searcher. If there’s 100 MEV in the opportunity, the winning transaction will now only set a priority fee of 1 ETH, 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 makes the transaction unprofitable; any lower priority fee results 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 that smart contracts levy the MEV tax. The MEV tax allows applications to hijack priority ordering for their own benefit, allowing 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, proposers will only receive negligible MEV. Since priorityFeePerGas is priced in wei (1 billionth of 1 ETH), we need to deal with a lot of precision. For example, if the MEV tax is sensitive enough, a priorityFeePerGas of 50,000 will result in excessive tax, so the total amount paid to proposers will be less than $0.01.
However, there’s 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”) rather than deviating from these rules to maximize their own revenue. Enforcing these rules in a trustless manner is an unresolved issue.
Here, we outline how, on platforms that guarantee block construction using competitive priority ordering, the MEV tax can be used to mitigate three significant problems in MEV: improving traders’ execution on DEX interfaces, reducing arbitrage losses for AMMs, and reducing user MEV leakage by selling the rights to back-runs.
In intent-based DEX routing protocols like UniswapX and 1inch Fusion, users (Alice) sign trading intents, and searchers compete to route or fill that intent for Alice at the best price.
The current version of UniswapX uses two mechanisms for competition: Dutch auctions, where Alice’s limit price changes over time until a searcher fills it; and initial on-chain Request for Quote (RFQ) auctions used 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: the MEV tax. This can be achieved by allowing users to sign orders that anyone can immediately fill but 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 non-reverted will complete the order, ensuring the trader gets the best price the searcher can find. (Some exceptions are discussed in the Limitations section).