Author: Dan Robinson,Dave White
##Compiled by: Joyce, BlockBeats
In this article, we will introduce MEV tax, which is a mechanism that any application can use to capture its own MEV. This mechanism is now available on OP Stack L2 such as OP Mainnet, Base and Blast, as block proposers on these chains follow a set of rules we call competitive prioritization.
In order to impose a MEV tax on one of the chains, the smart contract charges a fee that is a function of the transaction priority fee. If an application charges a $99 MEV tax for every $1 of searcher priority fees, it captures 99% of the competitive MEV for that transaction.
MEV tax is a simple technique that opens up a vast design space. You can think of them as allowing any application on the chain to run its own custom MEV auction without any of its own off-chain infrastructure, simply connecting to a single shared auction run by the block proposer.
We illustrate how MEV taxes can be used to address three major issues in MEV research:
Decentralized Exchanges (DEX) Routers optimize the prices received by exchangers;
Automated Market Makers (AMM), minimizing losses and rebalancing (LVR) experienced by liquidity providers;
Wallets that allow users to capture any "background running" MEV created by their transactions;
But there's a problem. The MEV tax is only effective if block proposers strictly adhere to competitive prioritization rules, which include ordering transactions by priority fees without censoring, snooping, or delaying any transactions. If block proposers deviate from these rules, they can evade the MEV tax and capture value for themselves. So today, MEV taxes rely on trusted L2 orderers and may not work at all on Ethereum L1, where block construction is dominated by competitive builder auctions that maximize proposals the income of the person.
Nonetheless, the power and flexibility of MEV taxation suggests that prioritization may be the right choice for platforms currently able to provide this service. The relative simplicity of competitive prioritization suggests that there may be a feasible way to enforce it in a decentralized manner without having to trust a single sequencer. We hope this article will stimulate further research on this issue.
When someone sends a transaction on Ethereum L1 or L2, they assign a priority fee and pay it to the block proposer. You can imagine this being specified as priorityFeePerGas, a number multiplied by the gas used in the transaction to get the builderPriorityFee—the total payment in ETH.
There is no provision in the Ethereum protocol that transactions in a block must be greedily sorted in descending priorityFeePerGas order. However, it is a popular way of building blocks - for example, it is the orderer of the OP Stack chain and the default algorithm used by geth and reth. Prioritization not only allows traders to effectively express the urgency of their transactions, but also naturally passes certain types of MEV to block proposers.
This happens because prioritization turns competition for MEV into a priority gas auction. When opportunities arise to profit from interactions with a chain, such as arbitrage with centralized exchanges via AMMs, searchers race to be the first to do so. If the chain uses prioritization to determine transaction inclusion and ordering, searchers compete by setting high-priority fees for their transactions.
In a competitive scenario where the risk-free profit competition is zero, the winning searcher should ultimately pay the full MEV priority fee. So, if a profit of 100 ETH is available by interacting with the contract, the first transaction to claim that profit will have a priority fee of 100 ETH set. (We discuss some caveats in the Limitations section).
Let’s say a smart contract wants to capture MEV from any transaction it interacts with. There is a lot of research into different application-specific ways that 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 built via competitive prioritization, then we have a universal signal about the amount of MEV in the transaction: the priority fee.
We propose that a smart contract could look at a transaction's priority fee and charge its own fee as some incremental 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 who sent 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 will result in a total payout of 100 ETH (1 ETH to the block proposer and 99 ETH to the smart contract). Any higher priority fee will make the transaction unprofitable; any lower priority fee will result in lost opportunities to competitors who set higher fees. This means that the smart contract has captured 99% of the MEV in the transaction.
#We call this additional fee imposed by the smart contract the MEV tax. The MEV tax allows an application to hijack prioritization for its own benefit, allowing it to recapture MEV for its users rather than leaking it to block proposers.
If the fee grows fast enough as a function of priorityFeePerGas, the proposer will only receive a negligible MEV. Since priorityFeePerGas is denominated in wei (billionths of 1 ETH), we need to deal with a lot of precision. For example, as long as the MEV tax is sensitive enough that a priorityFeePerGas of 50,000 would result in an excessive tax, then the total amount paid to the proposer would be less than $0.01. (5)
However, there is an important caveat. As discussed in the “Limitations” section, MEV taxes only work if block proposers follow certain rules (what we call “competitive prioritization”) and do not deviate in order to maximize their own revenue. these rules. Enforcing these rules in a trustless manner is an open question.
Here we outline how MEV can be captured on a chain that guarantees block construction using competitive precedence. Taxes can be used to mitigate three important issues in MEV: letting DEX interfaces improve exchangers' trade execution, letting AMMs reduce arbitrage losses on their LP, and letting wallets reduce users' MEV leakage by selling their reverse run rights.
In intent-based DEX routing protocols such as UniswapX and 1inch Fusion, the user (Alice) signs the exchange Intent, searchers compete to route or populate Alice the best price.
The current version of UniswapX uses two mechanisms to compete: a Dutch auction, where Alice’s limit price changes over time until the searchers fill it up; and the initial chain Lower Request for Quotation (RFQ) auction, used to set the starting price for a Dutch auction.
On a platform that guarantees competitive prioritization, UniswapX can replace these mechanisms with a single mechanism: the MEV tax. It does this by letting users sign orders that anyone can fill immediately, but with the execution price set as a function of the trade’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). minimumPrice may be some fixed value that she expects to be significantly lower than the current price.
Searchers will compete to fill Alice's order by submitting transactions. The order will be fulfilled regardless of which deal has the highest priority fee and is not restored, which should guarantee the exchanger 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 approx. is 50,000. (Note that in a transaction costing 200,000 Gas, this would result in only ~10 billion wei (~$0.000035) being paid to the block proposer.)
With UniswapX This has some potential benefits compared to using existing mechanisms.
Orders using the MEV tax can be filled faster and at a better price than orders using a Dutch auction. 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 taxes can often be filled in the next block while capturing the vast majority of MEV.
Unlike off-chain RFQs, auctions for orders using the MEV tax will occur automatically when on-chain transactions are executed. This means that the winning bidder is guaranteed to commit to filling the order only if the on-chain transaction is successful. This can make it easier for on-chain liquidity like AMMs to compete with off-chain liquidity, meaning UniswapX can serve as a more efficient router for multi-pool systems like Uniswap v4.
Normally, AMM leaks value to arbitrageurs who trade based on the outdated price at the top of the block, as As discussed in the Losses and Rebalancing paper. We can use MEV tax to let AMM capture MEV. For the sake of simplicity, we will discuss how to function on AMM without centralized liquidity. (If you are interested in how to solve this kind of problem by pooling liquidity, Sorella will release a solution soon.)
AMM can do this by charging an additional fee as a transaction priority fee function to capture MEV, allowing it to auction the right to be the first to trade in a block. There are several ways to calculate and value this fee. We will discuss one that is arguably neutral - in units of pool liquidity, sqrt(xy). The winning trade will be the one that increases the pool’s liquidity the most.
When executing the first transaction on the pool in a block, the pool can enforce the condition (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 motivate Arbitrage traders trade at the true price, and after that trade, the midpoint price in the pool should be the true price.
After the first trade, trades can proceed as on Uniswap v2, with fixed swap fees. Uninformed traders who want to trade in the pool without paying the additional MEV tax will have a lower priority fee set.
There are many other ways to implement a MEV tax on AMMs, which will have different effects. For example, an MEV tax could be denominated in the input or output tokens of a swap, could affect the percentage of swap fees applied by a pool, or could determine the minimum price for user transactions. We think this is an interesting design space worth exploring.
The above description shows how certain applications can be designed to avoid MEV leaks. However, what if a wallet wants to try and help users capture the MEV they create from any transaction they interact with any application, even ones that don’t include MEV taxes?
For example, when Alice makes large transactions on AMM, she sometimes creates arbitrage opportunities for "backrunners" to pull the price back. This would normally be leaked to MEV, not 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.
The MEV tax combined with an intent-based smart contract wallet allows us to build an alternative system to capture MEV running in the background for Alice. Assume that Alice did not create a transaction to transact on the AMM, but instead signed an intent that anyone could submit to Alice's smart contract wallet to have it take that action. Alice's smart contract wallet charges a MEV tax to anyone who submits the transaction, and the tax is paid to Alice.
Searchers who submit Alice's intent will have the exclusive right to de-run her, as they can do so automatically within the same transaction. Therefore, if the search is competitive, all of Alice's profits should accrue to Alice via the MEV tax.
Please note that this system does not necessarily protect users from attacks involving transactions by front-running users, as transactions by front-running users may be able to avoid paying MEV taxes to that user. This issue (and some possible mitigations) is discussed in more detail in the Limitations section below. Still, this could at least be an improvement over systems that use a common memory pool without any mitigations.
In addition to these examples, other potential uses for MEV taxes may include almost all of the current use cases using off-chain or Dutch auctions. Everything, such as:
Protocols where oracles capture the extractable value of the oracles they create, such as Oval;
Blend, etc. NFT mortgages Refinancing auction for loan protocols;
Leakage value for loan protocol liquidation is lower than Dutch auction;
The above solution is designed to capture MEV interactions with a single application. But sometimes searchers may be able to get more value by interacting with multiple applications in the same transaction.
If only one of these applications has a MEV tax, all MEV in the transaction should go to the application with a MEV tax, no matter how high or low the MEV tax is.
But what if the searcher's transaction interacts with two applications that use MEV tax? For example, what if there is some MEV that can only be captured by filling one of the MEV tax-paying UniswapX orders above against a MEV-taxed AMM?
In this case, the relative amount of excess MEV captured by each application depends on how those applications set their MEV taxes. 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 priority in the following equation:
tax_1( priorityPerGas) + tax_2(priorityPerGas) = total MEV
(Technically, we can add a third item for priorityPerGas * gasUsed to account for the priority paid to the block proposer fee, but we will ignore this, under normal circumstances it is probably negligible)
In the simple case where MEV tax is linearly related to priorityPerGas (so tax_1(priorityPerGas) = a_1 * priorityPerGas), you can solve for the MEV share 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
Setting your own MEV When it comes to taxes, apps face a trade-off - higher taxes allow it to get a larger share of cross-application MEV when it occurs, but that means it may miss out on some cross-application MEV if there's a competing way to extract it. For example, if there is an AMM that charges MEV tax on every transaction, then the MEV tax UniswapX order may be more likely to be filled by a different AMM or off-chain filler.
In many cases, there may be an equilibrium in which two applications design their MEV taxes so that they share the MEV in a way that maximizes their respective profits. For example, a MEV tax AMM might want to capture value from a single informed trader near the top of the block, but then want to provide liquidity at a lower fixed rate to other traders and applications (including applications using the MEV tax). cost. In this case, the AMM might set a relatively low MEV tax (e.g. $0.00001 * priorityFeePerGas) so that the arbitrage trade (if any) occurs early in the block and then impose no MEV tax on subsequent transactions in the block . Applications like UniswapX that want to interact with AMMs can set a higher MEV tax (e.g. $0.01 * priorityFeePerGas) to ensure their transactions are included after the pool has already arbitraged. Given these relative taxes, even if there was only $1 MEV and $50,000 MEV in the UniswapX order, the AMM would end up being arbitraged first.
We believe this is a broad design space worthy of future research.
MEV taxes have some complexities and shortcomings that we believe are interesting areas for future research.
The MEV tax is not incentive compatible for monopoly block proposers. They only work if there is a level playing field for transaction inclusion, which is only the case if block proposers follow what we call "competitive prioritization" rules rather than maximizing their own revenue. will happen. Informally enumerate some suggested rules, including but not limited to the following:
Prioritization. Transactions within the block must be ordered by priorityFeePerGas in descending order.
Resist censorship. If the block proposer receives transaction t1 during the block, and the block is not full or contains some transaction t2, such as t2.priorityFeePerGas < t1.priorityFeePerGas, then the block must contain transaction t1.
Privacy before transaction. Block proposers must accept transactions via a private endpoint and may not share such transactions with anyone else before submitting them to a block, or use the contents of these transactions as input for building their own transactions.
No final review. Block proposers must set a clear block time. Before this time, they will accept transaction requests from anyone; after this time, they will no longer accept transaction requests from anyone.
Violations of one or more of these attributes may undermine the effectiveness of the MEV tax. Block proposers who violate censorship can avoid most MEV taxes by excluding competing transactions and submitting zero-priority transactions that take advantage of themselves. Block proposers who violate pre-transaction privacy can steal MEV from other transactions or look at their priority fees to know exactly how high they need to set their fees, while block proposers who are able to submit transactions later than others will gain Free'Finally look at whether to pay a higher price than others for the opportunity, both of which can create adverse selection problems that ultimately hinder competition.
Unfortunately, though The first attribute is easily enforced at the protocol layer, but enforcing the other attributes in a trustless manner is an open question in the absence of enforcement at the protocol layer. A single sequencer committed to these rules needs to be trusted not to deviate from them, and if the proposer outsources block construction to a competitive revenue-maximizing auction (such as Ethereum L1's MEV-Boost), blocks may not follow them.
These problems can be "solved" by a single trusted sequencer that promises to use competitive priority ordering for block building. They can also be solved by decentralized mechanisms using some combination of consensus, cryptography, and/or a trusted execution environment, such as Sorella’s Angstrom, Flashbots’ SUAVE, leaderless auctions, or multiplicity.
An exception to the normal operation of the MEV tax occurs when a block is completely full. In this case, the block proposer may have to abandon lower priority transactions instead of simply including them in the block. Because transactions that interact with MEV tax applications may have very low priority fees, these applications may be crowded out by applications that do not use MEV taxes or have very low MEV taxes. However, in a chain that uses a mechanism like EIP-1559 to set a separate base fee, it should be relatively rare for blocks to be completely filled. Additionally, given that certain transactions need to be delayed when a block is full, delaying transactions that represent lower urgency by setting a higher MEV tax might be a reasonable outcome.
The 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 restored transactions being included on-chain, paying some base fees and causing chain congestion.
If the sorter could completely exclude failed transactions, this would alleviate this problem, although this is difficult to achieve even with a centralized sorter. (It also would not strictly adhere to the censorship-resistant properties mentioned above, although that definition could be tweaked.) More sophisticated sequencers could optimize this process by allowing transactions to specify which contested auctions they are participating in, allowing the sequencer to sufficiently information to skip subsequent transactions that it knows will fail.
MEV tax only works if there is competition between searchers, which means the opportunity needs to be Well known to some extent. For applications like AMM, where opportunities are visible on-chain, this should happen naturally. But for applications such as intent-based routing or background auctions, this means the application may need to share the user's intent with the searcher.
In some cases, the temporary loss of privacy caused by propagating user intent before it is realized may leak value in a way that the MEV tax cannot recover.
For example, suppose Alice wants to purchase low-liquidity tokens using the backend auction protocol described above. She publishes the signed intent of the smart contract wallet to purchase the token on the AMM and sets a certain slippage tolerance. A searcher can compete in a high-priority trade to push the price of that token up to her slippage tolerance without filling the user’s order. Winner Bob can then satisfy Alice's intentions in a non-competitive way by including it in a low-priority transaction and running it in reverse, thereby sandwiching Alice's transaction and giving her a worse price while escaping her MEV tax. Similar issues can arise when purchasing NFTs.
It should be noted that such an attack is risky for Bob because he cannot guarantee atomicity between buying the token and selling it to Alice. A naive Bob may fall into a "clamping and tearing" trap: Alice first announces her intention to buy a worthless token from herself, and Bob purchases the token in order to flank her transaction, but before Bob completes the flanking, Alice withdraws her intention.
Applications can also mitigate this by limiting the set of searchers they share intent with and monitoring their behavior, as many existing order flow auctions do.
It’s also possible to combine MEV taxes with privacy-aware builder features, like the one envisioned by Flashbots for the SUAVE design.
Finally, if Alice decides that the cost of sharing the intent outweighs the benefits of competitive search, she can construct the transaction herself and submit it directly to the block. As mentioned above, an ideal implementation of competitive prioritization would provide block proposers with pre-transaction privacy.
Priority gas auction. The Flash Boys 2.0 paper, which coined the term "miner extractable value," examines some of the dynamics of prioritization in decentralized blockchains. The paper states that Ethereum miners (when the network used proof-of-work) already prioritized transactions, and that arbitrageurs relied on this behavior to participate in "priority gas auctions" in which they bid for the right to be included in the first zone blocks, which results in the majority of MEV arbitraged by decentralized exchanges being owned by miners.
First come, first served. Some attempts to mitigate MEV through transaction ordering rules, such as Themis or Arbitrum One's current orderer (7) focus on enforcing a different ordering rule, first come first served (sometimes called "fair ordering"), in which block proposers must Sort transactions in the order they see them.
Prioritization takes a different approach - transactions arriving within a given time are treated equally and sorted by their declared priority.
First come, first served is difficult to implement or even define in a real network environment with multiple validators. Even with a single trusted sequencer, it can lead to wasteful latency contention and spam. Finally, an MEV tax might be able to eliminate certain types of MEV that first-come, first-served ordering cannot, such as arbitrage profits from discrete “jumps” in asset prices. The potential advantages of priority ordering over first-come, first-served ordering are related to some extent to the advantages of discrete-time over continuous-time exchange discussed in Budish, Cramton, Shim (2015).
Meanwhile, while prioritization seems to leak value to MEV by default, this post shows how to design your application to regain it.
Cost sharing. Blast is Ethereum L2 and shares a portion of the priority and base fees with the smart contracts accessed in transactions.
MEV tax allows something similar (at least for prioritized fees) but can be implemented at the application layer on any chain using competitive prioritization without requiring special support for fee sharing. They also allow applications to define their own tax as a custom function of the priority fee, providing greater flexibility and potentially improving the composability of MEV-aware applications.
Trustless solution. This article focuses on the motivations for platforms to use competitive prioritization and ways to exploit the platform, rather than on how to enforce it in a trustless manner.
Each of the other properties required for competitive prioritization has been previously discussed significantly. For example, in Fox, Pai, Resnick (2023), the authors discuss the vulnerabilities of on-chain auctions in the absence of censorship resistance and describe the design of censorship-resistant auctions using multiple concurrent proposers. However, they did not suggest a specific sequence of transactions.
There is other research into building trust-minimized block building mechanisms, including Flashbots’ SUAVE, Sorella’s Angstrom, Leaderless Auctions, Espresso and Offchain Labs’ decentralized Timeboost, and Péter Szilági’s mandatory public transaction inclusion.
We hope this article encourages L2 to consider using prioritization (supported by default by the OP stack), and encourages applications to try MEV taxes if supported. We also hope that it inspires further research into trust-minimizing competitive prioritization protocols on L1 and L2.
The above is the detailed content of New Article from Paradigm: MEV Taxation and Prioritization. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
