Remeasuring the Arbitrage and Sandwich Attacks of Maximal Extractable Value in Ethereum

Ethereum (Buterin et al., 2013) is one of the most well-known blockchain platforms. In Ethereum, there are two types of accounts, i.e., contract accounts and Externally Owned Accounts (EOAs), where the former one corresponds to a deployed smart contract and the latter is controlled by a pair of keys. All interactions among accounts are conducted in transactions, which are then packed into blocks. The role responsible for constructing blocks is called the block creator, while the role for block broadcasting and proposing consensus is referred to as the block proposer. To incentivize block creators to include a transaction into a block, the transaction initiator should attach a piece of transaction fee, which will then be taken by the block proposers (miners or validators) The original consensus algorithm of Ethereum was PoW. In September 2022, Ethereum’s consensus shifted to PoS, known as The Merge (Foundation, 2023). In the PoS consensus, participants apply to become validators by staking Ether, who are responsible for validating and packaging transactions.

In the standard Ethereum protocol, transactions will be broadcasted and added to the proposers’ trading pool, so called mempool. Proposers will select some of them and then append them into the latest block. To maximize their profits, proposers usually select the ones with the highest transaction fee. Instead of mempool, private transaction pool is introduced and can be used as a method for sending transactions. Users can directly send their transactions to a private transaction pool owned by a miner (Flashbots, 2021).

Ethereum allows smart contracts to interact with each other for a complicated functionality, where they are jointly named as decentralized applications (DApps) (dap, 2020). More specifically, if a DApp serves financial purpose, we often refer it to a decentralized finance (DeFi) DApp. DeFi allows users to perform financial operations based on decentralized platforms, instead of through the real-world centralized and regulated one. Currently, the DeFi service covers a lot area, e.g., currency exchange (Lehar and Parlour, 2021), fund borrowing and lending (aav, 2019, 2021, 2023), liquidity management (yea, 2020), and cross chain (syn, 2023). Among all blockchain platforms, Ethereum has the most prosperous DeFi ecosystem. According to the statistics (def, 2020), its total value locked (TVL), a widely-adopted metric to measure the prosperity of DeFi ecosystem, peaked in November 2021, around $108 billion, around 60% of all TVL among all public blockchain platforms. Among the various types of DeFi DApps, decentralized exchanges (DEXes) are the most prevalent. Leveraging smart contracts, DEXes ensure the transparency in the execution process. Users can deposit a sum of tokens into a pool and receive a certain amount of tokens in return, which represent the user’s contribution to the liquidity of the pool. Trading on DEX, often referred to as a swap, may encounter price slippage, refers to the price gap between the the actual trading price and the quoted price at the time of transaction.

Maximal extractable value (MEV) refers to any value that can be extracted from block production beyond the standard block reward and gas fees. MEV can be extracted by selecting, adjusting, or reordering transactions during processing a block (Daian et al., 2020). Other than proposers, traders can also participate into MEV activities, such as exploiting price discrepancies across different DApps’ assets or manipulating transaction slippage to gain profits. Thus, we name them as MEV searchers.

Additionally, a sandwich attack involves both back-running and front-running against one or multiple victim transactions. It is a strategy that exploits price slippage and transaction order to impact the execution price of a target transaction. The most common form of a sandwich attack targets a victim transaction that susceptible to significant slippage. The attacker inserts two transactions before and after the victim’s, with the former increasing the slippage and the latter profiting from the slippage.

Before the Merge, Flashbots architecture consisted of three main components: searchers (including MEV searchers and regular traders), relays, and miners. Searchers directly send private transactions or transaction bundles to miners through the Flashbots relay. Relay, as the intermediaries, is responsible for verifying and forwarding these transactions and bundles to miners. Upon receiving transactions, miners employ their strategies to construct corresponding blocks, aiming to maximize block construction rewards. After the Merge, Ethereum introduced the concept of Proposer-Builder Separation (PBS) (pbs, 2023), which introduces a more fine-grained way to propose and validate transactions. Specifically, builders are responsible for creating blocks and offering them to the block proposer, who cannot see the contents of the block. They simply choose the most profitable one and pay a fee to the builder before sending the block to its peers. As for Flashbots, they updated their architecture and introduced MEV-Boost, as shown in the bottom part of Fig. 1.

We first illustrate the limitations of existing methods on identifying MEV transactions in a high-level manner. Then, we conduct two case studies to concretely show their limitations.

