MEV-Share is a protocol aiming to distribute MEV revenue to Users within the MEV pipeline.
In addition to the User, Searcher, and Builder, a new entity called the Matchmaker emerges. The Matchmaker is responsible for tasks such as transmitting transactions, creating the final bundle, and protecting User transactions.
MEV-Share still has limitations, including excessive reliance on the Matchmaker and structural issues with MEV rewards.
In February of this year, MEV-Share, a new design for redistributing Maximal Extractable Value (MEV), was first introduced on the Flashbots forums and was also covered in the MEV track at ETH Denver in March. To make MEV-Share easier to understand, this article will cover the key features of MEV-Share compared to its predecessor, MEV-Boost, and show how it works at the high-level. I’ll also discuss some of the limitations of MEV-Share, and briefly share my thoughts on them. This article requires some prior knowledge of MEV-Boost.
There are many different players involved in the creation and redistribution of MEV on the Ethereum network. Users create transactions, Searchers combine these transactions with their own MEV transactions into a bundle. Once the bundle is delivered to the Builder, it combines the bundle and other transactions into a full block and sends it to the Proposer.
MEV-Boost and MEV-Share can be understood as protocols that define the interactions between these various players, with the goal of fairly distributing MEV among them. While MEV-Boost focuses on the relationship between Proposers and Builders to prevent them from engaging in malicious behavior, MEV-Share adds logic to the relationship between Searchers and Users. MEV-Share is not a separate protocol from MEV-Boost, but an attempt to take MEV-Boost to the next level.
The main feature of MEV-Share is the redistribution of MEV among Users. In the original MEV-boost design, Users were not directly rewarded when Searchers created MEV transactions with their transactions. In MEV-Share, the idea is to return some of the MEV revenue to the Users.
For example, suppose a User creates a transaction on Uniswap to swap a large amount of ETH for USDC, which causes a price difference in the ETH-USDC pool between DEXs, and a Searcher sees this and bundles an arbitrage transaction right after the User’s swap transaction to make a profit of 1 ETH. In MEV-Boost, if the Searcher bids to the Builder and the Searcher and Builder make a profit of 1 ETH, then in MEV-Share, 0.8 ETH of that 1 ETH will be distributed back to the User (the 80% to the user is just an example). The idea behind this is that Users are the ones who determine the usage of the blockchain ecosystem, and only their transactions can generate MEV, so rewarding them and protecting them will make the network more active.
MEV-Share introduces a new entity called Matchmaker in addition to User, Searcher, and Builder. The Matchmaker is a trusted entity that is expected not to engage in malicious behavior and is responsible for forwarding transactions between Users, Searchers, and Builders, creating the final bundle, and protecting User transactions. The interactions between them typically take place in the following order.
The User sends their transaction to the Matchmaker, who then shares only some of the information about the User’s transaction with searchers. For example, instead of revealing the full contents of the transaction, as shown in the json below, the Matchmaker selects and sends only the information that the transaction invoked a Uniswap V3 contract and traded ETH and USDC tokens.
Users can specify what information is shared in a transaction by specifying their own privacy preferences. The reason why only a small portion of the transaction is shown to Searchers is to protect the User’s transaction. If Searchers have all the information about a transaction, they can pass a bundle to the Builder or Proposer separately, bypassing MEV-Share. By putting this bundle in a block, the Searcher does not have to pay the User for the extracted MEVs. Therefore, the extraction of MEVs with the User’s transactions publicly available is the same process as in the current MEV-Boost.
[Case 1] When the Searcher exactly knows Users’ transactions.
Searchers create extractable MEV transactions from the complete transactions they get from the public mempool and the partial transactions they get from the Matcmaker, and send them back to the Matchmaker. If you create an MEV from the intact transactions, you should be able to create an accurate MEV bundle and send it to the Matchmaker. (You can also send it directly to the Builder.)
Using the json data below as an example, the User’s specific transaction, “0xhash”, is followed by the MEV transaction, “0xf145bh0t5”, which is the Searcher’s own creation, which is bundled in the “txs” field and sent to the Matchmaker.
[Case 2] Searcher doesn’t know User’s transactions
However, as mentioned earlier, Searchers do not have access to all of User’s transactions. So when a Searcher creates an MEV bundle, they have to ask the Matchmaker to find transactions in User that satisfy their specific criteria. Since it doesn’t know User’s transactions, it can only deliver part of the bundle (a partial bundle) by emptying User’s transactions when creating the bundle.
Here is an example of the json data that the Searcher sends to the Matchmaker. The bundle is prefixed with a “”, which means that if you have a transaction that meets the conditions below, put it in this location. The data in the Hints field is what Searcher is looking for. When the User’s transaction is executed, the transaction that interacts with the contracts “0x7a25” and “0xd14b” and generates the event log “0x41000” should go in the “” field.
The Matchmaker takes the partial bundle from the Searcher and searches for transactions that match the Searcher’s criteria. It then creates a bundle and sets a validity condition so that the User can get back some of the rewards for the transaction. The Matchmaker finally specifies the reward the User should receive.
In the example below, the validity condition requires the builder to send 1 ETH to the User named 0xprivsender. Assuming the builder is also a trusted entity, it will send 1 ETH to the User. Through this process, the User can be compensated when their transaction is inserted into a bundle and MEV is created, which is the main purpose of MEV-Share.
MEV-Share is a relatively new concept, and actual implementations are still in it early stages. In the further discussion section of Flashbot’s introduction to MEV-Share, it mentions a number of additional considerations and areas for improvement. In this article, I’ll go over what I consider to be the biggest limitations of MEV-Share and explain why I’m still skeptical about its applicability.
As we’ve seen in our walkthrough, the Matchmaker is supposed to find transactions for Users that match the Hints given by the Searcher, but there’s very little detail on how the matchmaking actually happens.
First, the Searcher needs to create an MEV bundle and present the Matchmaker with a bid for the bundle it created. However, if the Searcher only has partial information about the User transaction, it will be difficult to create a complete bundle. Also, the Searcher does not want to lose money, so it will be conservative with its bids. There is a concern that allowing Searchers to create and submit partial bundles may actually increase complexity and uncertainty for Searchers.
Requiring the Matchmaker to find transactions that meet certain criteria can also reduce overall efficiency. This is because, in MEV-boost, the Searchers created the entire bundle, whereas, in MEV-Share, the Searchers request transactions with specific conditions, and the Matchmaker has to search for transactions that meet the conditions of all Searchers one by one. We need to consider whether we are creating a trusted entity called Matchmaker to hide User transactions and leaving all the work to this omniscient Matchmaker.
The Matchmaker plays an important role in receiving all transactions from Users and providing a subset to Searchers, finding transactions that meet the Searchers’ requirements, and completing the bundle and delivering it to the Builder. In addition to the role of protecting User transactions, it almost inherits the role of Searchers in MEV-Boost, so high computing power will be required.
In MEV-Boost, where there are a small number of centralized entities called Builders, creating another centralized entity called Matchmaker risks introducing another attack vector due to centralization. Even if we exclude the possibility that the Matchmaker could be malicious, it could still be vulnerable to DoS attacks, and the later solutions presented in the article do not seem very complete.
There are two ways to solve this: one is to charge Searchers for submitting bundles, and the other is to manage the reputation of Searchers. The former option would add another layer of complexity to the protocol, making it less attractive for Searchers to participate, and would also require consideration of submission fees. The latter seems to be the most realistic, but it also increases the operational complexity of the Matchmaker, and there is a risk of a Sybil attack where a single Searcher makes requests through multiple nodes.
The initial Matchmaker will be powered by Flashbots, and there’s talk of decentralizing Matchmaker in the future, but there’s no word on what that will look like.
Matchmaker specifies a validity condition, which makes the Builder return a portion of the MEV to the User. One of the problems here is that the Matchmaker is ambiguous about which User should be rewarded. If the User transactions in the MEV bundle come from a single User and we know who the Searcher is, then the distribution of MEV is relatively straightforward, but this is not always the case. In the case of a bundle with multiple Users, it can also be difficult to determine which User should be rewarded and how much.
The biggest problem is that it’s hard to tell when a Searcher is pretending to be another User and including their own transactions in the bundle. If the MEV generated by a User transaction is very large, the Searcher’s strategy will be to include as many transactions in the bundle where they pretend to be a User as possible in order to exploit the reward, thus taking away some of the rewards. It doesn’t seem realistic for the Matchmaker to find and ban this.
In this article, we looked at the MEV-Share protocol, which was introduced as the next step after MEV-Boost, and discussed the limitations of the current design. It is significant because it is the first attempt to return MEV rewards to Users directly. However, in reality, the excessive trust structure of the Matchmaker and the difficulty of the MEV redistribution method are still considered to be major limitations. It remains to be seen whether MEV-Share will come up with feasible solutions to these problems and whether the protocol will become more advanced in the future.
Thanks to Kate for designing the graphics for this article.
The Graph
Cosmos
