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

Tianyang Chi  Beijing University of Posts and TelecommunicationsChina ,
Ningyu He  Peking UniversityChina ,  Xiaohui Hu  Huazhong University of
Science and TechnologyChina and  Haoyu Wang  Huazhong University of Science
and TechnologyChina

(2018)

###### Abstract.

Maximal Extractable Value (MEV) drives the prosperity of the blockchain
ecosystem. By strategically including, excluding, or reordering transactions
within blocks, block producers/validators can extract additional value, which
in turn incentivizes them to keep the decentralization of the whole blockchain
platform. Before The Merge of Ethereum in Sep. 2022, around $675M was
extracted in terms of MEV. Despite its importance, current measurement works
on MEV suffer some limitations. First, current works only focus on
transactions of a very limited number of DApps. Second, current methods
heavily rely on fixed heuristic rule-based patterns, leading to false
negative/positive. Third, the observations and conclusions are outdated to
some extent due to the continuously introduced features, like The Merge in
Ethereum. To address these challenges, in this work, we first propose two
robust methods to identify arbitrage transactions and sandwich attacks,
respectively. Then, we apply them to the largest-ever dataset to filter out
related MEV transactions. Based on the identified results, we have
characterized the overall landscape of the Ethereum MEV ecosystem, the impact
the private transaction architectures bring, and the adoption of back-running
mechanism. Our research will shed light on future MEV-related work.

††copyright: acmlicensed††journalyear: 2018††doi: XXXXXXX.XXXXXXX††journal:
JACM††journalvolume: 37††journalnumber: 4††article: 111††publicationmonth: 8

##  1\. Introduction

Decentralized Finance (DeFi) is a financial system built on Ethereum smart
contracts (Buterin et al., 2013). DeFi is steadily growing on Ethereum. In
Nov. 2021, DeFi has reached a peak in terms of Total Value Locked (TVL), with
over $170 billion (def, 2020). With the rise of DeFi, an increasing number of
traders are participating in DeFi investments. One way to gain profit is
reordering transactions within blocks, which is referred to as Maximal
Extractable Value (MEV) (Daian et al., 2020; Torres et al., 2021; Qin et al.,
2022; Wang et al., 2022; Zhou et al., 2021c; Qin et al., 2021).

Due to the profitability of MEV, numerous addresses, also known as MEV
searchers, are motivated to participate in MEV extraction. Various strategies
are adopted by searchers to extract MEV, e.g., arbitrage (McLaughlin Robert
and Vigna, 2023; Zhou et al., 2021b), liquidation (Qin et al., 2021), and
sandwich attacks (Zhou et al., 2021c; Torres et al., 2021). Additionally,
searchers submit transactions via multiple ways, not only through mempool, a
waiting area for the transactions that have not been added to a block, but
also through private transaction architectures, such as Flashbots (Flashbots,
2021). MEV searchers can directly send transactions to block creators through
private transaction architectures, avoiding other MEV searchers from copying
to compete MEV opportunities (Qin et al., 2023).

Despite the critical role the MEV plays in Ethereum ecosystem, there are a few
works that conduct a comprehensive measurement on MEV ecosystem. Meanwhile,
they all have certain limitations. First, existing works only focus on a few
selected DApps. For example, Wang et al. (Wang et al., 2022) only identified
arbitrages in Uniswap V2 (uni, 2018), while Qin et al. (Qin et al., 2022)
identified arbitrage, sandwich attacks, and liquidations in only 12 DApps.
Second, they mainly adopt heuristic rule-based methods for detecting arbitrage
and sandwich transactions, leading to lots of false positives and false
negatives according to our investigation. For example, we observe a variant of
sandwich attack that involves more than two attack transactions, which cannot
be detected by Qin’s method (Qin et al., 2022). Third, their observations and
conclusions are outdated due to the continuous introduction of new features.
One of the biggest changes in Ethereum is The Merge, where the consensus
algorithm is transitioned from Proof of Work (PoW) to Proof of Stake (PoS). At
this milestone, Proposer-Builder Separation (PBS) is introduced, which brings
in new private transaction architectures. However, only some basic statistical
works are conducted, like Heimbach et al. (Heimbach et al., 2023) analyzed the
number of different types of MEV transactions in (non-)PBS blocks.

To address these challenges, this paper aims to perform a comprehensive
measurement study on Ethereum MEV ecosystem in the new era. We firstly, to the
best of our knowledge, collect the largest ever dataset, consisting of
Ethereum transactions, private transactions, and proposed PBS blocks. Then, we
propose two new sets of algorithms to identify arbitrages and sandwich attacks
in a robust way. Last, based on our collected results, we have answered the
following research questions.

RQ1: How is the overall landscape of the Ethereum MEV ecosystem? To answer
this question, we focused on the number of MEV transactions (arbitrages and
sandwich attacks) that can be identified by our algorithms. Moreover, we
compared the identified results with the corresponding SOTA methods to
quantitatively prove the robustness and effectiveness of our method. Last, we
also counted the participation levels of different DApps. By answering these
questions can draw a big picture of the Ethereum MEV ecosystem.