To improve arbitrage identification and overcome limitations discussed in §4.1, we propose a new algorithm to identify arbitrage transactions, as shown in Algorithm 1. Given a transaction, $tx$, the algorithm first parses all events emitted. If any event conforms to one of the patterns we collected in $swapPatterns$, it extracts the following information, i.e., input token, output token, input amount, and output amount, as a tuple in the $swapList$ (L1 – L6). According to all collected swap events, initGraph at L7 generates the corresponding directed graph, where nodes are tokens and edges refer to swap actions. If no cycles are detected, the algorithm eliminates the possibilities of existence of arbitrage. At L11, as we only consider the arbitrage transaction where traders get profits, the checkProfitable function is responsible for this examination, as shown in Algorithm 2.

Specifically, at L1, getBalChange, identifies the balance change of each type of token for involved addresses by parsing ERC-20 transfer events and transaction traces. Considering that tokens, DApp addresses, and the black hole address may also be included, which are irrelevant to arbitrageurs, rmvIrrAddr excludes these address at L2. For the remaining addresses, we consider them as arbitrageurs if they consist of only one address; otherwise, we identify the ‘From’ and ‘To’ addresses within them as arbitrageurs. We aggregate the token changes on address level at L3. During token exchanges, token with positive amount represents tokens gained by traders as profit, while token with negative amount indicates the lost tokens. The loop at L4 is designed to determine whether the trader can gain profits from the transaction, i.e., determining whether the value of the tokens gained can cover the value of the tokens lost. The loop at L4 iterates tknChange to find a tuple where $tkn_{i}<0$ and $tkn_{k}>0$. The $ratio$ at L5 refers to the proportion of tokens lost relative to the input amount in the swap, where we only focus the one with small $ratio$. This step is designed to avoid excessive use of the conversion between tokens, which could lead to errors in determining whether the transaction is profitable. L7 to L12 is responsible for determining whether the positive change of token $tkn_{k}$ can cover the negative change of token $tkn_{i}$. If it can, $tkn_{i}$ is converted into an equivalent value of token $tkn_{k}$, and their balance changes are adjusted accordingly, which is shown in Algorithm 3. Consequently, if there are no tokens with a negative balance change, the transaction is considered as a profitable arbitrage.

As for Algorithm 3, it is responsible for exchange a specific amount of one token for an equivalent value of another one. At L1, the DFS function obtains all paths from inToken to outToken. The nested loop from L3 to L10 iterates over paths, it converts inToken to outToken based on the exchange rate calculated from the swap. The converted balance of outToken from all paths is collected. The algorithm will return the maximum value of the converted balances.

Previous studies have assumed that there is only one victim transaction in a sandwich attack. In practice, however, there are many advanced sandwich attacks. We refer to the sandwich attack that targets multiple victim transactions within two attack transactions as multi-layered burger attack (Li et al., 2023). Moreover, if a sandwich attack that involves multiple attack transactions like the one shown in the second case in §4.1.2, we term it as a conjoined sandwich attack.

Algorithm  4 outlines the process of identifying sandwich attacks. Given a transaction list, $txs$, the algorithm initially parses all events emitted in every transaction within the same block. From L7 to L12, it identifies all potential pairs of attack transactions. For each potential pair of attack transactions, the algorithm checks if there exists a victim transaction in the middle of them, and if the transactions meet one of the following criteria: 1) an EOA address sends two attack transactions, or 2) two different EOA addresses send attack transactions to the same smart contract. Additionally, the attack transactions must involve swap in an opposite direction, while the swap direction of the first attack transaction matches that of the victim transaction. At L14, the algorithm combines all possible attack transaction pairs, whose aim is to identify potential conjoined sandwich attacks. From L16 to L21, the loop traverses possible combinations of attack transactions to find potentially profitable ones. Since possible combinations of sandwich attacks may share common transactions, like $Tx_{1}$, $Tx_{2}$, $Tx_{3}$ and $Tx_{1}$, $Tx_{2}$, $Tx_{4}$, the algorithm removes both at L23 to prevent false positives. Finally, the algorithm categorizes sandwich attacks based on the number of attack and victim transactions at L24.

To depict their characteristics, we firstly compare the profits among these three types of sandwich attacks, as shown in Fig. 5(a). We find that the median profits of multi-layered burger attacks and normal sandwich attacks are quite similar, while the profits of conjoined sandwich attacks is almost 5 times. This suggests that the conjoined sandwich attack is a more efficient form for MEV searchers.

