MEV Tax Mechanism, allowing any application to capture its MEV and maintain composability.

Authors: Dan Robinson, Dave White

Translator: Joyce, BlockBeats

Introduction

In this article, we will introduce the MEV tax, a mechanism that any application can use to capture its own MEV. This mechanism can now be used on OP Mainnet, Base, Blast, and other OP Stack L2 chains because the block proposers on these chains follow a set of rules we call competitive priority sorting.

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

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 any off-chain infrastructure of its own, simply 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:

Decentralized exchange (DEX) routers optimizing the prices received by traders;

Automated market makers (AMMs) minimizing the losses and rebalancing (LVR) experienced by liquidity providers;

Allowing users to capture any "backrun" MEV created by their transactions.

But there's a catch. MEV tax is only effective if the block proposers strictly adhere to the 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 for their own gain. Therefore, 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, maximizing proposer revenue.

Nevertheless, the power and flexibility of MEV tax collection suggest that, for platforms currently able to provide this service, priority sorting may be the right choice. The relative simplicity of competitive priority sorting suggests that there may be 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.

Priority Sorting

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 specified 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 specify 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 sorter used by OP Stack chains, as well as 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 passes certain types of MEV to the block proposers.

This happens because priority sorting turns the competition for MEV into a priority gas auction. When there is 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 transaction inclusion and ordering, searchers compete by setting high priority fees for their transactions.

In a zero-risk profit competition scenario, the winning searcher should ultimately pay the full MEV priority fee. Therefore, if there is an opportunity to profit 100 ETH 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).

MEV Tax

Suppose a smart contract wants to capture MEV from any transaction interacting with it. There is a lot of research on different specific ways smart contracts can try to capture their own MEV.

But in fact, we don't necessarily need to know anything about the application. If we know that the block was constructed using competitive priority sorting, then we have a general signal about the amount of MEV in the transaction: the priority fee.

We suggest that a smart contract can look at the priority fee of a transaction and charge its own fee as some increasing 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, so it affects the behavior of that searcher. If there is 100 MEV in the opportunity, the winning transaction will now only set a priority fee of 1 ETH, as this would 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 losing the opportunity to a competitor setting a higher fee. This means the smart contract has captured 99% of the MEV in the transaction.

We call this additional fee collected by the smart contract the MEV tax. The MEV tax allows applications to hijack the priority sorting for their own benefit, allowing them to recapture MEV for their users instead of leaking it to the block proposers.