RQ2: What is the impact of private transaction architectures? To answer this
question, we pay special attention to two critical timestamps, i.e.,
introduction of Flashbots and PBS. When splitting the whole timeline into
three intervals, we focused on several key metrics on each of them, including
the MEV transaction volumes, MEV transactions profit/profit margins/revenues,
and MEV performing strategies. Answering these questions can quantitatively
tell the community what positive and negative impacts are resulted in by
introducing new features.

RQ3: Is performing back-running a silver bullet for MEV searchers? Due to the
introduction of PBS, performing back-running instead of front-running within
the same block to the target transaction to extract MEV is possible. According
to McLaughlin (McLaughlin Robert and Vigna, 2023), it gradually becomes the
primary profit mechanism for arbitrages. In this RQ, we evaluated how many
back-running transactions are performed. Then, we focused on two mechanisms
that adopt back-running, i.e., MEV-Share/MEV-Block, and builder MEV
extraction, to inspect this question from different perspectives.

We have conducted the following contributions:

  * •

We propose two new robust algorithms against arbitrage and sandwich attacks.
Against current SOTA methods, our method can detect 16.44% and 1.19% more
arbitrage and sandwich attacks, respectively, with very low false
positive/negative rates.

  * •

Nearly 9.4 million in-the-wild MEV transactions are identified, and more than
100K DApp addresses are involved, where Uniswap V2, Uniswap V3, and Sushiswap
are the top-3 involved DApps.

  * •

The emergence of private transaction architecture does not bring in
significant impacts on MEV transaction volume. However, because a relative low
success rate (¡40%) when conducting MEV through mempool, MEV searchers began
to exploit this architecture on a large scale to extract MEV, which resulted
in intense competition, reflected in a significant drop in both profit and
profit margin.

  * •

Back-running arbitrages gradually become a type of MEV activity that cannot be
overlooked in both terms of frequency and especially revenue. The statistics
on the adoption of MEV-Share and MEV-Blocker indicate back-running is far from
fully utilized yet, while 620K USD are obtained by quietly and maliciously
exploiting back-running mechanisms in builders.

Our dataset will be released to the research community for further study.

##  2\. Background

###  2.1. Ethereum & Smart Contract

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).

###  2.2. Decentralized Finance

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.

###  2.3. Maximal Extractable Value Extraction

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.

Front-running & Back-running. Reordering transactions is a key tactic in MEV
extraction and its two main strategies are front-running and back-running. The
primary distinction between these two lies in the relative position between
MEV searcher transactions and the target transaction. Front-running occurs
before the target transaction, while back-running occurs after the target
transaction. Intuitively, front-running influences the execution of the target
transaction, while back-running does not.

Common Types of MEV. It is widely recognized that MEV transactions includes
two common types: arbitrage, sandwich attack, as discussed in previous
research (Qin et al., 2022; Weintraub et al., 2022; Wang et al., 2022; Qin et
al., 2021; Zhou et al., 2021c). Specifically, arbitrage refers to that MEV
searchers exploit price differences between DApps to achieve profits. We focus
on cyclic arbitrage, where a loop is formed through currency exchanges, and
the profit from the price difference in transactions is mostly converted into
the same token.

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.

Flashbots. Flashbots (Flashbots, 2021), which utilizes a private transaction
pool, is an organization aiming to democratize MEV extraction. The
architectures of Flashbots before and after The Merge are shown in Figure 1.

Figure 1. The architecture of Flashbots before (upper part) and after (bottom
part, also known as MEV-Boost) The Merge.

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.

##  3\. Data Overview

To gain a comprehensive investigation of MEV activities, we need various types
of data, including Ethereum transactions, private transactions, mempool
transactions, and PBS block. Therefore, we select different data sources to
collect them, as shown in Table 1.