As both of these two advanced sandwich attacks can hold more than one victim transactions, we then analyze the number of victim transactions, as shown in Fig. 5(b). We can observe that the median number of these two attacks are 2 and 4, respectively. This may be one of the reasons of why conjoined sandwich attack is more profitable, i.e., it increases the number of victim transactions in a single attack, thereby increasing the attacks’ revenue.

Findings: Nearly 9.4 million in-the-wild MEV transactions are identified. Moreover, compared to normal sandwich attack and multi-layerd burger attack, MEV searchers can take advantage of conjoined sandwich attacks to obtain 5x more profits.

Compared to related work (Weintraub et al., 2022; Qin et al., 2022; Wang et al., 2022), our work covers a larger set of candidate DApps and more blocks. To the best of our knowledge, there are two available MEV datasets, i.e., Weintraub (Weintraub et al., 2022) for arbitrages and ZeroMEV (ZER, 2021), a widely used public MEV dataset referenced by studies (Heimbach et al., 2023; Yang et al., 2022; Heimbach et al., 2024) for sandwich attacks. We then compare our identification results with these two datasets²²2For a fair comparison, we only compare the results over the same block range, i.e., from block #10,000,000 to #14,444,725..

To figure out the root causes of such distinctions, we sample hundreds of them to conduct manual investigation. The results for the newly detect 693K arbitrages are shown in Table 2. Three main reasons contribute to the failure of previous methods. Specifically, limited swap patterns refers to the scope of patterns of swap events is limited. Strict token amount comparison and strict chronological examination respectively refer to the two limitations mentioned in the first case study in §4.1.2. Unfortunately, we still cannot identify the reason of 3.6% of newly identified arbitrage. From the break-down statistics, we can observe that the limited swap patterns nearly dominates the reason, more than four-fifth ones are due to this reason. Moreover, we cannot underestimate the impact brought by the two seemingly intuitive rules, around 15% of transactions are mislabeled as negatives by Weintraub.

As for the 141K transactions that are not identified by our method, we summarize two root causes. One is that we do not classify transactions with final token losses as arbitrages but as failed ones, accounting for 38,729 transactions (around 27.3%). Another is that Weintraub’s method labels transactions with swap loops within a DApp as arbitrage, accounting for 11,008 transactions (7.8%). However, upon manual inspection, we found that these transactions do not result in profit for the traders (checked by Algorithm 2). The presence of loops is due to some other reasons, such as selling a portion of tokens as fees to token administrators. We also sample some cases from the remaining 91,980 transactions. We find that they do obtain profits that, however, are transferred to other entities, where some of them are labelled as ‘MEV Bot’ by Etherscan. Because our method mentioned in §4.2 only examines if profits are obtained by the ‘From’ or ‘To’ addresses, leading to false negatives of these cases.

We estimate the false positive (FP) rate and false negative (FN) rate of our method. Since we cannot determine the reasons for the 24,669 newly identified ones in Table 2, we consider all of them as FPs as a upper bound, where the FP rate is around 0.6%. For the FN rate, since 91,980 transactions are not detected by our method, we consider all of them as FNs as a upper bound. Thus, the FN rate of our method is 2.4%.

Similarly, we sample 100 ones from the 70,088 sandwich attacks exclusively marked by ZeroMEV. We find that 57 are non-sandwich attacks, involving various EOA addresses interacting with public contracts, like Uniswap V2 Router, with no evidence indicating that they are sandwich attacks. Moreover, we speculate that 19 of them are likely sandwich attacks, but they are executed through different EOA addresses and contract addresses. Due to the anonymity of blockchain platforms, we cannot determine if there is an entity after them to determine if they are real attacks. Last, the remaining 24 ones all result in token losses for traders, which we take as failed sandwich attacks. We believe these may due to buggy quantitative trading strategies. Thus, our method does not mark them as sandwich attacks.

As for the ones that are exclusive by our method, we sample 100 of them and manually check them. We find that all of them are indeed sandwich attacks. The results underlines the outperformance of our method over the one of ZeroMEV.