If this fee grows fast enough as a function of priorityFeePerGas, the proposers will only get a negligible amount of MEV. Since priorityFeePerGas is priced in wei (1 billionth of an 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 an excessively high tax, such that the total amount paid to the proposer will be less than 0.01 USD. (5)

However, there is an important caveat. As discussed in the "Limitations" section, MEV tax only works if the block proposers follow certain rules (which we call "competitive priority sorting") and do not deviate from these rules to maximize their own income. Enforcing these rules in a trustless manner is an open question.

Single Application MEV Capture

Here, we outline how, on a platform that guarantees block construction using competitive priority sorting, MEV tax can be used to mitigate three important issues in MEV: improving trader execution on DEX interfaces, reducing arbitrage losses for AMMs, and reducing user MEV leakage by selling the right to run the user's transaction.

Decentralized Exchange Router

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

UniswapX's current version uses two mechanisms for competition: a Dutch auction, where Alice's limit price changes over time until it is filled, and an initial off-chain request for quote (RFQ) auction used to set the starting price for the Dutch auction.

On a platform that guarantees competitive priority sorting, UniswapX can replace these mechanisms with a single one: MEV tax. This can be achieved by having users sign orders that anyone can fill immediately, but with the execution price being a function of the transaction's priority.

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 might be a fixed value that 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 that the trader gets the best price the searcher can find. (Some exceptions are discussed in the "Limitations" section).

If Alice's minimum price is $3,000 and the current price of ETH is $3,500, the priorityFeePerGas in the winning transaction is approximately 50,000. (Note that in a transaction with 200,000 gas, this would result in only about 100 billion wei (approximately $0.000035) paid to the block proposer).

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

Orders using MEV tax can be completed faster and at a more favorable price compared to orders using Dutch auctions. As discussed in this article, on-chain Dutch auctions leak some value to MEV due to price changes 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 requests for quote (RFQ), auctions for orders using MEV tax will automatically occur during on-chain transaction execution. This means that the winning bidder can only commit to filling the order if the on-chain transaction is successful. This can make on-chain liquidity more competitive with off-chain liquidity, meaning that UniswapX can serve as a more effective router for multi-pool systems like Uniswap v4.

AMM

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

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

When executing the first transaction on the pool in a block, the pool can enforce a condition (taking a as some constant) instead of enforcing the condition x_end * y_end > x_start * y_start:

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2

This formula will incentivize arbitrageurs to trade at the true price, and after this transaction, the mid-price in the pool should be the true price.

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

There are many other ways to implement MEV tax on AMMs, each with different effects. For example, MEV tax can be priced in terms of the input or output tokens of the swap, potentially affecting the swap fee percentage applied by the pool, or it can determine the minimum price for user transactions. We believe this is an interesting design space worth exploring.

Backrun Auction

The above descriptions show how to design certain applications to avoid MEV leakage. However, what if a wallet wants to try to help users capture the MEV created by any transaction interacting with any application, even those without MEV tax?

For example, when Alice makes a large trade on an AMM, she sometimes creates arbitrage opportunities for "backrunners" that pull the price back. This typically leaks to MEV instead of to Alice.

MEV-Share and MEVBlocker are two protocols that allow users to capture MEV from transactions, 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 can allow us to build an alternative system to capture backrun MEV for Alice. Suppose Alice did not create a transaction to trade on the AMM, but instead signed an intent for anyone to submit to her smart contract wallet to perform that operation. Alice's smart contract wallet charges MEV tax to anyone submitting that transaction, which is paid to Alice.

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

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

Other Use Cases

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

Protocols capturing the value of their created oracles, such as Oval;

Refinancing auctions for NFT collateralized lending protocols like Blend;

Leakage value lower than Dutch auctions for liquidation in lending protocols;

Cross-Application MEV Capture

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

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

But what if the searcher's transaction interacts with two applications using MEV tax? For example, if some MEV can only be captured by filling an MEV tax-paying UniswapX order and another MEV tax-paying order on the same transaction?

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 app_i collected as MEV tax is given by the function tax_i(priority), then the priority of the winning transaction can be determined by solving the following equation:

tax_1(priorityPerGas) + tax_2(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 can be negligible in normal circumstances)

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

a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

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

In many cases, there may be an equilibrium where two applications design their MEV tax to share the MEV in a way that maximizes their respective profits. For example, an MEV tax AMM might 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) to allow arbitrage trades (if any) to occur early in the block, and then not charge MEV tax for 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 been arbitraged. Given these relative taxes, even if there is only $1 of MEV in a UniswapX order and $50,000 of MEV in the AMM, the AMM will ultimately be front-run.

We believe this is a broad 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 taxes are not incentive-compatible for monopolistic block proposers. They only work when there is fair competition for transaction inclusion, and this only happens when block proposers follow what we call "competitive priority ordering" rules, rather than maximizing their own income. Informally listing some proposed rules, including but not limited to:

Priority ordering. Transactions within a block must be ordered in descending order of priorityFeePerGas.

Resistance to censorship. If a block proposer receives transaction t1 during a block and the block is not full or contains some transaction t2, such that t2.priorityFeePerGas t1.priorityFeePerGas, the block must include transaction t1.

Pre-transaction privacy. Block proposers must accept transactions through private endpoints and not share such transactions with anyone else or use the contents of these transactions as inputs to construct their own transactions before submitting them to the block.

No last look. Block proposers must set a clear block time at which they accept transactions from anyone; after this time, they no longer accept transactions from anyone.

Violating one or more of these properties could weaken the effectiveness of MEV tax. Block proposers violating resistance to censorship could avoid most MEV tax by excluding competitive trades and submitting zero-priority trades advantageous to themselves. Block proposers violating pre-transaction privacy could steal MEV from other transactions or view their priority fees to know exactly how much they need to set their fees, and block proposers able to submit transactions later than others could get a free "last look" opportunity at higher-than-others prices, both of which could cause adverse selection problems, ultimately hindering competition.

Unfortunately, while the first property is easily enforceable at the protocol layer, enforcing the other properties in a trustless manner is an open problem.

In the absence of enforced enforcement at the protocol layer, single trusted sequencers are needed to trust that they will not deviate from these rules, and if proposers outsource block construction to competitive income-maximizing auctions (e.g., MEV-Boost on Ethereum L1), blocks may not follow them.

These issues can be "solved" by a single trusted sequencer that commits to using competitive priority ordering for block construction. They can also be addressed through decentralized mechanisms using a combination of consensus, cryptography, and/or trusted execution environments, such as Sorella's Angstrom, Flashbots' SUAVE, leaderless auctions, or multiplicity.

Full Blocks

