This article is from "Priority Is All You Need"
Original authors: Dan Robinson, Dave White
Compiled by: Odaily Planet Daily, How
Paradigm published the article "Priority Is All You Need" on June 4th, detailing the new mechanism MEV tax.
MEV tax is a novel mechanism that allows applications to capture their own generated MEV, instead of leaking it to block proposers (for content related to block proposers, please refer to the footnote at the end of the article). This mechanism utilizes competitive priority sorting during block construction. Under this sorting method, transactions are arranged in descending order based on priority fees, and transactions with higher priority are packed into blocks first. MEV tax is achieved 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 own customized MEV auctions without the need for any off-chain infrastructure, by participating in a single shared auction run by block proposers.
The emergence of the MEV tax mechanism may have an impact on the existing DeFi ecosystem:
Changing the traditional distribution of MEV: Traditionally, most of the MEV flowed to block proposers, but MEV tax allows applications to capture this value and redistribute it to their users or for other purposes.
Increasing application revenue and user experience: Applications can increase their revenue by implementing MEV tax, while providing a better user experience, as users can achieve higher transaction execution efficiency and better transaction prices.
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, thereby enhancing the efficiency and sustainability of the DeFi ecosystem.
Quotation
In this article, we introduce MEV tax, a mechanism that allows any application to capture its own MEV (maximum extractable value).
This mechanism can be immediately used 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 call competitive priority sorting.
To implement MEV tax on these chains, a smart contract will charge a fee based on the transaction's priority fee. We demonstrate that if an application levies a 99% MEV tax on a searcher for every $1 of priority fee paid, 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-chain to run its own customized MEV auction without any off-chain infrastructure of its own, simply by connecting to a shared auction run by block proposers.
We demonstrate how MEV tax can be used to address three main issues in MEV research:
Optimizing the decentralized exchange (DEX) router for the prices received by traders
Minimizing the losses suffered by liquidity providers due to rebalancing (LVR) in automated market makers (AMM)
Enabling wallets to capture any "rollback" MEV generated by their exchanges
But there is a catch. MEV tax only works if block proposers strictly adhere to the competitive priority sorting rules, including sorting transactions by priority fee without censorship, front-running, or delay. If block proposers deviate from these rules, they can bypass 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, as on the Ethereum mainnet, block construction is primarily dominated by competitive builder auctions, maximizing proposer revenue.
Nevertheless, the capabilities and flexibility of MEV tax suggest that priority sorting may be a correct choice for platforms that can currently provide priority ordering. 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 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. You can imagine this is specified through priorityFeePerGas, which multiplied by the gas used in the transaction gives builderPriorityFee, the total amount of ETH paid.
The Ethereum protocol does not specify that transactions in a block must be greedily sorted in descending order by priorityFeePerGas. However, this is a popular method for constructing blocks. For example, this is the sequencer on the OP Stack chain, 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 channels certain types of MEV to block proposers.
This happens because priority sorting turns competition for MEV into a priority gas auction. When there is an opportunity to profit from interacting with the chain, such as arbitrage between AMMs and centralized exchanges, searchers compete to be the first to seize the opportunity. If the chain uses priority sorting to determine transaction packaging and ordering, searchers compete by setting high priority fees in their transactions.
In a competitive scenario where risk-free profit is compressed to zero, the winning searcher should ultimately pay the full amount of MEV as a priority fee. Therefore, if a profit of 100 ETH can be obtained by interacting 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 from any interaction with it. There is a wealth of research literature on specific ways in which smart contracts attempt to capture their own MEV.
But in practice, we don't necessarily need to know any specific information about the application. If we know that blocks are constructed through competitive priority sorting, then we have a uniform signal for the amount of MEV in a transaction: the priority fee.
We propose that a smart contract can look at the priority fee of a transaction and charge its 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 that searcher. If there is 100 ETH of MEV in an opportunity, 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 with a higher fee. This means that the smart contract captures 99% of the MEV in the transaction.
We call this additional fee imposed by the smart contract 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 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 quintillionth of an ETH), we have plenty 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 tax high enough to be prohibitive, the total amount paid to the proposers would be less than $0.01.
However, there is an important caveat. As discussed in the "Limitations" section, MEV tax only works if block proposers adhere to certain rules (which we call "competitive priority sorting") rather than deviating from these rules to maximize their own income. Enforcing these rules in a trustless manner is a pending issue.
Single application MEV capture
On a chain that guarantees block construction using competitive priority sorting, MEV tax can be used to address three important issues with MEV: improving trader execution on DEX interfaces; reducing arbitrage losses for AMMs; and reducing user MEV leakage by selling backrunning rights.
DEX router for searchers
In intent-based DEX routing protocols (such as UniswapX and 1inch Fusion), a user (Alice) signs an intent to exchange, and searchers compete to route or fill that intent at the best price.
The current version of UniswapX uses two mechanisms to run this competition: a Dutch auction, where Alice's limit price changes over time until filled by a searcher, and an initial off-chain request for quote (RFQ) auction to set the starting price for the Dutch auction.
On a platform that guarantees competitive priority sorting, UniswapX can replace these with a mechanism: MEV tax. This can be achieved by allowing the user to 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.
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 would be approximately 50,000. (Note that in a transaction costing 200,000 gas, this would result in paying only about 10 billion wei (about $0.000035) to the block proposer.)
This has some potential advantages compared to the existing mechanisms used in UniswapX.
Orders using MEV tax can be completed faster and at better prices than orders using Dutch auctions. As described in this article, on-chain Dutch auctions leak some value to MEV due to price changes between blocks and may require multiple blocks to complete. In contrast, orders using MEV tax can typically be completed in the next block, capturing the vast majority of their MEV.
Unlike off-chain RFQ, auctions to fill orders using MEV tax occur atomically during on-chain transaction execution. This means the winning bidder can guarantee that the order will only be filled if their on-chain transaction is successful. This can make on-chain liquidity (such as AMMs) more competitive with off-chain liquidity, meaning UniswapX can be a more effective router for multi-pool systems (such as Uniswap v4).
Automated Market Makers (AMM)
Typically, AMMs leak value due to arbitrageurs trading at stale prices at the top of a block, as discussed in the "loss-vs-rebalancing" paper. We can use MEV tax to allow AMMs to capture this MEV. For simplicity, we will discuss how to achieve this on an AMM without centralized liquidity. (If you are interested in how to address such issues with centralized liquidity, Sorella will soon release a solution.)
AMMs can capture MEV by charging an additional fee based on the transaction's priority fee, allowing them to auction off the right to prioritize transactions in a block. There are many methods for calculating and pricing this fee. We will discuss a method that can be considered neutral—using the square root of the pool liquidity units (sqrt(xy)). The winning transactions will be those that increase the pool liquidity the most.
When executing the first transaction on a pool in a block, x_end * y_end > x_start * y_start, the pool can enforce the condition (as a constant a):
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2. This formula will incentivize arbitrage transactions to trade at the true price, and after that transaction, the midpoint price of the pool should be the true price.
After that first transaction, transactions can work as in Uniswap v2, using a fixed exchange fee. Uninformed traders hoping to trade without paying additional MEV tax will set lower priority fees.
There are many other methods for implementing MEV tax on AMMs, each producing different effects. For example, MEV tax can be represented in input or output tokens of the exchange, can affect the exchange fee percentage of the pool application, or can determine the minimum price for user transactions. We believe this is an interesting design space worth exploring.
Backrunning auctions
The above descriptions show how to design certain applications to avoid leaking MEV. However, what if a wallet wants to help its users capture the MEV generated when interacting with any application, even those that do not include MEV tax?
For example, when Alice makes a large trade on an AMM, she sometimes creates an arbitrage opportunity for "backrunners" to restore the price. Typically, these opportunities leak to MEV instead of being owned by Alice.
MEV-Share and MEVBlocker are two protocols that allow users to capture MEV from their transactions, but they rely on complex off-chain auction systems. "The Orderflow Auction Design Space" describes some other solutions.
When MEV tax is combined with intent-based smart contract wallets, we can build an alternative system to capture Alice's backrunning MEV. Suppose Alice did not create a transaction to trade on the AMM, but instead signed an intent that anyone could submit to her smart contract wallet to execute that operation. Alice's smart contract wallet collects the MEV tax from the person submitting that transaction, which is paid to Alice.
The searcher submitting Alice's intent has exclusive rights to backrun her, as they can atomically perform this operation in the same transaction. Therefore, if the search competition is fierce, all profits from backrunning Alice should be owned by Alice through her MEV tax.
It should be noted that this system may not fully protect users from frontrunning attacks, as frontrunners may be able to avoid paying MEV tax to the user. This issue (and some possible mitigations) will be discussed in detail in the "Limitations" section below. However, this is at least an improvement compared to a public mempool system with no mitigations.
Other use cases
In addition to these examples, other potential uses of MEV tax include almost all current scenarios that use off-chain or Dutch auctions, such as:
Protocols like Oval, which can extract value (OEV) by capturing the oracles they create.
Refinancing auctions in NFT collateral lending protocols like Blend.
Liquidation in lending protocols, with less value leakage than Dutch auctions.
Cross-application MEV capture
The above solutions are designed to capture MEV generated when interacting with a single application. However, sometimes searchers can capture more value by interacting with multiple applications in the same transaction.
If only one of these applications uses MEV tax, then all MEV from the transaction should belong to the application using MEV tax, regardless of the level of MEV tax.
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 a UniswapX order with MEV tax to counteract an AMM with MEV tax.
In this case, the relative amount of excess MEV captured by each application is determined by the MEV tax set by these applications. If the value app_i as MEV tax is given by the function tax_i(priority), 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 priorityPerGas * gasUsed to account for the priority fee paid to the block proposer, but we will ignore this as, as discussed in Appendix A, the priority fee may be negligible in normal circumstances.)
In the simple case of linear MEV tax in priorityPerGas (so 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 - a higher tax rate allows them to capture a larger share of cross-application MEV when it occurs, but this means they may miss out on some cross-application MEV if there are competing extraction methods. For example, if an AMM charges MEV tax for every transaction, then an MEV tax UniswapX order may be filled by a different AMM or off-chain filler.
In many cases, there may be a balance where two applications design their MEV tax to share MEV in a way that maximizes their respective benefits. For example, an AMM with MEV tax may want to extract value from a single informed trader near the top of a block, but then want to provide liquidity to other traders and applications (including traders and applications using MEV tax) at a lower fixed cost. In this case, the AMM may 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 transactions 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 arbitrated. With these relative taxes, even if there is only $1 of MEV in a UniswapX order and $50,000 of MEV, the AMM will still be arbitrated first.
We believe this is a broad design space worth exploring in future research.
Limitations
MEV tax has some complexities and shortcomings. We believe these are interesting areas for future research.
Incentive incompatibility
MEV tax is incompatible with incentives for monopolistic block proposers. They only work in the context of fair competition in transactions, which only occurs when block proposers follow rules we call "competitive priority sorting" rather than maximizing their own income. We suggest these rules should include:
Priority sorting: Transactions in a block must be sorted in descending order of priorityFeePerGas.
Censorship resistance: If a block proposer receives transaction t1 when constructing a block and the block is not full or contains transaction t2, and t2.priorityFeePerGas t1.priorityFeePerGas, then the block must include transaction t1.
Transaction front-running privacy: Block proposers must accept transactions through private endpoints and must not share these transactions with anyone or use the contents of these transactions to construct their own transactions before submitting the block.
No last-minute determinism: Block proposers must set a clear time (blockTime) at which they accept transactions from anyone, and after which they do not accept transactions from anyone.
If one or more of these properties are violated, it may weaken the effectiveness of MEV tax. Block proposers violating censorship resistance can bypass most MEV tax by excluding competitive transactions and submitting a zero priority transaction, giving themselves an opportunity. Block proposers violating transaction front-running privacy can steal MEV from other transactions, or peek at their priority fees, knowing how high a priority fee needs to be set to outbid others, and a proposer who can submit a transaction later than others can freely "last-minute determine" whether to bid higher than others, causing a winner's curse problem, ultimately suppressing competition.
Unfortunately, while the first property is easily enforceable at the protocol layer, enforcing the other properties in a trustless manner is a pending issue.
In the absence of enforcement at the protocol layer, trust in a single sequencer committed to these rules is needed. It may also be possible to use a decentralized mechanism using a combination of consensus, cryptography, and/or trusted execution environments, such as Sorella's Angstrom, Flashbots' SUAVE, Leaderless Auctions, or Multiplicity.
Full blocks
MEV tax's normal operation encounters exceptions when blocks are completely full. In this case, block proposers may have to exclude low-priority transactions rather than just include them later in the block. Since transactions interacting with applications using MEV tax are likely to have extremely low priority fees, these applications may be crowded out by applications not using MEV tax or using very low MEV tax. However, in a chain with a separate base fee set using a mechanism similar to EIP-1559, the situation of completely full blocks should be rare. Additionally, given the need to delay some transactions when blocks are full, delaying transactions expressing lower urgency by setting higher MEV tax may be a reasonable outcome.
Rollback transactions
MEV tax essentially relies on single-block auctions, where each "bid" is a transaction. One drawback of such auctions is that unsuccessful bids often result in rollback transactions being included on-chain, paying some base fee, and causing chain congestion.
If the sequencer is able to completely exclude failed transactions, this would mitigate the issue, although it is difficult to achieve even in the case of a centralized sequencer. (This also does not fully comply with the censorship resistance property described above, although that definition can be adjusted.) A more sophisticated sequencer might optimize this process by allowing transactions to specify the disputed auctions they participate in, enabling the sequencer to skip subsequent transactions it knows will fail.
Leakage of User Intent
MEV tax is only effective when there is competition among searchers, which means opportunities need to be somewhat widely known. For applications like AMMs, opportunities on-chain are visible and should naturally occur. But for intent-based routing or sniping auction applications, this means the applications may need to share user intent with searchers.
In some cases, broadcasting user intent before realizing the intent may temporarily compromise privacy in a way that leaks value irrecoverably from MEV tax.
For example, suppose Alice wants to purchase a low liquidity token using the aforementioned sniping auction protocol. She posts a signed intent from her smart contract wallet to buy the token on an AMM and sets some slippage tolerance. Searchers can competitively push up the price of the token to her slippage tolerance in high priority transactions without filling the user's order. Then, the winner Bob can non-competitively fulfill Alice's intent by including and front-running Alice's intent in low priority transactions, giving her a worse price while evading her MEV tax. Similar issues may occur when purchasing NFTs.
It is worth noting that such attacks are risky for Bob, as he cannot guarantee the atomicity between purchasing the token and selling it to Alice. A naive Bob may fall victim to the "sandwich front-running" trap, in which Alice posts an intent to purchase a worthless token from herself, causing Bob to purchase it in hopes of front-running her trade, but Alice revokes her intent before Bob can complete the sandwich.
Applications can also mitigate this situation by limiting the set of searchers with whom they share intent and monitoring their behavior, similar to many existing order flow auctions.
MEV tax can also be combined with privacy-aware builder features, as envisioned in Flashbots' SUAVE design.
Finally, if Alice believes that the cost of sharing her intent outweighs the benefits of competitive search, she can construct a transaction herself and submit it directly to the block. As mentioned above, the ideal implementation of competitive priority sorting would provide transaction front-running privacy for block proposers.
Discussion and Prior Work
Priority Gas Auctions. The paper "Flash Boys 2.0" studied some dynamics of priority sorting in decentralized blockchains, creating the term "miner extractable value." The paper observed that Ethereum miners (when the network uses proof of work) already sort transactions by priority and arbitrageurs rely on this behavior to participate in "priority gas auctions," where they bid for the right to be included in a block first, leading to most MEV from decentralized exchange arbitrage accumulating to miners.
First-come, first-served. Attempts to mitigate MEV using different sorting rules (such as Themis or Arbitrum One’s current sequencer) have focused on implementing different sorting rules, such as first-come, first-served (sometimes called "fair sorting"), where block proposers must sort transactions in the order they receive them.
Fair sorting is difficult to enforce or even define in a real network environment with multiple validators. It may also lead to wasted delay races and spam, even with a single trusted sequencer. Finally, MEV tax may be able to eliminate certain "first-come, first-served" MEV, such as arbitrage profits from asset price discontinuities. The potential advantage of priority sorting over first-come, first-served sorting is somewhat related to the advantage of discrete time over continuous time exchanges discussed in Budish, Cramton, Shim (2015).
While priority sorting seems to default to leaking value to MEV, this article demonstrates how applications can re-capture 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 sorting, without requiring special support for fee sharing. They also allow applications to define their tax as a custom function of the priority fee, providing greater flexibility and potentially increasing the composability of MEV-aware applications.
Trustless solutions. This article focuses on the motivations for platforms using competitive priority sorting and methods for leveraging platforms using competitive priority sorting, rather than discussing how to execute it trustlessly.
There has been extensive discussion of each of the other properties required for competitive priority sorting in previous work. For example, in Fox, Pai, Resnick (2023), the authors discuss vulnerabilities in on-chain auctions without censorship resistance and describe the design of censorship-resistant auctions using multiple concurrent proposers. However, they do not advocate for a specific order of 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 Enforced Public Transaction Packing.
Conclusion
We hope this article encourages L2s to consider using priority sorting (OP stack supports it by default) and incentivizes applications to experiment with MEV tax where supported.
We also hope it sparks further research into trust-minimized competitive priority sorting protocols on L1 and L2.
Footnotes
In this article, we use "proposer" to refer to the participant or process that determines which transactions are included in a specific block. On Ethereum L2, this role is typically filled by a "sequencer." On Ethereum L1, it is filled by a specific Ethereum validator called a proposer, although proposers usually outsource the task of constructing blocks to a competitive auction involving "relayers" and "builders." The details of how these responsibilities are divided are beyond the scope of this article.
The priority fee for each Gas is not explicitly specified in the transaction but can be calculated within the transaction. The transaction specifies the Gas price, but Ethereum also charges a base fee, which is extracted from the Gas price and destroyed. For MEV tax, the base fee should be ignored as it is not under the control of the transaction sender. The priority fee for each Gas (i.e., the price portion of the transaction fee flowing to the block proposer) can be calculated in Solidity as priorityGasPrice = tx.gasprice - block.basefee.
We can simply define "MEV" to exclude any profit for searchers and only refer to the value flowing to the validators.
Please note that proposerPriorityFee cannot actually be calculated as a multiple of the total gaspriorityFeePerGas used in the transaction during the contract period, as it is not known how much Gas the transaction will ultimately use. However, this is usually irrelevant because all we need is its upper limit. For safety, you can multiply priorityFeePerGas by 30 million - the current maximum Gas in an Ethereum block. Overestimating this value will only mean that the MEV tax accounts for a larger proportion of the MEV.
Assuming a transaction cannot exceed 30 million Gas, then a priorityFeePerGas of 50,000 will result in a Gas payment of 1500 gwei - approximately $0.006 at an ETH price of $4000.
If priorityFeePerGas is set to zero for the profit-maximizing arbitrage trade, it should correspond to the same trade maximizing AMM.
Arbitrum has discussed replacing it with a form of priority sorting called Timeboost, but as of the writing of this article, this form has not been deployed into production.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