Firstly, we use the most well-known Ethereum client node, Geth, to sync
transactions, traces, and logs. In total, we have collected over 2 billion
Ethereum transactions (from block #0 to #18,000,000), as well as all metadata,
including logs, traces, transaction data (like gas used and gas price) and
block data (like block number and base fee).

Then, to distinguish private transactions from normal mempool transactions, we
firstly query the Blocknative database (blo, 2023), a public dataset which
maintains the time interval between a transaction is listened and recorded on
the blockchain. We consider transactions with a 0 interval as private
transactions. Moreover, because Blocknative does not cover all private
transactions, we also query the Flashbots API (fla, 2021), a public data
source that records private transaction bundles passed through the Flashbots
relays. We merge the obtained private transactions from both datasets, and
obtain a total of 36,180,823 private transactions.

Last, to obtain all PBS blocks, we utilize the Relay API (Eth-Educators,
2022), a data source provided by each relay that can query the block numbers
they propose. To the best of our knowledge, only 11 relays have disclosed the
PBS blocks they propose. Consequently, we collect a total of 2,087,069 PBS
blocks with their relay APIs, respectively.

Table 1. Overview of Datasets

Source | Data Type | Time Span | Number
---|---|---|---
Geth | Transaction | 2015.07-2023.08 | 2,074,998,853
Logs | 3,108,423,890
Traces | 5,582,166,611
Block | 18,000,000
Blocknative API | Private Transaction | 2021.01-2023.08 | 36,180,823
Flahbots API | 2021.02-2022.09
Relay API | Proposed PBS block | 2022.09-2023.08 | 2,087,069

##  4\. Methodologies

Our study focuses on two types of MEV transactions, i.e., arbitrage and
sandwich attacks. While previous works (Wang et al., 2022; Torres et al.,
2021; Qin et al., 2022) perform heuristic methods to identify them, through
our investigation on real-world cases, both false positives and false
negatives exist. We firstly illustrate the limitations of previous heuristic
methods with case studies in §4.1, then we propose an updated set of rules to
identify these MEV transactions in §4.2 and §4.3.

###  4.1. Limitations of Existing Methods

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.

####  4.1.1. Limitations

According to our comprehensive investigation on existing heuristic methods
(Wang et al., 2022; Torres et al., 2021; Qin et al., 2022), we have summarized
two main limitations on detecting arbitrages and sandwich attacks.

L1: Existence of unconventional swap events. Swap event is a kind of
conventional log that will be emitted when two different types of tokens are
exchanged between two entities. However, Ethereum does not require the format
of swap events. Overdependence on the so-called standard or conventional swap
events may generate imprecise results on identifying MEV transactions, which
has been observed previously (Li et al., 2023).

L2: Inflexible rule-based pattern matching. As the landscape of arbitrage and
sandwich attack evolves, traditional identification methods that heavily rely
on inflexible rule-based pattern matching become less effective. For example,
in an arbitrage, each swap within the transaction may not necessarily be
executed in a chronological order, leading to false negatives in previous
detection methods. Another example is that if a transaction contains a loop
where the output amount of a swap for the same token is greater than the input
amount of the subsequent swap, it may be detected as an arbitrage, leading to
false positives.

####  4.1.2. Case Studies

Figure 2. An arbitrage that violates heuristics of previous identification
method.

We provide two real-world examples to concretely explain the limitations of
existing methods.

Case I: Arbitrage. Intuitively, to perform an arbitrage, the swap should be
conducted in a sequential order, where the amount of tokens in the output of
the preceding swap should be no less than the one of input of the following
swap. Current heuristic methods embed these two observations to identify MEV
arbitrage. However, we observe that in some real-world cases, these two
intuitive rules can be violated, as illustrated in Fig. 2111Transaction: link.
On the one hand, due to Flash Swap, a feature provided by DEXs that allow
users to borrow and return tokens within the same transaction, these four
swaps do not form a circle in chronological order. On the other hand, we can
observe the input of swap#2 is slightly greater than the output of swap#1.
However, compared to the final profit, this extra cost can be ignored. This
example violates both intuitive heuristic but is still a successful MEV
arbitrage that cannot be identified by previous methods.

Figure 3. An sandwich attack that violates heuristics of previous
identification method.

Case II: Sandwich Attack. To perform a successful sandwich attack, the most
intuitive way is sandwiching a victim transaction by two attack transactions
for swapping token A for B. Specifically, the first attack transaction and the
victim one swap token A for B, while the second attack one swaps it back.
Moreover, the input amount of token B in the second attack transaction equals
to the output amount of the one in the first attack transaction, formally
denoted as $Tx_{\\#2attack}[B_{in}]=Tx_{\\#1attack}[B_{out}]$. Current methods
rely on such pattern-based matching processes. However, we have discovered a
more complex form of sandwich attack, consisting of more than two attack
transactions, as illustrated in Fig. 3. As we can see, there are three attack
transactions and three victim transactions. Moreover,
$Tx_{\\#2attack}[WETH_{in}]\neq Tx_{\\#1attack}[WETH_{out}]$ and
$Tx_{\\#3attack}[SILKROAD_{in}]\neq Tx_{\\#2attack}[SILKROAD_{out}]$. This
example violates both intuitive heuristics and cannot be identified by
previous methods, but is still a successful sandwich attack because the
attacker finally gets additional SILKROAD and WETH tokens as profits.

###  4.2. Arbitrage Identification Method

Algorithm 1 Identify Arbitrages

1:tx \- candidate transaction; swapPatterns \- collected swap events patterns.

2:arbitrageFlag \- a flag to indicate if current transaction is an arbitrage.

3:$swapList\leftarrow[]$

4:for $\textit{event}_{i}$ in tx.events do

5: if $\textit{event}_{i}\in swapPatterns$ then

6: $swapList.\text{append}(\text{swapParse}(\textit{event}_{i}))$

7: end if

8:end for

9:$g\leftarrow\text{initGraph}(swapList)$

10:if not $\text{existsCycle}(g)$ then

11: return false

12:end if

13:return checkProfitable(tx, g)

Algorithm 2 Check Profitable

1:tx \- a transaction or transactions; $g$ \- a directed graph where nodes
represent tokens and edges represent swaps.

2:flag \- a flag to indicate if a transaction or transactions is profitable
for trader.

3:$\textit{addrBalChange}\leftarrow\text{getBalChange}(\textit{tx})$

4:$\textit{addrBalChange}\leftarrow\text{rmvIrrAddr}(\textit{addrBalChange})$

5:$\textit{tknChange}\leftarrow\text{aggrTknChange}(\textit{addrBalChange})$

6:for $(\textit{tkn}_{i},\textit{tkn}_{k})$ in
$\\{(\textit{tkn}_{i},\textit{tkn}_{k})\mid\textit{tkn}_{i},\textit{tkn}_{k}\in\textit{tknChange}$
$\land$ $tknChange.\textit{tkn}_{i}<0$ $\land$
$\textit{tknChange}.\textit{tkn}_{k}>0$ } do

7:
$ratio\leftarrow(\textit{tkn}_{k}.out-\textit{tkn}_{k}.in)/\textit{tkn}_{k}.in$

8: if $ratio<\epsilon$ then

9: $exInput\leftarrow-\textit{tknChange}.\textit{tkn}_{i}$

10:
$exAmt\leftarrow\text{exchangeToken}(\textit{tkn}_{i},\textit{tkn}_{k},g,exInput)$

11: if $\textit{tknChange}.\textit{tkn}_{k}-\textit{exAmt}>0$ then

12:
$\textit{tknChange}.\textit{tkn}_{k}\leftarrow\textit{tknChange}.\textit{tkn}_{k}-\textit{exAmt}$

13: $\textit{tknChange}.\textit{tkn}_{i}\leftarrow 0$

14: break

15: end if

16: end if

17:end for

18:if $\forall\text{tkn}_{i}\in\text{tknChange}(\text{tkn}_{i}\geq 0)$ then

19: return true

20:else

21: return false

22:end if

Algorithm 3 Exchange Token

1:inToken \- exchanged token; outToken \- output token; exInput \- exchange
amount; $g$ \- a directed graph where nodes represent tokens and edges
represent swaps.

2:exOutput \- output amount.

3:$routeList\leftarrow\textit{DFS}(\textit{inToken},\textit{outToken},g)$

4:$\textit{exOutList}\leftarrow[]$

5:for $route_{i}$ in routeList do

6: $exOutput\leftarrow\textit{exInput}$

7: for $\textit{swap}_{i}$ in $\textit{route}_{i}$ do

8:
$ratio\leftarrow\textit{swap}_{i}.\textit{outputAmt}/\textit{swap}_{i}.\textit{inputAmt}$

9: $\textit{exOutput}\leftarrow\textit{exOutput}*ratio$

10: end for

11: $\textit{exOutList}.\textit{append}(\textit{exOutput})$

12:end for

13:return max(exOutList)

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.

###  4.3. Sandwich Identification Method

Algorithm 4 Identify Sandwich Attacks

1:txs \- candidate transactions in one block;swapPatterns \- collected swap
events patterns.

2:sandwichAttacks \- a list of sandwich attacks.

3:initSwapList($txs$)

4:for $(\textit{tx}_{i},\textit{event}_{k})$ in
$\\{(\textit{tx}_{i},\textit{event}_{k})\mid\textit{tx}_{i}\in\textit{txs},$

5: $\textit{event}_{k}\in\textit{tx}_{i}.events,\textit{event}_{k}\in
swapPatterns\\}$ do

6:
$\textit{tx}_{i}.swapList.\text{append}(\text{swapParse}(\textit{event}_{k}))$

7:end for

8:$attackList\leftarrow[]$

9:for $\textit{tx}_{i},\textit{tx}_{v},\textit{tx}_{k}$ in txs do

10: if
$\textit{index}(\textit{tx}_{i})<\textit{index}(\textit{tx}_{v})<\textit{index}(\textit{tx}_{k})$
$\land$

11:$(\textit{tx}_{i}.\textit{from}=\textit{tx}_{k}.\textit{from}\vee\textit{tx}_{i}.\textit{to}=\textit{tx}_{k}.\textit{to})$
$\land$

12:$(checkSwap(\textit{tx}_{i},\textit{tx}_{v},\textit{tx}_{k}))$ then

13: $\textit{attackList}.\textit{append}((\textit{tx}_{i},\textit{tx}_{k}))$

14: end if

15:end for

16:$\textit{possibleAttack}\leftarrow\text{combineAttacks}(\textit{attackList})$

17:$\textit{profitableAttack}\leftarrow[]$

18:for attack in possibleAttack do

19: $swaps\leftarrow\text{concatenate}([tx.swapList\text{ for }tx\in attack])$

20: $g\leftarrow\text{initGraph}(allSwaps)$

21: if $\text{checkProfitable}(\textit{attack},g)$ then

22: $\textit{profitableAttack}.append(\textit{attack})$

23: end if

24:end for

25:$attacks\leftarrow\text{filtAttack}(profitableAttack)$

26:$\text{classifyAttacks}(attacks)$

27:return $attacks$

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.

##  5\. Study Design

##### Research Questions

Compared to existing work, our work proposes a more effective algorithm to
identify three types of MEV transactions. To comprehensively evaluate MEV
transactions in the ecosystem, we raise the following research questions
(RQs).

  * RQ1

How many MEV transactions exist? What about the whole picture of MEV
activities?

  * RQ2

What impacts are imported through introducing private transaction architecture
to the MEV ecosystem?

  * RQ3

Back-running arbitrage, as a newly emerged MEV activity, what characteristics
does it own?

##### Experimental Setting

To answer RQ1, we focus on the transactions interacted with a set of DeFi
DApps. Considering the representativeness, according to Defilama (def, 2020),
we finally take the only 44 DeFi DApps with TVL, a metric to reflect the
prosperity, as candidates. Moreover, we extract their swap events as the
pattern set, i.e., $swapPatterns$ in Algorithm 1. To answer RQ2 and RQ3, we
need to identify front-running and back-running arbitrages, respectively.
Thus, we directly utilize the replay strategy proposed by McLaughlin
(McLaughlin Robert and Vigna, 2023). We get transaction traces and event logs
replayed at any position within its block by forking the code of Ganache (gan,
2022). To identify the target transaction of a back-running arbitrage, we
iteratively move the back-running arbitrage transaction forward till it
changes to a non-arbitrage. The just behind transaction is the target one.

##  6\. RQ1: Status of MEV Activities

In this section, we present the detection results of arbitrage and sandwich
attacks in-the-wild.

Figure 4. Identified arbitrage and sandwich attack.

###  6.1. Identified MEV Activities

Overview. As shown in Fig. 4, we have successfully identified nearly 9.4
million pieces of MEV transactions, including 6,331,851 arbitrages and
3,016,971 sandwich attacks. Interestingly, we found there exists an
intersection between these two sets, consisted of 148,133 transactions. After
investigating their characteristics, we concluded that they are toxic
arbitrages, a special kind of MEV transaction (Zero MEV, 2022). It can be
regarded as a sandwich attack where the second attack is also a profitable
arbitrage. Its profits come from the manipulation of prices in the DApp in the
first attack transaction and the losses of the victim transaction.

Advanced Sandwich Attack. As we mentioned in §4.3, our algorithm also focuses
on some advanced types of sandwich attacks. In total, there are 395,779
(13.1%) multi-layered burger attacks and 31,878 (1.1%) conjoined sandwich
attacks.

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.

Figure 5. Profits and transaction count for different types of sandwich
attacks.

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.

###  6.2. Comparison with Existing Methods

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 datasets222For a fair
comparison, we only compare the results over the same block range, i.e., from
block #10,000,000 to #14,444,725..

Arbitrages Comparison. Within the given range, our method can identify a total
of 3,910,444 arbitrages, whereas Weintraub can identify 3,358,371 ones333Both
of them exclude the toxic arbitrage.. Specifically, around 95.78% of
transactions are detected by both methods, while 141,717 transactions are only
detected by Weintraub (accounting for 4.22% of its dataset) and 693,790
transactions are only detected by our method (accounting for 17.74% of our
results).

Table 2. Reasons of exclusively identified arbitrages in our method compared to Weintraub. Reasons | Count | %
---|---|---
Limited swap patterns | 566,076 | 81.6%
Strict token amount comparison | 76,506 | 11.0%
Strict chronological examination | 26,539 | 3.8%
Other | 24,669 | 3.6%
Total | 693,790 | 100%

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%.

Sandwich Attack Comparison. Within the given block range, our method detects a
total of 1,265,929 sandwich attacks, whereas there are 1,251,072 ones for
ZeroMEV. Among them, 84,944 and 70,088 sandwich attacks are exclusively marked
by our method and the ZeroMEV’s, respectively.

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%.

###  6.3. DApps Composition

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.

Figure 6. Distribution of swap events involved in different types of
transactions.

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.

##  7\. RQ2: Impact of Private Transaction Architecture

In this section, we discuss the impact brought in by the emergence of private
transaction architecture, i.e., Flashbots and MEV-Boost, on MEV extraction.

###  7.1. Impact on MEV Transaction Volume

Figure 7. The number of MEV transactions.

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.

###  7.2. Impact on MEV Transaction Profit

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.

Figure 8. Profit, profit margin, and revenue of MEV transactions before and
after the introduction of MEV-Boost.

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.

###  7.3. Impact on MEV Strategies

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.

Success Rate. Because Flashbots verifies the success of transactions, MEV
searchers can avoid financial losses in terms of transaction fees. Instead,
for mempool transactions, failed transactions still require fees as they are
executed regardless of success. We focus on front-running arbitrages to
evaluate the success rate, whose reasons are twofold: 1) arbitrage represents
the most prevalent form of MEV transactions, and 2) failed sandwich
transactions cannot be reliably detected due to the existence of multiple
transactions in a single one attack. We use the method mentioned in §5

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.

Figure 9. Distribution of success rates (in mempool) and expected profits for
MEV searchers.

Expected Profit. Due to the potential losses incurred from failed mempool
transactions, we introduce the concept of Expected Loss (EL) to evaluate the
potential losses for each transaction, which is calculated as follows:

$EL=gp\times fg\times(1-sr)$

, where $gp$ represents the gas price, $fg$ denotes the average gas of failed
front-running arbitrages, and $sr$ is the success rate of mempool
transactions. We calculate EL for all 47 contracts that conduct failed mempool
transactions. For the other 60 contracts that execute arbitrages only through
private transactions, we consider the average EL of the 47 contracts as the EL
for these 60 contracts to evaluate what if they are executed through mempool.
Expected profit is calculated by subtracting EL from the profit for all
successful front-running arbitrages. Under this scenario, if the expected
profit becomes negative, that one is no longer profitable.

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.

##  8\. RQ3: Application of Back-running

Intuitively, front-running can modify the state before the victim transaction
is performed. However, according to McLaughlin (McLaughlin Robert and Vigna,
2023), back-running has gradually become the primary profit mechanism for
arbitrages. In this section, we delve deeper into the characteristics of back-
running, aiming to understand the characteristics and application of back-
running arbitrages.

###  8.1. Overall Results

Figure 10. The frequency and revenue of back-running arbitrages and other
types of arbitrages after the introduction of Flashbots.

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.

Table 3. Labels of target transaction contracts. Label | # Transaction | Proportion (%)
---|---|---
Uniswap | 942,395 | 56.75
MEV-Bot | 181,374 | 10.91
SushiSwap | 105,521 | 6.35
1inch | 104,053 | 6.26
0x Protocol | 37,942 | 2.28
Other | 460,433 | 27.74

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.

###  8.2. MEV-Share and MEV-Blocker

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%.

Figure 11. MEV searchers obtained revenue through back-running arbitrage.
Table 4. Participation of builders in back-running arbitrages after PBS.

Builder Address | MEV Searcher Contract Address | Number of Transactions | Revenue (ETH)
---|---|---|---
0x3bee5122e2a2fbe11287aafb0cb918e22abb5436 | 0x9dd864d39fbfdf7648402746263e451cd4f36af0 | 590 | 81.0
0x3b64216ad1a58f61538b4fa1b27327675ab7ed67 | 0xb0bababe78a9be0810fadf99dd2ed31ed12568be | 381 | 40.5
0x229b8325bb9ac04602898b7e8989998710235d5f | 0x6c6b87d44d239b3750bf9badce26a9a0a3d2364e | 141 | 85.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.

###  8.3. Builder MEV Extraction

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.

##  9\. Related Work

Our work is related to three following three categories.

MEV identification. Most research (Qin et al., 2022; Wang et al., 2022;
Weintraub et al., 2022; Piet et al., 2022; Torres et al., 2021) are based on
heuristic methods and are only identified for a few popular DApps. The
advantage of them is their simplicity, but the drawback is the limitation on
specific types of transactions. Our work improves upon this heuristic method
by expanding the range of DApps searched and refining the rules, enabling the
identification of more subtypes of transactions. Mclaughlin et al. (McLaughlin
Robert and Vigna, 2023) utilizes the heuristic method proposed by Wu et al.
(Wu et al., 2021), relying solely on ERC-20 transfer events to identify DEX
addresses and detect arbitrage transactions, thereby expanding the scope of
DApps searched. Recent work by Li et al. (Li et al., 2023) utilizes
transaction aggregation, detecting MEV transactions on a Flashbot bundle
basis, which can uncover more types of MEV transactions.

Private transaction architecture. Before the PBS update, some researches
(Weintraub et al., 2022; Capponi et al., 2022; Piet et al., 2022; Lyu et al.,
2022) focus on the relationship between private transaction architecture and
MEV. After the PBS update, other studies (Wahrstätter et al., 2023; Heimbach
et al., 2023) delve into the characteristics of the PBS update and its impact
on MEV. Wahrstätter et al. (Wahrstätter et al., 2023) investigated the impact
of the time taken by builders to submit blocks on their block construction
profits, analyzing whether the builder strategy involves waiting to accept
more MEV transactions or submitting blocks in advance. Our research focuses on
the impact of private transaction architectures on the profits and strategies
of MEV searchers.

MEV applications. Due to the potential losses incurred by traders due to MEV,
some applications have been designed to mitigate MEV. Some solutions aim to
prevent losses caused by front-running through the design of DEX (Zhou et al.,
2021a; Ciampi et al., 2022; McMenamin et al., 2022; Baum et al., 2021; cow,
2021). Other solutions involve redesigning the order of transactions (Khalil
et al., 2019; Bentov et al., 2019; Malkhi and Szalachowski, 2022). In our
study, although back-running transactions do not directly impact traders’
profits, the majority of traders do not profit from the MEV generated by them.
Despite MEV-Share and MEV-Blocker being an effective solution, they have not
been widely adopted, indicating that the MEV problem introduced by Ethereum
has not been adequately addressed and remains a challenge in terms of fair
distribution of profits.

##  10\. Conclusions

In this work, we have proposed two new sets of algorithms to identify
arbitrages and sandwich attacks in MEV ecosystem. Compared to SOTA methods,
our methods are more robust in identifying variants of the corresponding MEV
activities with lower false positive/negative rate, at most 2.4%. To the best
of our knowledge, based on the largest-ever dataset, we have answered three
interesting questions. Results illustrate the prosperity of current MEV
ecosystem, the potential centralization trend brought by the introduction of
private transaction architecture, and the unhealthy adoption of back-running
arbitrages.

## References

  * (1)
  * uni (2018) 2018\.  Uniswap.  https://uniswap.org/.
  * aav (2019) 2019\.  Aave V1.  https://app-v1.aave.com/.
  * dap (2020) 2020\.  Decentralized applications(dapps).  https://ethereum.org/en/dapps/.
  * def (2020) 2020\.  DefiLlama.  https://defillama.com/.
  * yea (2020) 2020\.  Yearn Finance.  https://yearn.finance/.
  * aav (2021) 2021\.  Aave V2.  https://github.com/aave/protocol-v2.
  * cow (2021) 2021\.  CoW Protocol Overview.  https://docs.cow.fi/.
  * fla (2021) 2021\.  Flashbots API.  https://blocks.flashbots.net/.
  * unc (2021) 2021\.  Uncle Bandit Risk.  https://docs.edennetwork.io/eden-rpc/more-information/uncle-bandits/.
  * uni (2021) 2021\.  Uniswap V2 Router.  https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02.
  * ZER (2021) 2021\.  Zero MEV Datasets.  https://zeromev.org/.
  * gan (2022) 2022\.  Ganache: A tool for creating a local blockchain for fast Ethereum development.  https://github.com/trufflesuite/ganache.
  * aav (2023) 2023\.  Aave V3.  https://docs.aave.com/.
  * blo (2023) 2023\.  Blocknative Mempool Data Program.  https://docs.blocknative.com/mempool-data-program.
  * bob (2023) 2023\.  Boba Builder Docs.  http://boba-builder.com/.
  * mev (2023a) 2023a.  MEV-Blocker.  https://mevblocker.io/.
  * mev (2023b) 2023b.  MEV-Share Docs.  https://docs.flashbots.net/flashbots-protect/mev-share.
  * pbs (2023) 2023\.  Proposer-builder separation.  https://ethereum.org/nl/roadmap/pbs.
  * syn (2023) 2023\.  Synapse Bridge.  https://docs.synapseprotocol.com.
  * MEV (2024) 2024\.  MEV-Blocker Data.  https://dune.com/cowprotocol/mev-blocker.
  * Baum et al. (2021) Carsten Baum, Bernardo David, and Tore Kasper Frederiksen. 2021.  P2DEX: privacy-preserving decentralized cryptocurrency exchange. In _International Conference on Applied Cryptography and Network Security_. Springer, 163–194.
  * Bentov et al. (2019) Iddo Bentov, Yan Ji, Fan Zhang, Lorenz Breidenbach, Philip Daian, and Ari Juels. 2019.  Tesseract: Real-time cryptocurrency exchange using trusted hardware. In _Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security_. 1521–1538.
  * Buterin et al. (2013) Vitalik Buterin et al. 2013\.  Ethereum white paper.  _GitHub repository_ 1 (2013), 22–23.
  * Capponi et al. (2022) Agostino Capponi, Ruizhe Jia, and Ye Wang. 2022.  The evolution of blockchain: from lit to dark.  _arXiv preprint arXiv:2202.05779_ (2022).
  * Ciampi et al. (2022) Michele Ciampi, Muhammad Ishaq, Malik Magdon-Ismail, Rafail Ostrovsky, and Vassilis Zikas. 2022.  Fairmm: A fast and frontrunning-resistant crypto market-maker. In _International Symposium on Cyber Security, Cryptology, and Machine Learning_. Springer, 428–446.
  * Daian et al. (2020) Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. 2020.  Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability. In _2020 IEEE Symposium on Security and Privacy (SP)_. IEEE, 910–927.
  * eigenphi (2023) eigenphi. 2023.  Transaction Observability: Forget Top-of-Block Biddings; Back-of-Block MEVs On Private Order Flow are Moving Validators’ Cheese.  https://eigenphi.substack.com/p/transaction-observability.
  * Eth-Educators (2022) Eth-Educators. 2022.  MEV Relay List.  https://github.com/eth-educators/ethstaker-guides.
  * Flashbots (2021) Flashbots. 2021.  Flashbots: A private transaction architecture.  https://docs.flashbots.net/flashbots-auction/overview.
  * Flashbots (2024) Flashbots. 2024.  MEV-Share Data.  https://flashbots-data.s3.us-east-2.amazonaws.com/index.html.
  * Foundation (2023) Ethereum Foundation. 2023.  The Merge.  https://ethereum.org/en/roadmap/merge/.
  * Heimbach et al. (2023) Lioba Heimbach, Lucianna Kiffer, Christof Ferreira Torres, and Roger Wattenhofer. 2023.  Ethereum’s Proposer-Builder Separation: Promises and Realities. In _Proceedings of the 2023 ACM on Internet Measurement Conference_. 406–420.
  * Heimbach et al. (2024) Lioba Heimbach, Vabuk Pahari, and Eric Schertenleib. 2024.  Non-Atomic Arbitrage in Decentralized Finance.  _arXiv preprint arXiv:2401.01622_ (2024).
  * Khalil et al. (2019) Rami Khalil, Arthur Gervais, and Guillaume Felley. 2019.  Tex-a securely scalable trustless exchange.  _Cryptology ePrint Archive_ (2019).
  * Lehar and Parlour (2021) Alfred Lehar and Christine A Parlour. 2021.  Decentralized exchanges.  _Available at SSRN 3905316_ (2021).
  * Li et al. (2023) Zihao Li, Jianfeng Li, Zheyuan He, Xiapu Luo, Ting Wang, Xiaoze Ni, Wenwu Yang, Xi Chen, and Ting Chen. 2023.  Demystifying DeFi MEV Activities in Flashbots Bundle. In _Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security_. 165–179.
  * Lyu et al. (2022) Xingyu Lyu, Mengya Zhang, Xiaokuan Zhang, Jianyu Niu, Yinqian Zhang, and Zhiqiang Lin. 2022.  An Empirical Study on Ethereum Private Transactions and the Security Implications.  _arXiv preprint arXiv:2208.02858_ (2022).
  * Malkhi and Szalachowski (2022) Dahlia Malkhi and Pawel Szalachowski. 2022.  Maximal extractable value (mev) protection on a dag.  _arXiv preprint arXiv:2208.00940_ (2022).
  * McLaughlin Robert and Vigna (2023) Kruegel Christopher McLaughlin Robert and Giovanni Vigna. 2023.  A large scale study of the ethereum arbitrage ecosystem. In _32nd USENIX Security Symposium (USENIX Security 23)_. 3295–3312.
  * McMenamin et al. (2022) Conor McMenamin, Vanesa Daza, Matthias Fitzi, and Padraic O’Donoghue. 2022.  Fairtradex: A decentralised exchange preventing value extraction. In _Proceedings of the 2022 ACM CCS Workshop on Decentralized Finance and Security_. 39–46.
  * Messias et al. (2023) Johnnatan Messias, Vabuk Pahari, Balakrishnan Chandrasekaran, Krishna P Gummadi, and Patrick Loiseau. 2023.  Dissecting Bitcoin and Ethereum Transactions: On the Lack of Transaction Contention and Prioritization Transparency in Blockchains.  _arXiv preprint arXiv:2302.06962_ (2023).
  * Piet et al. (2022) Julien Piet, Jaiden Fairoze, and Nicholas Weaver. 2022.  Extracting godl [sic] from the salt mines: Ethereum miners extracting value.  _arXiv preprint arXiv:2203.15930_ (2022).
  * Qin et al. (2023) Kaihua Qin, Stefanos Chaliasos, Liyi Zhou, Benjamin Livshits, Dawn Song, and Arthur Gervais. 2023.  The blockchain imitation game.  _arXiv preprint arXiv:2303.17877_ (2023).
  * Qin et al. (2021) Kaihua Qin, Liyi Zhou, Pablo Gamito, Philipp Jovanovic, and Arthur Gervais. 2021.  An empirical study of defi liquidations: Incentives, risks, and instabilities. In _Proceedings of the 21st ACM Internet Measurement Conference_. 336–350.
  * Qin et al. (2022) Kaihua Qin, Liyi Zhou, and Arthur Gervais. 2022.  Quantifying blockchain extractable value: How dark is the forest?. In _2022 IEEE Symposium on Security and Privacy (SP)_. IEEE, 198–214.
  * Torres et al. (2021) Christof Ferreira Torres, Ramiro Camino, et al. 2021\.  Frontrunner jones and the raiders of the dark forest: An empirical study of frontrunning on the ethereum blockchain. In _30th USENIX Security Symposium (USENIX Security 21)_. 1343–1359.
  * Wahrstätter et al. (2023) Anton Wahrstätter, Liyi Zhou, Kaihua Qin, Davor Svetinovic, and Arthur Gervais. 2023.  Time to Bribe: Measuring Block Construction Market.  _arXiv preprint arXiv:2305.16468_ (2023).
  * Wang et al. (2022) Ye Wang, Yan Chen, Haotian Wu, Liyi Zhou, Shuiguang Deng, and Roger Wattenhofer. 2022.  Cyclic arbitrage in decentralized exchanges. In _Companion Proceedings of the Web Conference 2022_. 12–19.
  * Weintraub et al. (2022) Ben Weintraub, Christof Ferreira Torres, Cristina Nita-Rotaru, and Radu State. 2022.  A flash (bot) in the pan: measuring maximal extractable value in private pools. In _Proceedings of the 22nd ACM Internet Measurement Conference_. 458–471.
  * Wu et al. (2021) Siwei Wu, Dabao Wang, Jianting He, Yajin Zhou, Lei Wu, Xingliang Yuan, Qinming He, and Kui Ren. 2021.  Defiranger: Detecting price manipulation attacks on defi applications.  _arXiv preprint arXiv:2104.15068_ (2021).
  * Yang et al. (2022) Sen Yang, Fan Zhang, Ken Huang, Xi Chen, Youwei Yang, and Feng Zhu. 2022.  Sok: Mev countermeasures: Theory and practice.  _arXiv preprint arXiv:2212.05111_ (2022).
  * Zero MEV (2022) Zero MEV. 2022.  Toxic Arbitrage.  https://info.zeromev.org/terms.html#toxic-arbitrage.
  * Zhou et al. (2021b) Liyi Zhou, Kaihua Qin, Antoine Cully, Benjamin Livshits, and Arthur Gervais. 2021b.  On the just-in-time discovery of profit-generating transactions in defi protocols. In _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE, 919–936.
  * Zhou et al. (2021a) Liyi Zhou, Kaihua Qin, and Arthur Gervais. 2021a.  A2mm: Mitigating frontrunning, transaction reordering and consensus instability in decentralized exchanges.  _arXiv preprint arXiv:2106.07371_ (2021).
  * Zhou et al. (2021c) Liyi Zhou, Kaihua Qin, Christof Ferreira Torres, Duc V Le, and Arthur Gervais. 2021c.  High-frequency trading on decentralized on-chain exchanges. In _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE, 428–445.

##  Appendix A Ethics

This work collects several types of data, including Ethereum transactions from
Etherscan, and Flashbots/relay/private transaction data from Blocknative.
Ethereum data is accessible to everyone from Etherscan. As the data from
Blocknative, they are voluntarily provided by their respective organizations
for research purposes. We underline that all data collected in this work is
publicly available, therefore, this work does not raise any ethical issues.