We also estimate the FP and FN rate of the sandwich attack detection method. As we sample 100 transactions from the 70,088 sandwich attacks exclusively marked by ZeroMEV, and find 57 that we definitely consider not to be sandwich attacks, we estimate that 43% of these transactions are sandwich attacks. The FN rate is calculated as $\frac{70,088\times 43\%}{1,265,929}$, which is 2.4%. As for FP rate, since we does not find any FPs in our sample results of the detected sandwich attacks that are exclusive by our method, we believe that our method has a quite small FP rate compared to ZeroMEV.

Findings: Compared to existing SOTA methods, our methods outperform both of them in identifying arbitrage and sandwich attacks. Even with the upper-bound estimation, the FP and FN rates for arbitrage is 0.6% and 2.4%, while these two numbers for sandwich attacks are $\sim$0% and 2.4%.

Filtering involved DApps for MEV transactions is beneficial to understand the whole MEV ecosystem. In total, we identify 100,709 DApp addresses involved in arbitrages and sandwich attacks. We manually cluster these addresses with the help of labels from Etherscan and factory addresses of DApps.

Fig. 6 shows the number of swap events emitted from these DApps. Uniswap V2 is the most frequently used DApp, it has emitted 118,573,289 pieces of swap events, accounting for 61.1% of the total. These swap events are related to 81,818 addresses, representing 81.0% of all involved address. It is also the DApp with the most swap actions in MEV transactions, reaching 16,245,431, which accounts for 53.0% of the total occurrences. This indicates that Uniswap V2 is a suitable target to initiate arbitrages and sandwich attacks.

Moreover, as for the swap events incurred by MEV activities, we find that 8.9% of the swap actions originated from arbitrages, and 4.1% and 2.8% are from the attack and victim transactions of sandwich attacks, respectively. Interestingly, we found that 47.0% of the swap actions from Balancer originated from arbitrages, while for Uniswap V2, only 5.2% of the swap actions originated from arbitrages. We speculate the reason behind such a distinction is that compared to Uniswap V2, a Balancer pool can contain multiple tokens, and prices are adjusted based on the weight and quantity of each token in the pool. When the price of one token changes, it affects the prices of multiple tokens, thereby increasing the possibility of creating arbitrage opportunities. As for sandwich attacks, Uniswap V2 has the highest percentage, with 8.5% of the swap actions originating from sandwich attacks (both attack and victim transactions). This could be attributed to its largest volume of both MEV and non-MEV transactions, indicating the highest number of regular traders and MEV searchers. As a result, it presents the most opportunities for sandwich attacks.

Findings: More than 100K DApp addresses are involved into MEV activities, where Uniswap V2, due to its huge transaction volume, gives highest opportunities for initiating MEV activities.

Flashbots is the most popular private relay network available in Ethereum (Messias et al., 2023), we consider the timestamp when it is introduced as an import time node. Specifically, the numbers of different types of transactions are shown in Fig. 7, where the red dotted vertical line indicates the introduction of Flashbots. As we can see, before the emergence of Flashbots, we can observe an obvious rapid growth between block #10,000,000 and #11,000,000, spanning from May 2020 to October 2020, which is attributed to the outburst of the Ethereum DeFi ecosystem. There were 2,488,789 MEV transactions before the emergence of Flashbots. After its introduction, we can observe a sharp decline of mempool transactions, and it is consistently wiggling at a low level. Instead, the private transaction pool immediately dominated a significant portion of the MEV market. We speculate the reason of such a shift is that Flashbots transactions typically occupy the top positions in blocks, making it challenging for mempool MEV transactions to avoid conflicts. Although the number of mempool transactions slightly increased during the upgrade phase of the private transaction architecture, particularly around the PBS update during The Merge, represented by the blue dotted vertical line, the launch of MEV-Boost immediately decreased the number of mempool transactions. Prior to the PBS update, 37.1% of MEV transactions originated from the mempool, while the number went to only 4.7% after The Merge.

Findings: Once after the private transaction architecture has emerged, due to its processing priority over mempool transactions for block builders, MEV activities in private transaction pool started to dominate the whole ecosystem.

We split the timeline into two phases by the introduction of PBS, when the MEV-Boost is also introduced. We quantitatively analyze the profit, profit margin, and revenue of MEV transactions, providing a clear picture of how MEV-Boost impacts the profit distribution in MEV ecosystem.