An exception to how MEV tax operates occurs when blocks are completely full. In this case, block proposers may have to exclude lower-priority transactions rather than simply include them in the block. Since transactions interacting with MEV tax applications may have extremely low priority fees, these applications may be crowded out by non-MEV tax or very low MEV tax applications. However, in chains using mechanisms similar to EIP-1559 to set a separate base fee, cases of completely filled blocks should be relatively rare. Additionally, considering that some transactions need to be delayed when blocks are full, it may be a reasonable outcome to delay less urgent transactions by setting higher MEV tax.

Reverted Transactions

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

This issue could be mitigated if sequencers could completely exclude failed transactions, although it is difficult to achieve even with centralized sequencers. (It also does not strictly adhere to the resistance to censorship properties, although that definition can be adjusted.) More sophisticated sequencers could optimize this process by allowing transactions to specify which disputed auctions they are participating in, giving the sequencer enough information to skip subsequent transactions it knows will fail.

Leakage of User Intent

MEV tax is only effective when there is competition among searchers, meaning that this opportunity needs to be somewhat widely known. For applications like AMMs, the opportunity should be visible on-chain and should naturally occur. However, for intent-based routing or backrun auctions, applications may need to share user intent with searchers.

In some cases, there may be temporary privacy loss from propagating user intent before the user intent is realized, in a way that leaks value in a way that MEV tax cannot recover.

For example, suppose Alice wants to use the aforementioned backrun auction protocol to purchase a low-liquidity token. She posts a signed intent from her smart contract wallet to buy the token on an AMM and sets a certain slippage tolerance. Searchers can compete in high-priority trades to push the price of the token to her slippage tolerance without filling the user's order. Then, the winner Bob can non-competitively fulfill Alice's intent by buying the token in a low-priority trade and front-running her trade, thus sandwiching Alice's trade and giving her a worse price while evading her MEV tax. Similar issues could arise for purchasing NFTs.

It should be noted that such attacks are risky for Bob, as he cannot guarantee atomicity between buying the token and selling it to Alice. A naive Bob might fall into a "sandwich tearing" trap: Alice first posts an intent to buy a worthless token from herself, Bob buys the token to sandwich her trade, but before Bob completes the sandwich, Alice withdraws her intent.

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

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

Finally, if Alice believes that the cost of sharing intent outweighs the benefits of competitive search, she can construct 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

Gas auctions. The Flash Boys 2.0 paper studied some dynamics of priority ordering in decentralized blockchains, creating the term "Miner Extractable Value." The paper points out that Ethereum miners (when the network uses proof of work) have been ordering transactions by priority, and arbitrageurs rely on this behavior to participate in "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 going to miners.

First come, first served. Attempts to mitigate MEV through transaction ordering rules, such as the current sequencer in Themis or Arbitrum One (7), focus on enforcing different ordering rules, such as first come, first served (sometimes called "fair ordering"), where block proposers must order transactions based on the order they see them.

Priority ordering takes a different approach - treating transactions arriving within a given time equally and ordering them based on their declared priority.

First come, first served is difficult to enforce or even define in a real network environment with multiple validators. Even with a single trusted sequencer, it could lead to wasted latency competition and spam. Finally, MEV tax may be able to eliminate certain types of MEV that first come, first served ordering cannot, such as arbitrage profits from asset price discontinuities "jumps." The potential advantage of priority ordering over first come, first served ordering is somewhat related to the advantage of discrete time over 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 reclaim it.

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

MEV tax allows for similar things (at least for priority fees), but can be implemented at the application layer on any chain using competitive priority ordering, without the need for specific support for fee sharing. They also allow applications to define their taxes as custom functions of the priority fee, providing greater flexibility and potentially increasing the composability of MEV-aware applications.

Trustless solutions. This article focuses on the motivation for platforms to use competitive priority ordering and ways to leverage the platform, rather than discussing how to enforce it in a trustless manner.

Important discussions have already been made on each of the other properties required for competitive priority ordering. For example, in Fox, Pai, Resnick (2023), the authors discuss vulnerabilities in on-chain auctions in the absence of resistance to censorship and describe the design of anti-censorship auctions using multiple concurrent proposers. However, they did not suggest a specific order for transactions.

There is also other research on building trust-minimized block construction mechanisms, including Flashbots' SUAVE, Sorella's Angstrom, Leaderless Auctions, Espresso, Offchain Labs' decentralized Timeboost, and Péter Szilági's Mandatory Public Transaction Inclusion.

We hope this article encourages L2 to consider using priority ordering (OP stack supports by default) 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 L1 and L2.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。