Venture Capital Firm Paradigm Proposes Introducing Miner Extractable Value MEV Tax and Priority Sorting

Venture Capital Firm Paradigm Proposes Introducing Miner Extractable Value MEV Tax and Priority Sorting

Venture Capital Firm Paradigm Proposes Introducing Miner Extractable Value MEV Tax and Priority Sorting

Priority Is All You Need
By Dan Robinson and Dave White
Translated by Joyce, BlockBeats

On June 5th, Dan Robinson, the Research Director at Paradigm, and Dave White, a research partner, 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. This 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 MEV tax, including its reliance on block proposers strictly adhering to competitive priority sorting rules, and potential inefficiencies in operation on Ethereum L1. Additionally, the article discusses how to mitigate some drawbacks of MEV tax through design, such as incentivizing incompatibility, complete blocks issues, recovered transactions, and leakage of user intentions. BlockBeats has translated the article as follows:

Introduction
Priority Sorting
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
Complete Blocks
Recovered Transactions
Leakage of User Intentions
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 platforms, as the block proposers on these chains follow a set of rules we call competitive priority sorting.

To levy MEV tax on a chain, smart contracts charge a fee, which is a function of the transaction’s priority fee. If an application charges 99 USD of MEV tax for every 1 USD of 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 think of it as allowing any application on-chain to run its custom MEV auction without any off-chain infrastructure of its own, just by connecting to a single shared auction run by the block proposers.

We outline how to use MEV tax to address three main issues in MEV research:
– Optimizing exchange execution for traders through DEX routers
– Minimizing arbitrage losses for liquidity providers in AMMs and rebalances (LVR)
– Allowing wallets to capture any “backrunning” MEV created by user transactions

However, there’s a catch. MEV tax is only effective if block proposers strictly adhere to competitive priority sorting rules, which include sorting transactions by priority fee without censoring, peeking, or delaying any transactions. If block proposers deviate from these rules, they can evade MEV tax to capture value for themselves. Therefore, MEV tax now relies on trusted L2 sorters and may not work effectively on Ethereum L1, where block construction is dominated by competitive builders’ auctions, maximizing proposers’ revenue.

Nonetheless, the power and flexibility of MEV tax revenues suggest that priority sorting may be the right choice for platforms currently able to provide this service. The relative simplicity of competitive priority sorting suggests a feasible 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 proposers. This can be thought of as priorityFeePerGas (priority fee), a number multiplied by the gas used in the transaction to get builderPriorityFee – the total payment in ETH.

There’s no specification in the Ethereum protocol that transactions in a block must be greedily sorted in descending order of priorityFeePerGas. However, it’s a popular way to construct blocks – for example, it’s the default algorithm used by OP Stack chains and geth and reth. Priority sorting not only allows traders to express the urgency of their transactions effectively but also naturally passes some types of MEV to block proposers.

This happens because priority sorting turns MEV competition 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 get ahead. If the chain uses priority sorting to determine which transactions are included and how they’re sorted, searchers compete by setting high priority fees on 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 transaction can yield 100 ETH in profit from 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 transactions it interacts with. There’s extensive research on various specific ways smart contracts can try to capture their own MEV.

But in reality, we don’t necessarily need information about the application. If we know the block is built through competitive priority sorting, we have a universal signal about the amount of MEV in a transaction: the priority fee.

We suggest 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 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, thus influencing their behavior. If there’s 100 MEV in the opportunity, the winning transaction will now only set a 1 ETH priority fee, as this would result in a total payment of 100 ETH (1 ETH to the block proposer and 99 ETH to the smart contract). Any higher priority fee would make the transaction unprofitable; any lower priority fee would lose the opportunity to a competitor setting a higher fee. This means the smart contract has captured 99% of the MEV in the transaction.

We refer to this additional fee collected by the smart contract as the MEV tax. MEV tax allows applications to hijack priority sorting for their own benefit, enabling them to recapture MEV for their users instead of 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, as long as the MEV tax is sensitive enough, a priorityFeePerGas of 50,000 will lead to excessive tax, resulting in total amounts paid to proposers lower than 0.01 USD.

However, there’s an important caveat. As discussed in the “Limitations” section, MEV tax only works if block proposers follow certain rules (what we call “competitive priority sorting”) and don’t deviate from these rules to maximize their revenue. 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 critical issues in MEV: improving exchange execution for traders through DEX interfaces, reducing arbitrage losses for AMMs, and reducing user MEV leakage by selling users’ backrunning rights.

In intent-based DEX routing protocols like UniswapX and 1inch Fusion, users (Alice) sign an exchange intent, 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 filled by a searcher; and Initial off-chain RFQ auctions used to set the starting price for the Dutch auction.

On platforms ensuring 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 instantly fill, but with the execution price being a function of the transaction’s priority.

For example, if Alice has an order to sell 1 ETH on UniswapX, she can define the order’s execution price as minimumPrice + ($0.01 * priorityFeePerGas). The minimumPrice could 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).

If Alic