Fig. 8(a) illustrates the profit of MEV transactions of these two phases. We can easily observe that both before and after the introduction of MEV-Boost, compared to private transactions, mempool transactions can get eight times higher profit. Such a distinction exists even with the low proportion of mempool transactions as shown in Fig. 7. To this end, despite MEV searchers are exposed to the risk of being front-ran, the allure of high profits continues to drive searchers to utilize mempool when extracting MEV.

To obtain a deep understanding, we further evaluate their profit margins, as shown in Fig.  8(b). As we can see, similarly, the profit margin of mempool transactions still exceeds that of private transactions. Before the introduction of MEV-Boost, the median profit margins for mempool and private transaction were 47.1% and 6.7%, respectively, while these two ratios changed to 66.6% and 1.9% after the introduction. The gap between profit margins even widens, which we speculate the reasons are twofold. On one hand, private transaction architectures, such as Flashbots, implement a bidding mechanism where MEV searchers compete by offering high transaction fees, thereby reducing their profit margins. On the other hand, for mempool transactions, since some block proposers might not be connected to private transaction architectures, or their block-building strategies might not prioritize the highest fee MEV transactions, there is still a chance that MEV transactions with lower fees can be proposed. Moreover, such a widening gap indicates that MEV profits further skewed towards block proposers after The Merge, and the private transaction architecture did not democratize the distribution of MEV gains.

Finally, Fig. 8(c) illustrates the revenue of these MEV transactions. Interestingly, we can observe that before The Merge, the median revenue of mempool transactions exceeded the one of private transactions, while things started to go the other way after The Merge. This suggests that after the introduction of MEV-Boost, MEV searchers prefer using private transactions to capture high-revenue opportunities, rather than relying on mempool transactions. However, transaction fees consume a significant portion of their profits, resulting in the decrease of overall profits for private transactions.

Findings: Though the introduction of MEV-Boost incentivizes the adoption of private transaction architecture for MEV activities, the competition on transaction fee significantly lowers the profit, which exacerbates the centralization of profit gaining for block proposers.

After the emergence of private transaction architectures, MEV searchers begin to weigh the options between utilizing the mempool and private transaction architectures. We evaluate this shift based on success rates and profits.

We replay 20,496,511 transactions from 107 contracts that engaged in arbitrage over 10,000 times. Among these, there are 841,937 successful mempool front-running arbitrages, 1,158,966 successful private front-running arbitrages, 675,065 failed mempool front-running arbitrages. We select 37 contracts with over 1,000 mempool transactions for success rate analysis. Given the possibility of private transactions re-entering the mempool due to uncle blocks (unc, 2021) in Proof-of-Work Ethereum, this selection ensures that these contracts engaged in arbitrage using the mempool. As shown in Fig. 9(a), the median success rate of top MEV searchers using mempool for extraction is below 40%. This suggests a high failure rate for mempool transactions, prompting many MEV searchers to switch to private architecture. This shift explains the decline in mempool MEV transactions after the introduction of private architecture, as discussed in §7.1.

As shown in Fig. 9(b), we observe that for 1,104,891 successful private front-running arbitrages, when considering EL, 587,232 (53.1%) ones are no longer profitable. In contrast, out of 779,055 successful mempool ones, only 42,702 (5.5%) ones are no longer profitable. This indicates that for these top MEV searchers, they will consider the success rate and potential loss in MEV extraction when deciding whether to use mempool to acquire MEV. It also highlights that private transaction architecture improves the Ethereum MEV acquisition environment, allowing more MEV opportunities to be captured by MEV searchers. Specifically, without private transaction architecture, smaller-yield MEV opportunities may not be extracted by MEV searchers in time due to the success rate.

Findings: Due to a relative low success rate (¡40%) when conducting MEV through mempool, MEV searchers intend to find opportunities in private transaction architecture. Interestingly, for the ones insist on mempool, they will consider the failed ones as necessary cost when extracting MEV.

To identify back-running arbitrages, we utilize the method mentioned in  §5. Consequently, we identify 1,212,672 back-running arbitrages (including 879,282 private ones and 334,797 mempool ones) and 2,712,357 non-back-running arbitrages after the introduction of Flashbots. Fig. 10 illustrates the number and percentage of revenue. As we can see, although non-back-running arbitrage is still the main form of arbitrage, the revenue generated from back-running has become the dominant source of arbitrage transaction. We speculate there are two possible reasons. First, as private transaction architecture is becoming prevalent in MEV extraction and offers transaction ordering services, e.g., Flashbots bundles, the technical barrier to implement back-running arbitrages has been lowered. Second, the increasing number of MEV searchers leads to a greater competition. The MEV opportunities with high revenue are captured immediately in the same block, i.e., in the form of back-running arbitrage, rather than being left for the next block, which will be captured by non-back-running arbitrages.

Back-running arbitrage requires a target transaction whose position is in the front of it within a block. We observe that for 79.7% cases, there is no other intermediate transaction between them. For these target transactions, Table 3 shows their labels we collect from Etherscan. As we can see, we find that 51.4% of the target transaction contracts are related to Uniswap, while 37.2% are Uniswap V2 Router (uni, 2021). This indicates that public contracts generate a large number of back-running opportunities, which are targeted by MEV searchers in their back-running strategies.

Findings: As the competition among MEV searchers intensifies, back-running arbitrages gradually become a type of MEV activity that cannot be overlooked in both terms of frequency and revenue. Lots of famous public DeFi DApps are considered as targets for such MEV activities.

MEV-Share is a transaction service provided by Flashbots that utilizes back-running techniques to refund a portion of the profits back to the users whose transaction creates MEV opportunities. This service not only enhances the profits of builders, but also ensures better returns for users. Cow Protocol (cow, 2021) also provides a service called MEV-Blocker (mev, 2023a), which also have such a service to refund a part of MEV to the users. We obtain transaction information for MEV-Share and MEV-Blocker from two datasets (Flashbots, 2024; MEV, 2024). In total, we collect 8,422 MEV-Blocker transactions and 589 MEV-Share transactions. We statistically analyze the revenue distribution among different roles. We find that builders receive the largest share of revenue from MEV-Share and MEV-Blocker, accounting for 41.8%. Despite the claim from Flashbots documentation where it enables users to reclaim up to 90% of the MEV generated by their transactions (mev, 2023b), the actual proportion of MEV that users receive is much lower, only around 36.0%.

We also analyze the revenue share of users from MEV-Share and MEV-Blocker in back-running transactions to gain insights into the utilization of these services. Firstly, we extract the contracts used by users in MEV-Share and MEV-Blocker, where 523 contracts are identified. Against them, we identify 98,117 instances of back-running arbitrages, while only 6,109 of them are back-running transactions realted to these two services. Fig. 11 illustrates the obtained revenue. As we can see, there are approximately 4,122.24 ETH extracted by MEV searchers, builders, and validators, while only about 441.76 ETH are captured by searchers in MEV-Share and MEV-Blocker, accounting for a mere 10.7% share. Therefore, we argue that these two services only protect a limited number of traders, highlighting the development potential of these services.

Findings: Only 10.7% of profits obtained by MEV are returned back to users through back-running arbitrages via MEV-Share and MEV-Blocker, reflecting their significant development potential.

After The Merge, the introduction of PBS allowed builders to provide private transaction services through their owned APIs. As builders can arbitrarily reorder these transactions, it provides an opportunity for them to perform MEV. For example, Eigenphi (eigenphi, 2023) has reported a back-running arbitrage conducted by a builder. In this section, we try to filter out if this type of situations happen a lot.

Firstly, we filter out all back-running arbitrages in private transaction pools between Sep. 2022 to Aug. 2023. A total of 54,273 such back-running transactions are identified. For transactions within each block, we consider the block where the over 50% MEV transactions are initiated through a specific MEV searchers. Finally, Table 4 illustrates the filtered three set of searcher-builder tuples, as well as the corresponding revenue. After calculating the profit margins of these three groups of MEV searchers and builders, we find that the median profit margins for these three MEV searchers are 80.6%, 46.1%, and 44.7%, respectively. Compared to the statistics mentioned in §7.2, we can conclude these MEV searchers do not undergo a severe competition, which is most likely due to collusion between MEV searchers and builders. Interestingly, for the example at the second row. Its builder 0x3b6…d67 is named as Boba Builder in Etherscan, and the MEV searcher contract is also named as Boba. However, according to its website (bob, 2023), we have not seen any statement indicating that it engages in back-running arbitrages for private transactions. This actually serves as an example of a builder leveraging the provision of private transaction services to engage in back-running and increase its own profits.

Findings: After The Merge, PBS enables builders to conduct back-running arbitrages quietly by reordering transactions in their corresponding owned private transactions pools. We have observed nearly 620K USD are related to such hidden activities, which require related regulatory work.