Frontrunner Jones and the Raiders of the Dark Forest:

An Empirical Study of Frontrunning on the

Ethereum Blockchain

Christof Ferreira Torres Ramiro Camino

SnT/University of Luxembourg Luxembourg Institute of Science and Technology
Radu Statee
arXiv:2102.03347v1 [cs.CR] 5 Feb 2021

SnT/University of Luxembourg

Abstract paper is among the first comprehensive surveys on the ex-

tent and impact of this phenomenon. Already in 2017, the
Ethereum prospered the inception of a plethora of smart con-
Bancor ICO [11] was susceptible to such an attack – among
tract applications, ranging from gambling games to decentral-
other vulnerabilities – but no real attack was observed in the
ized finance. However, Ethereum is also considered a highly
wild. Some concrete frontrunning attacks on the Ethereum
adversarial environment, where vulnerable smart contracts
blockchain were brought to knowledge by two independently
will eventually be exploited. Recently, Ethereum’s pool of
reported attacks and their mitigation approaches to the in-
pending transaction has become a far more aggressive envi-
formed audience. In the first report [10], the researchers tried
ronment. In the hope of making some profit, attackers con-
to recover some liquidity tokens by calling a specific func-
tinuously monitor the transaction pool and try to front-run
tion in a smart contract. Since this function was callable
their victims’ transactions by either displacing or suppressing
by everyone, the authors – who also compared the pending
them, or strategically inserting their transactions. This paper
transactions in the transaction pool to a dark forest full of
aims to shed some light into what is known as a dark forest
predators – assumed that their function call could be observed
and uncover these predators’ actions. We present a method-
and front-runned by bots observing the submitted transactions
ology to efficiently measure the three types of frontrunning:
in the transaction pool. Even though they tried to obfuscate
displacement, insertion, and suppression. We perform a large-
their efforts, their approach failed in the end, and they be-
scale analysis on more than 11M blocks and identify almost
came a victim of a frontrunning bot. A few months later, a
200K attacks with an accumulated profit of 18.41M USD for
second group of researchers [24] reported a successful re-
the attackers, providing evidence that frontrunning is both,
covery using lessons learned from the previously reported
lucrative and a prevalent issue.
incident [10]. The success was due to them mining their trans-
actions privately without broadcasting them to the rest of the
1 Introduction network. The researchers used a new functionality provided
by SparkPool called the Taichi Network [15]. In this way,
The concept of frontrunning is not new. In financial markets, the transactions were not available to frontrunning bots but
brokers act as intermediaries between clients and the market, relied entirely on having a reliable and honest mining pool.
and thus brokers have an advantage in terms of insider knowl- However, this approach enables centralization and requires
edge about potential future buy/sell orders which can impact users to entrust their transactions to SparkPool. Similar to how
the market. In this context, frontrunning is executed by priori- honeypots gather intelligence by luring attackers to compro-
tizing a broker’s trading actions before executing the client’s mise apparently vulnerable hosts [8], a recent experiment [21]
orders such that the trader pockets a profit. Front-running detailed the interactions with two bots and reported relevant
is illegal in regulated financial markets. However, the recent assessment on their nature and origin. Surprisingly, the front-
revolution enabled by decentralized finance (DeFi), where running bots do not rely on advanced software development
smart contracts and miners replace intermediaries (brokers) is techniques or complex instructions, and code examples on
both, a blessing and a curse. Removing trusted intermediaries developing such bots are readily available [22, 23]. There are
can streamline finance and substantially lower adjacent costs, several ways to perform frontrunning attacks. The first survey
but misaligned incentives for miners leads to generalized fron- defining a taxonomy of frontrunning attacks [12] identified
trunning, in which market participants behave exactly like three different variants on how these can be performed. To
unethical brokers used to in the “old” financial world. Un- understand these approaches – displacement, insertion, and
fortunately, this is already happening at a large scale. Our suppression – a short refresh on gas and transaction fees in

1
Ethereum is given. Transactions, submitted to the Ethereum 2 Background
network, send money and data to smart contract addresses
or account addresses. Transactions are confirmed by miners This section provides the necessary background to understand
who get paid via a fee that the sender of the transaction pays. our work setting, including smart contracts, transactions, gas
This payment is also responsible for the speed/priority min- economics, and transaction ordering.
ers include a transaction in a mined block. Miners have an
inherent incentive to include high paying transactions and
2.1 Smart Contracts
prioritize them. As such, nodes observing the unconfirmed
transactions can front-run by just sending transactions with The notion of smart contracts has already been introduced
higher payoffs for miners [9]. The common feature of all three in 1997 by Nick Szabo [25], but the concept only became a
attack types is that by frontrunning a transaction, the initial reality with the inception of Ethereum in 2015 [29]. Ethereum
transaction’s expected outcome is changed. In the case of the proposes two types of accounts: externally owned accounts
first attack (displacement), the outcome of a victim’s original (EOA) and contract accounts (smart contracts). EOAs are con-
transaction is irrelevant. The second attack type (insertion) trolled via private keys and have no associated code. Contract
manipulates the victim’s transaction environment, thereby accounts, i.e., smart contracts, have associated code but are
leading to an arbitrage opportunity for the attacker. Finally, not controlled via private keys. They operate as fully-fledged
the third attack (suppression) delays the execution of a vic- programs that are stored and executed across the blockchain.
tim’s original transaction. Although previous papers [9, 12] EOAs and smart contracts are identifiable via a unique 160-bit
have identified decentralized applications which are victims address. Smart contracts are immutable, and they cannot be
of frontrunning attacks, no scientific study has analyzed the removed or updated once they have been deployed unless they
occurrence of these three attacks in the wild on a large scale. have been explicitly designed to do so. Besides having a key-
The impact of this structural design failure of the Ethereum value store that enables them to preserve their state across
blockchain is far-reaching. Many decentralized exchanges, executions, smart contracts also have a balance that keeps
implementing token-based market places have passed the 1B track of the amount of ether (Ethereum’s cryptocurrency)
USD volume [26] and are prone to the same frontrunning that they own. Smart contracts are usually developed using a
attack vectors because the Ethereum blockchain is used as a high-level programming language, such as Solidity [30]. The
significant building block. Frontrunning is not going to dis- program code is then compiled into a low-level bytecode rep-
appear any time soon, and the future looks rather grim. We resentation, which is then interpreted by the Ethereum Virtual
do not expect to have mitigation against frontrunning in the Machine (EVM). The EVM is a stack-based virtual machine
short-term. Miners do profit from the fees and thus will al- that supports a set of Turing-complete instructions.
ways prioritize high yield transactions. Moreover, the trust
mechanism in Ethereum is built on the total observability of
the confirmed/unconfirmed transactions and is thus by design 2.2 Transactions
prone to frontrunning. Our paper sheds light into the long Smart contracts are deployed and executed via transactions.
term history of frontrunning on the Ethereum blockchain and Transactions contain an amount of ether, a sender, a receiver,
provides the first large scale data-driven investigation of this input data, a gas limit and a gas price. Transactions may only
type of attack vector. We investigate the real profits made by be initiated by EOAs. Smart contract functions are invoked
attackers, differentiated by the specific attack type and pro- by encoding the function signature and arguments in a trans-
pose the first methodology to detect them efficiently. action’s data field. A fallback function is executed whenever
Contributions. We summarize our contributions as follows: the provided function name is not implemented. Smart con-
• We propose a methodology that is efficient enough to tracts may call other smart contracts during execution. Thus,
detect displacement, insertion, and suppression attacks a single transaction may trigger further transactions, so-called
on Ethereum’s past transaction history. internal transactions.

• We run an extensive measurement study and analyze

frontrunning attacks on Ethereum for the past five years. 2.3 Gas Economics
• We identify a total of 199,725 attacks, 1,580 attacker Ethereum employs a gas mechanism that assigns a cost to each
accounts, 526 bots, and over 18.41M USD profit. EVM instruction. This mechanism prevents denial-of-service
attacks and ensures termination. When issuing a transaction,
• We demonstrate that the identified attacker accounts and the sender has to specify a gas limit and a gas price. The gas
bots can be grouped to 137 unique attacker clusters. limit is specified in gas units and must be large enough to
• We discuss frontrunning implications and find that min- cover the amount of gas consumed by the instructions during a
ers made a profit of 300K USD due to frontrunners. contract’s execution. Otherwise, the execution will terminate
abnormally, and its effects will be rolled back. The gas price

2
 𝑇! 𝑇! 𝑇! 𝑇! 𝑇! 𝑇!
Ordered by Gas Price

𝑇" 𝑇$ 𝑇" 𝑇$! 𝑇" 𝑇$!

𝑇# 𝑇% 𝑇# 𝑇% 𝑇# 𝑇$"

𝑇# 𝑇$" 𝑇$#

𝑇# 𝑇%

𝑇#

(a) Displacement (b) Insertion (c) Suppression

Transaction Pool Proposed Block

(Pending Transactions)

Figure 1: Illustrative examples of the three frontrunning attack types.

defines the amount of ether that the sender is willing to pay deliberately creating a prioritization mechanism for transac-
per unit of gas used. The sender is required to have a balance tions [31].
greater than or equal to gas limit × gas price, but the final
transaction fee is computed as the gas used × gas price. The
price of gas is extremely volatile as it is directly linked to the 3 Frontrunning Attacks
price of ether. As a result, Breidenbach et al. [6] proposed
GasToken, a smart contract that allows users to tokenize gas. This section defines our attacker model and introduces the
The idea is to store gas when ether is cheap and spend it reader to three different types of frontrunning attacks.
when ether is expensive, thereby allowing users to save on
transaction fees. Two versions of GasToken exist, whereby 3.1 Attacker Model
the second version is more efficient than the first one. The
first version of GasToken (GST1) exploits the fact that gas is Miners, as well as non-miners, can mount frontrunning attacks.
refunded when storage is freed. Hence, gas is saved by writing Miners are not required to pay a higher gas price to manip-
to storage and liberated when deleting from storage. The ulate the order of transactions as they have full control over
second version of GasToken (GST2) exploits the refunding how transactions are included. Non-miners, on the other hand,
mechanism of removing contracts. Hence, gas is saved by are required to pay a higher gas price in order to front-run
creating contracts and liberated by deleting contracts. In 2020, transactions of other non-miners. Our attacker model assumes
1inch released their version of GST2 called ChiToken [1], an attacker A that is a financially rational non-miner with
which includes some optimizations. the capability to monitor the transaction pool for incoming
transactions. The attacker A needs to process the transactions
in the pool, find a victim V among those transactions and
2.4 Transaction Ordering create a given amount of attack transactions TAi before the
victim’s transaction TV is mined. Usually, A would not be
A blockchain is essentially a verifiable, append-only list of able to react fast enough to perform all these tasks manually.
records in which all transactions are recorded in so-called Hence, we assume that the attacker A has at least one com-
blocks. This list is maintained by a distributed peer-to-peer puter program BotA that automatically performs these tasks.
(P2P) network of distrusting nodes called miners. Miners However, BotA must be an off-chain program, because con-
follow a consensus protocol that dictates the appending of tracts cannot react on its own when transactions are added to
new blocks. They compete to create a block by solving a the pool. Nevertheless, BotA needs at least one or more EOAs
cryptographic puzzle. The winner is rewarded with a static to act as senders of any attack transaction TA . Using multiple
block reward and the execution fees from the included trans- EOAs helps attackers obscure their frontrunning activities,
actions [14]. While blockchains prescribe specific rules for similar to money laundering layering schemes. We refer to
consensus, there are only loose requirements for selecting these EOAs owned by A as attacker accounts EOAA j and to
and ordering transactions. Thus, miners get to choose which the EOA owned by V as victim account EOAV . We assume
transactions to include and how to order them inside a block. that attacker A owns a sufficiently large balance across all
Nevertheless, 95% of the miners choose and order their trans- its attacker accounts EOAA j from which it can send frontrun-
actions based on the gas price to increase their profit, thereby ning transactions. However, attacker A can also employ smart

3
 Suppression. In a suppression attack, an attacker A observes
a transaction TV from a victim V and decides to broad-
Attacker Bot Attacker EOAs Bot Contracts
cast its transactions to the network, which have a higher
gas price than TV such that miners will include A’s trans-
action before TV (see Figure 1 c). The goal of A is to
suppress transaction TV , by filling up the block with its
transactions such that transaction TV cannot be included
anymore in the next block. This type of attack is also
Off-Chain On-Chain called block stuffing. Every block in Ethereum has a
so-called block gas limit. The consumed gas of all trans-
actions included in a block cannot exceed this limit. A’s
Figure 2: Attacker model with on-chain and off-chain parts. transactions try to consume as much gas as possible to
reach this limit such that no other transactions can be
included. This type of attack is often used against lotter-
contracts to hold part of the attack logic. We refer to these ies where the last purchaser of a ticket wins if no one
smart contracts as bot contracts BCAk , which are called by the else purchases a ticket during a specific time window.
attacker accounts EOAA j . Figure 2 provides an overview of Attackers can then purchase a ticket and mount a sup-
our final attacker model. pression attack for several blocks to prevent other users
from purchasing a ticket themselves. Keep in mind that
this type of frontrunning attack is expensive.
3.2 Frontrunning Taxonomy
We describe in the following the taxonomy of frontrunning
4 Measuring Frontrunning Attacks
attacks presented by Eskandari et al. [12].
This section provides an overview of our methodology’s de-
Displacement. In a displacement attack an attacker A ob- sign and implementation details to detect frontrunning attacks
serves a profitable transaction TV from a victim V and in the wild.
decides to broadcast its own transaction TA to the net-
work, where TA has a higher gas price than TV such that
miners will include TA before TV (see Figure 1 a). Note 4.1 Identifying Attackers
that the attacker does not require the victim’s transaction
to execute successfully within a displacement attack. For As defined in Section 3.1, an attacker A employs one or more
example, imagine a smart contract that awards a user off-chain programs to perform its attacks. However, because
with a prize if they can guess the preimage of a hash. An we have no means to distinguish between the different soft-
attacker can wait for a user to find the solution and to sub- ware agents an attacker A could have, for this study, we con-
mit it to the network. Once observed, the attacker then sider all of them as part of the same multi-agent system BotA .
copies the user’s solution and performs a displacement Additionally, we cannot recognize the true nature of A or how
attack. The attacker’s transaction will then be mined first, BotA is implemented. Instead, we would like to build a cluster
thereby winning the prize, and the user’s transaction will with the n different attacker accounts EOAA1 , . . ., EOAAn and
be mined last, possibly failing. the m different bot contracts BCA1 , . . ., BCAm to form an iden-
tity of A. Consequently, in each of the following experiments,
Insertion. In an insertion attack an attacker A observes a we use our detection system’s results to build a graph. Each
profitable transaction TV from a victim V and decides node is either an attacker account or a bot contract. We make
to broadcast its own two transactions TA1 and TA2 to the the following two assumptions:
network, where TA1 has a higher gas price than TV and
TA2 has a lower gas price than TV , such that miners will Assumption 1: Attackers only use their own bot contracts.
include TA1 before TV and TA2 after TV (see Figure 1 b). Hence, when an attacker account sends a transaction to
This type of attack is also sometimes called a sandwich a bot contract, we suspect that both entities belong to the
attack. In this type of attack, the transaction TV must same attacker. Note that one attacker account can send
execute successfully as TA2 depends on the execution of transactions to multiple bot contracts, and bot contracts
TV . A well-known example of insertion attacks is arbi- can receive transactions from multiple attacker accounts.
traging on decentralized exchanges, where an attacker
observes a large trade, also known as a whale, sends a Assumption 2: Attackers develop their own bot contracts,
buy transaction before the trade, and a sell transaction and they do not publish the source code of their bot con-
after the trade. tracts as they do not want to share their secrets with

4
 Input Bytes 4 bytes with an offset of 1 byte and check whether at least
deadbeefcafebabe ... 95% of the n-grams match n-grams of previous transaction
deadbeef
inputs. Each window has its own Bloom filter that memorizes
previously observed n-grams. A Bloom filter is a probabilis-
adbeefca
tic data structure that can efficiently tell if a given element
beefcafe
may already have been seen before or if it definitely has not
...
been seen before, meaning that Bloom filters may yield false
positives, but no false negatives. The idea is first to use a
Bloom filter to perform a quick probabilistic search and only
0 1 1 1 1 0 1 0 1 0 0 0 0 0 1 0 perform an exhaustive linear search if the filter finds that at
Bloom Filter least 95% of a transaction’s n-grams are contained in the filter.
Our Bloom filters can hold up to n = 1M elements with a false
positive rate p = 1%, which according to Bloom [3], requires
Figure 3: An example on how transaction input bytes are having k = 6 different hash functions:
mapped into a bloom filter.
n ln p
m=− (1)
(ln 2)2
competitors. Hence, when the bytecode of two bot con-
tracts is exactly the same, we suspect that they belong to m
k= ln 2 (2)
the same attacker. n
We bootstrapped our 6 hash functions using the Murmur3
With these assumptions in mind, we create edges between hash function as a basis. The result of each hash function is
attacker accounts and bot contracts that share at least one an integer that acts as an index on the Bloom filter’s bit array.
attack transaction, and between bots that share the same byte- The bit array is initialized at the beginning with zeros, and a
code. Using the resulting graph, we compute all the connected value of one is set for each index returned by a hash function
components. Hence, we interpret each of these connected (see Figure 3). An n-gram is considered to be contained in
components as a single attacker cluster. the filter if all indices of the 6 hash functions are set to one.
We use interleaved n-grams because the input of a copied
transaction might be included at any position in the attacker’s
4.2 Detecting Displacement
input. Once our linear search finds two transactions TA and TV
We limit our detection to displacement attacks where attack- with matching inputs, we check whether the following three
ers observe profitable transactions via the transaction pool heuristics hold:
and copy these profitable transactions’ input to create their Heuristic 1: The sender of TA and TV as well as the receiver
own profitable transactions. While attackers are not required of TA and TV must be different.
to use a bot contract to mount displacement attacks, using a
smart contract allows them to save money as they can abort Heuristic 2: The gas price of TA must be larger than the gas
the execution in case of an unexpected event. Therefore, our price of TV .
detection focuses on finding attackers that use bot contracts
Heuristic 3: We split the input of TA and TV into sequences
to perform internal transactions of copied inputs. The general
of 4 bytes, and the ratio between the number of the se-
idea is to detect displacement by checking for every trans-
quences must be at least 25%.
action T if there exists a subsequent transaction T 0 with a
gas price lower than T and a transaction index higher than T , Finally, to validate that TA is a copy of TV , we run in a sim-
where the input of T 0 is contained inside the input of T . How- ulated environment first TA before TV and then TV before TA .
ever, detecting displacement in the wild can become quite We report a finding if the number of executed EVM instruc-
challenging due to a large number of possible combinations. tions is different across both runs for TA and TV , as this means
A naive approach would compare every transaction to ev- that TA and TV influence each other. During our experiments,
ery subsequent transaction in the blockchain, resulting in a we noted, that some bot contracts included code that checks if
combinatorial explosion. Our goal is to follow a more effi- the miner address of the block that is currently being executed
cient approach that might sacrifice completeness but preserve is not equal to zero. We think that the goal of this mechanism
soundness. We begin by splitting the range of blocks that are could be to prevent transactions from being run locally.
to be analyzed into windows of 100 blocks and slide them
with an offset of 20 blocks. This approach has the advantage
4.3 Detecting Insertion
that each window can be analyzed in parallel. Inside each
window, we iterate block by block, transaction by transaction, We limit our detection to insertion attacks on decentralized
and split the input bytes of each transaction into n-grams of exchanges (DEXes). At the time of writing, we are not aware

5
of any other use case where insertion attacks are applied in
the wild. DEXes are decentralized platforms where users can
trade their ERC-20 tokens for ether or other ERC-20 tokens
via a smart contract. Uniswap is currently the most popu-
lar DEX in terms of locked value with 3.15B USD locked1 .
There exist two genres of DEXes, order book-based DEXes

Token 𝑦 Reserve
and automated market maker-based (AMM) DEXes. While
order book-based DEXes match prices based on so-called
’bid’ and ’ask’ orders, AMM-based DEXes match and settle
trades automatically on-chain via a smart contract, without 𝑝!" (sell)
the need of third party service. AMMs are algorithmic agents 𝑝" (buy)
that follow a deterministic approach to calculate the price 𝑝!! (buy)
of a token. Uniswap, for example, is an AMM-based DEX,
which computes for every trade the price of a token using the
Token 𝑥 Reserve
equation of a constant product market maker (CPMM):

[x] × [y] = k (3) Figure 4: An illustrative example of an insertion attack on an

AMM-based DEX that uses CPMM.
where [x] is the current reserve of token x and [y] is the current
reserve of token y. Trades must not change the product k of a
functions and events that enable users to trade their tokens
pair’s reserve. Thus, if the underlying token reserves decrease
between each other and across exchanges. In particular, when-
as a trader is buying, the token price increases. The same holds
ever a token is traded, a so-called Transfer event is triggered,
in the opposite direction: if the underlying token’s reserve
and information about the sender, receiver, and the amount is
increases while a trader is selling, the token price decreases.
logged on the blockchain. We combine this information with
Despite being simple, CPMMs are incredibly susceptible to
transactional information (e.g., transaction index, gas price,
price slippage. Price slippage refers to the difference between
etc.) to detect insertion attacks. We define a transfer event
a trade’s expected price and the price at which the trade is ex-
as E = (s, r, a, c, h, i, g), where s is the sender of the tokens, r
ecuted. Given the public nature of blockchains, attackers can
is the receiver of the tokens, a is the number of transferred
observe large buy orders before miners pick them up by mon-
tokens, c is the token’s contract address, h is the transaction
itoring the transaction pool. These large buy orders will have
hash, i is the transaction index, and g is the gas price of the
a significant impact on the price of a token. Leveraging this
transaction. We detect insertion attacks by iterating block by
knowledge and the fact that miners order transactions based
block through all the transfer events and checking if there
on transaction fees, attackers can insert their buy order in front
are three events EA1 , EV , and EA2 for which the following six
of an observed large buy order and insert a sell order after the
heuristics hold:
observed large buy order to profit from the deterministic price
calculation. Figure 4 depicts an example of an insertion attack Heuristic 1: The exchange transfers tokens to A in EA1 and
on an AMM-based DEX that uses CPMM. Let us assume that to V in EA1 , and the exchange receives tokens from A in
a victim V wants to purchase some tokens at a price p. Let EA2 . Moreover, A transfers tokens in EA2 that it received
us also assume that an attacker A observes V ’s transaction previously in EA1 . Thus, the sender of EA1 must be iden-
and sends in two transactions: 1) a buy transaction which also tical to the sender of EV as well as the receiver of EA2 ,
tries to purchase some tokens at a price p, but with a gas price and the receiver of EA1 must be identical to the sender
higher than V , and 2) a sell transaction that tries to sell the of EA2 (i.e., sA1 = sV = rA2 ∧ rA1 = sA2 ).
purchased tokens, but with a gas price lower than V . Since A
pays a higher gas price than V , A’s purchase transaction will Heuristic 2: The number of tokens bought by EA1 must be
be mined first and A will be able to purchase the tokens at similar to the number of tokens sold by EA2 . To avoid
price p, where p = pA1 (cf. Figure 4). Afterwards, V ’s trans- false positives, we set a conservative threshold of 1%.
action will be mined. However, V will purchase tokens at a Hence, the difference between token amount aA1 of EA1
higher price pV , where pV > pA1 due to the imbalance in the and token amount aA2 of EA2 cannot be more than 1%
|aA1 −aA2 |
token reserves (see Equation 3). Finally, A’s sell transaction (i.e., ≤ 0.01).
max(aA1 ,aA1 )
will be mined, for which A will sell its tokens at price pA2 ,
where pA2 > pA1 and therefore A making profit. Our detection Heuristic 3: The token contract addresses of EA1 , EV , and
algorithm exploits the fact that DEXes depend on the ERC-20 EA2 must be identical (i.e., cA1 = cV = cA2 ).
token standard. The ERC-20 token standard defines many
Heuristic 4: The transaction hashes of EA1 , EV , and EA2
1 https://defipulse.com/ must be dissimilar (i.e., hA1 6= hV 6= hA2 ).

6
Heuristic 5: The transaction index of EA1 must be smaller If we happen to find a cluster that fulfils the heuristics men-
than the transaction index of EV , and the transaction tioned above, we check whether at least one of the neighbour-
index of EV must be smaller than the transaction index ing blocks (i.e., the previous block and the subsequent block)
of EA2 (i.e., iA1 < iV < iA2 ). also contains a cluster that satisfies the same heuristics. We
assume that an attacker tries to suppress transactions for a
Heuristic 6: The gas price of EA1 must be larger than the sequence of blocks. Finally, we try to detect if an attacker
gas price of EV , and the gas price of EA2 must be less of employs one of three suppression strategies by retrieving and
equal to the gas price of EV (i.e., gA1 > gV ≥ gA2 ). analyzing the execution trace of the first transaction in the
cluster. An execution trace consists of a sequence of executed
4.4 Detecting Suppression instructions. We detect the first strategy by checking if the
transaction did not raise an exception and if the instruction se-
In suppression, an attacker’s goal is to submit transactions to
quence [GAS, GT, ISZERO, JUMPI] is executed more than
the network that consume large amounts of gas and fill up the
ten times in a loop. We detect the second strategy by checking
block gas limit to withhold a victim’s transaction. There are
if the transaction raised an exception via a revert and if the
several ways to achieve this. The naive approach uses a smart
instruction sequence [SLOAD, TIMESTAMP, ADD, SSTORE]
contract that repeatedly executes a sequence of instructions in
is executed more than ten times in a loop. Finally, we de-
a loop to consume gas. This strategy can either be controlled
tect the third strategy by checking if the transaction raised an
or uncontrolled. In a controlled setting, the attacker repeat-
exception via an assert.
edly checks how much gas is still left and exits the loop right
before all gas is consumed such that no out-of-gas exception
is raised. In an uncontrolled setting, the attacker does not 4.5 Challenges and Limitations
repeatedly check how much gas is left and lets the loop run
until no more gas is left and an out-of-gas exception is raised. We were compelled to make trade-offs between efficiency
The former strategy does not consume all the gas and does not and completeness with more than 11M blocks and over 1B
raise an exception which makes it less obtrusive, while the transactions. For instance, to detect displacement attacks, we
latter strategy does consume all the gas but raises an excep- had to set a window size of 100 blocks, meaning that we could
tion which makes it more obtrusive. However, a third strategy not detect displacement attacks were an attacker’s transaction
achieves precisely the same result without running code in and a victim’s transaction are more than 100 blocks apart.
an infinite loop. If we think about it, the attacker’s goal is Another example is insertion detection, where we assume
not to execute useless instructions but rather to force miners that the attacks occur within the same block. However, this
to consume the attacker’s gas units to fill up the block. The assumption does not always hold, as transactions might be
EVM proposes two ways to raise an error during execution, scattered across different blocks during the mining process.
either through a revert or an assert. The difference between Theoretically, it would be possible to attack victims using
revert and assert is that the former returns the unused gas to attacker accounts directly for displacement and suppression
the transaction sender, while the latter consumes the entire attacks. However, our detection heuristics rely on the exis-
gas limit initially specified by the transaction sender. Hence, tence of the bot contracts to identify attackers as a single
an attacker can exploit this and call an assert to consume all entity. Considering these limitations, all the results presented
the provided gas with just one instruction. Our goal is to de- in this paper should be interpreted as lower bounds, and they
tect transactions that employ one of the three aforementioned might be solely the tip of the iceberg.
suppression strategies: controlled gas loop, uncontrolled gas
loop, and assert. We start by clustering for each block all
transactions with the same receiver, as we assume that attack- 5 Analyzing Frontrunning Attacks
ers send multiple suppression transactions to the same bot
contract. Afterwards, we check the following heuristics for In this section, we analyze the results of our large scale mea-
each cluster: surement study on detecting frontrunning in Ethereum.

Heuristic 1: The number of transactions within a cluster

must be larger than one. 5.1 Experimental Setup
Heuristic 2: All transactions within the cluster must have We implemented our detection modules using Python with
consumed more than 21,000 gas units. This heuristic roughly 1,700 lines of code2 . We run our modules on the first
goal is to filter out transactions that only transfer money, 11,300,000 blocks of the Ethereum blockchain, ranging from
but do not execute code. July 30, 2015 to November 21, 2020. All our experiments
were conducted using a machine with 128 GB of memory and
Heuristic 3: The ratio between gas used and gas limit must
be larger than 99% for all transactions within the cluster. 2 The code and data will be publicly released.

7
10 Intel(R) Xeon(TM) L5640 CPUs with 12 cores each and of more than 4.1M USD while spending over 40K USD in
clocked at 2.26 GHz, running 64 bit Ubuntu 16.04.6 LTS. transaction fees. We can also see that the attacker used 16
different accounts and 3 different bots to mount its attacks.
The minimum amount of profit that an attacker made with
5.2 Analyzing Displacement displacement is 0.01 USD. Overall, the average number of
Overall Results. We identified a total of 2,983 displacement attacks per attacker cluster is 175.47 attacks, using 2.88 ac-
attacks from 49 unique attacker accounts and 25 unique bot counts and 1.47 bots. However, we also observe from the
contracts. Using the graph analysis defined in Section 4.1 we distribution that at least half of the attackers only use one
identified 17 unique attacker clusters. account and one bot contract.

Cost (USD) Profit (USD) Attacks Attacker Accounts Bot Contracts

Profitability. We compute the gain of an attacker A on each
mean 2,505.09 269,872.45 175.47 2.88 1.47
displacement attack by searching how much ether EOAA re- std 9,776.51 1,005,283.40 555.03 3.89 0.80
ceives among the internal transactions triggered by TA . Ad- min 0.05 0.01 1.00 1.00 1.00
25% 0.14 3.53 1.00 1.00 1.00
ditionally, we obtain the profit by subtracting the attack cost 50% 3.98 726.70 5.00 1.00 1.00
from the gain, where cost is defined solely by the fees of TA . 75% 65.78 4,670.94 8.00 3.00 2.00
max 40,420.63 4,152,270.01 2249.00 16.00 3.00
Finally, for each attack we convert the ether cost and profit
into USD by taking the conversion rate valid at the time of
the attack. Table 2: Distributions for displacement attacker clusters.

Attacks. We can see in Table 1 the distribution of each vari-

able we collected per displacement attack. The cost and the 5.3 Analyzing Insertion
profit do not appear to be very high for most of the attacks,
but the distributions of both variables present very long tails Overall Results. We identified a total of 196,691 insertion
to the right. Additionally, we compute the Gas Price ∆ as the attacks from 1,504 unique attacker accounts and 471 unique
gas price of TA minus the gas price of TV . This value indicates bot contracts. Using the graph analysis defined in Section 4.1
how much the attacker A is willing to pay to the miners so we identified 98 unique attacker clusters.
they execute TA before TV . Table 1 shows that most of the
attacks contain a very small gas price difference in GWei Profitability. We compute the cost for each attack as the
(and cannot be represented with only two digits of precision), sum of the amount of ether an attacker spent in TA1 and the
but there are very extreme cases with a difference close to fees imposed by transactions TA1 and TA2 . Additionally, we
50 GWei. Furthermore, we compute the Block ∆ to indicate compute the profitability of an attack as the amount of ether
how many blocks are between the execution of TA and TV . an attacker gained in TA2 minus the cost. Finally, for each
Again we can see in Table 1 that for most of the attacks, both attack we convert the ether cost and profit into USD by taking
transactions were executed in the same block, but there are the conversion rate valid at the time of the attack.
some extreme cases with a long block distance of 19 blocks.
Attacks. We can see in Table 3 the distribution of each vari-
Cost (USD) Profit (USD) Gas Price ∆ (GWei) Block ∆ able we collected per insertion attack. The cost and the profit
mean 14.28 1,537.99 0.43 0.78
do not appear to be very high for most of the attacks, but
std 18.25 7,162.80 2.65 2.37 the distributions of both variables present very long tails to
min 0.01 0.00 0.00 0.00 the right. Note that the profit also present very large negative
25% 4.36 1.14 0.00 0.00 values to the left, meaning that there are extreme cases of
50% 9.48 158.53 0.00 0.00 attackers losing money. Additionally, we compute the Gas
75% 16.64 851.04 0.00 0.00
max 311.69 223,150.01 52.90 19.00 Price ∆1 and Gas Price ∆2 as the gas price of TA1 minus the
gas price of TV , and the gas price of TV minus the gas price of
TA2 respectively. This value indicates how much the attacker
Table 1: Distributions for displacement attacks. A is willing to pay to the miners so they execute TA1 before TV
and also if TA2 can be executed after TV . Table 3 shows that
25% of the attacks contain a very small Gas Price ∆1 in GWei
Attacker Clusters. Every cluster contains bot accounts with (and cannot be represented with only two digits of precision),
different bytecode, with the exception of one cluster that con- but that half or more paid a significant difference, reaching
tains three bot accounts with the exact same bytecode. Table 2 some extreme cases of more than 76K GWei. For Gas Price
presents the distribution of each attacker cluster variable. The ∆2 most of the attacks have a very small value, but there are
first variable describes profit, where we can see that a single extreme cases, which mean that some attacks are targeting
attacker mounted 2,249 attacks making an accumulated profit transactions with very high gas prices.

8
 Bancor Uniswap V1 Uniswap V2 SushiSwap
Bancor Uniswap V1 Uniswap V2 SushiSwap
Release Release Release Release
Insertion Attacks [log]

103

102

101

100
2018-01 2018-05 2018-09 2019-01 2019-05 2019-09 2020-01 2020-05 2020-09

Figure 5: Weekly average of daily insertion attacks per decentralized exchange.

Cost (USD) Profit (USD) Gas Price ∆1 (GWei) Gas Price ∆2 (GWei) Exchange Combination Attacker Clusters
mean 19.41 65.05 407.63 3.88
Uniswap V2 72
std 51.15 233.44 1,897.47 137.12
min 0.01 -10,620.61 0.00 0.00 Uniswap V1 16
25% 4.09 7.86 0.00 0.00 SushiSwap, Uniswap V2 4
50% 7.74 24.07 5.25 0.00 Bancor 3
75% 15.23 62.92 74.10 0.00 Uniswap V1, Uniswap V2 2
max 1,822.22 20,084.01 76,236.09 27,396.63 Bancor, SushiSwap, Uniswap V1, Uniswap V2 1

Table 3: Distributions for insertion attacks. Table 4: Exchange combination count by attacker cluster.

Gas Tokens. We analyzed how many attacks were mounted to the core functionality of Uniswap V1 and Uniswap V2 be-
using gas tokens. Gas tokens allow attackers to reduce their ing the same and that SushiSwap is a direct fork of Uniswap
gas costs. We found that 63,274 (32,17%) of the insertion V2. Thus, for attackers it was probably straightforward to
attacks we measured were performed using gas tokens. 48,281 take their existing code for Uniswap V1 and adapt it to attack
(76.3%) attacks were mounted using gas tokens only for the Uniswap V2 as well as SushiSwap. The peak of insertion
first transaction TA1 , 1,404 (2.22%) attacks were mounted by attacks was on October 5, 2020, with 2,749 daily attacks. We
employing gas tokens only for the second transaction TA2 , measured in total 3,004 attacks on Bancor, 13,051 attacks
and 13,589 (21.48%) attacks were mounted by employing gas on Uniswap V1, 180,185 attacks on Uniswap V2, and 451
tokens for both transactions TA1 and TA2 . We also found that attacks on SushiSwap. Table 4 shows the different combina-
24,042 (38%) of the attacks used GST2, 14,932 (23.6%) used tions of exchanges that attackers try to front-run. We see that
ChiToken, and 24,300 (38.4%) used their own implementation most of the attackers focus on attacking Uniswap V2, with
or copy of GST2 and ChiToken. 72 attacker clusters (73.47%). We also see that 92.86% of the
attackers only focus on attacking one exchange. Moreover,
Exchanges and Tokens. We identified insertion attacks we observed one attacker that attacked all the 4 exchanges,
across 3,200 different tokens on four exchanges: Bancor, 2 attackers that attacked Uniswap V1 and Uniswap V2, and
Uniswap V1, Uniswap V2, and SushiSwap. Figure 5 depicts 4 attackers that attacked Uniswap V2 and SushiSwap. The
the weekly average of daily insertion attacks per exchange. latter is expected since SushiSwap is a direct fork of Uniswap
The first AMM-based DEX to be released on Ethereum was V2. Hence, the attackers can reuse their code from Uniswap
Bancor in November 2017. We observe from Figure 5 that the V2 to attack SushiSwap. What is interesting though, is the
first insertion attacks started in February 2018, targeting the fact that no attacker is attacking only SushiSwap, we see that
Bancor exchange. We also see that the number of insertion attacker always attack SushiSwap in conjunction to another
attacks increased tremendously with the rise of other DEXes, exchange.
such as Uniswap V1 and Uniswap V2. While it took 3 months
for attackers to launch their first insertion attacks on Uniswap Attack Strategies. In 186,960 cases (95.05%) the attackers
V1, it only took 2 weeks to launch attacks on Uniswap V2 and sold the exact same amount of tokens that they purchased.
5 days to launch attacks on SushiSwap. This is probably due Thus, an easy way to spot insertion attacks on decentralized

9
 [$H&F%E(FD&)'G&&(
'LUHFW$WWDFN
,QGLUHFW$WWDFNWKURXJKERWDFFRXQW

0 0 0 0 0 0 0 0

%ORFN1XPEHU
[HE()('$GHI)ED(E&(
,QGLUHFW$WWDFNWKURXJKERWDFFRXQW
'LUHFW$WWDFN

0 0 0 0 0

%ORFN1XPEHU

Figure 6: Two examples of attackers changing their strategies over time from direct attacks (i.e., using directly an exchange) to
indirect attacks (i.e., using a bot contract).

exchanges, could be to check for two transactions that have tified, many of the bot contracts share the same bytecode. The
the same sender and receiver, and where the first transaction most extreme case is an attacker cluster that contains 80 bot
buys the same amount of tokens that the second transaction contracts and all of them have the same bytecode. We find that
sells. However, some attackers try to obscure their buy and attackers were already able to make an accumulated profit of
sell transactions by using different sender accounts. We found over 13.9M USD. From Table 5, we see that an attacker makes
86,038 cases of attacks (43.74%) where attackers used a differ- on average a profit of over 130K USD per attacker cluster.
ent sender address to buy tokens than to sell tokens. Moreover, Moreover, the average profit per attack is 78.72 USD, whereas
besides trying to hide their sender accounts, attackers also try the median profit is 28.80 USD. The largest profit that has
to hide in some cases the addresses of their bot contracts by been made with a single attack was 20,084.01 USD. However,
using proxy contracts to forward for instance the call to buy not all the attacks were successful in terms of profit. We count
tokens to the bot contracts. To the outsider it will look like 19,828 (10.08%) attacks that resulted in an accumulated loss
two transactions with different receivers. We found only 5,467 of roughly 1.1M USD. The largest loss that we measured was
cases (2.78%) where the attackers are using proxy contracts 10,620.61 USD. The average loss is 56.93 USD per attack
to disguise calls to their bot contracts. Insertion is the only and the median loss is 14.26 USD per attack. Thus, the av-
attack type for which our heuristics can detect attacks that erage loss is still lower than the average profit, meaning that
do not employ bot contracts. For these cases, the attacker ac- insertion attacks are profitable despite bearing some risks.
counts call the DEXes directly. From all the insertion attacks
we detected, only 2,673 cases (0.01%) fall in this category of Cost (USD) Profit (USD) Attacks Attacker Accounts Bot Contracts
direct attacks. We included these attacks in most of the results, mean 38,807.63 130,246.93 1979.78 14.87 4.81
but we do not count them for the cluster computation since std 135,352.00 462,464.36 6053.68 90.59 10.09
min 0.98 -2,319.42 1.00 1.00 1.00
we cannot link the corresponding attacker accounts to any bot 25% 43.84 -9.78 4.25 1.00 1.00
contract. Figure 6 highlights examples of two accounts that 50% 419.74 691.48 68.50 2.00 2.00
75% 3,510.94 8,350.46 529.25 3.00 4.00
changed their attack strategy over time. The attackers initially max 686,850.37 2,262,411.95 39162.00 891.00 80.00
performed their attacks by calling directly the smart contract
of exchanges, but then switched to bot contracts over time. Table 5: Distributions for insertion attacker clusters.

Attacker Clusters. Among the attacker clusters that we iden- Competition. We found among our detected results 5,715

10
groups of at least two insertion attacks that share the same Suppression Strategy Attacks Successful Failed
block number, victim transaction and exchanged token but Assert 20 2 18
with different attackers. Included in those groups, we found Controlled Gas Loop 18 8 10
270 cases where at least two of the attackers targeting the Uncontrolled Gas Loop 12 3 9
same victim belong to the same attacker cluster. To explain
this phenomenon, we have three hypothesis. The first one Table 7: Suppression strategies.
is that an attacker would not interfere with its own attacks,
hence, our attacker clustering mechanism is incorrect. Since
our methodology is based on heuristics and we have no Profitability. In a suppression attack, the profit of the attacker
ground truth to validate them, we could expect to find oc- A is defined by the accumulated ether in the price pool of the
casional errors. However, since the heuristics are simple and suppressed contract. Note that the attack only obtains the
reasonable enough, we also consider the next two hypothesis. prize if it succeeds. Additionally, we subtract from the profit
The second one is that some attackers might not be clever the attack cost which is defined by the sum of the initial
enough to coordinate multiple agents working in parallel, investment on each round, and the accumulated fees of all the
and the self-interference could be an accident. And third, related transactions TAi . Finally, for each attack we convert
the parallel attacks could be a tactic to split the movements the ether cost and profit into USD by taking the conversion
of funds into smaller amounts to avoid becoming the tar- rate valid at the time of the attack.
get of other attackers. For example, we found two instances
where attackers became victims at the same time, namely ac- Attacks. We can see in Table 8 the distribution of each vari-
counts 0x5e334032Fca55814dDb77379D8f99c6eb30dEa6a able we collected per suppression attack. An interesting result
and 0xB5AD1C4305828636F32B04E5B5Db558de447eAff is that at least 75% of the attacks generate big losses. How-
in blocks 11,190,219 and 11,269,029, respectively. ever, there are also extreme cases with huge profits. Hence,
we could say that the suppression attacks are very risky but
that they can also yield high rewards. Along with the price
and cost, we also count the number of rounds, blocks and
5.4 Analyzing Suppression
transactions every attack contains. We can observe, as ex-
pected in Table 8, how all these metrics grow together with
Overall Results. We identified a total of 50 suppression at-
the cost. A suppression attack lasts on average 6.62 rounds
tacks originated from 98 attacker accounts and 30 bot con-
and an attacker stuffs on average 29.70 blocks with an average
tracts. From these entities, we identified 5 unique attacker
of 182.70 transactions.
clusters using the graph analysis defined in Section 4.1.
Cost (USD) Profit (USD) Rounds Blocks Transactions
Rounds, Success, and Failure. In this section we define a mean 2,349.65 20,725.24 6.62 29.70 182.70
suppression attack as a sequence of rounds. Each round starts std 3,331.21 113,598.58 12.86 50.77 456.91
with an investment transaction that sends ether to the victim’s min 4.67 -10,741.12 1.00 2.00 6.00
25% 221.87 -1,893.26 1.00 4.00 12.50
contract, which is added to a prize pool. The round then con- 50% 896.68 -284.81 2.00 10.00 33.50
tinues with a sequence of one or more stuffing transactions. 75% 2,719.69 -14.93 4.75 21.50 88.75
When another participant interrupts the stuffing sequence by max 10,741.12 791,211.86 66.00 233.00 2,664.00
sending a new investment transaction, the participant becomes
the new potential winner of the prize pool. This event termi- Table 8: Distributions for suppression attacks.
nates the round in a failure state, because the attacker cannot
claim the prize anymore. Otherwise, if an interruption never
occurs and the attacker can eventually claim the competition Attacker Clusters. Among the attacker clusters, we found
prize, the round is terminated with a success status. Thus, we only two pairs of bot contracts sharing the same bytecode.
define the status of an entire suppression attack as the status of From Table 9, we can see that the average profit per attacker
the last round in the corresponding sequence of rounds. From cluster is 47,102.81 USD and that the largest profit made by
the 50 suppression attacks we identified, 13 were successful an attacker cluster is over 777K USD. However, we also see
and 37 failed. that at least 50% of the attackers did not make any profit, and
that one attacker cluster made an accumulated loss of more
Suppression Strategies. In Table 7 we show the distribution than 19K USD. Also, we find that attackers mount on average
of suppression strategies split by successful and failed attacks. only 2.27 attacks and use in at least 75% of the cases only
We see that although the assert strategy is the most popular one attacker account and one bot contract. There is one case
one, it is not the most successful one. The controlled gas loop where an attacker was responsible for mounting 14 different
strategy seems to be the most successful in terms of attacks. attacks using 4 different accounts and 4 different bots.

11
 Suppressed Contract Address Contract Name Attacks Rounds Transactions Attackers Bot Contracts Attacker Clusters
0xA62142888ABa8370742bE823c1782D17A0389Da1 FoMo3Dlong 12 188 5875 81 8 4
0xDd9fd6b6F8f7ea932997992bbE67EabB3e316f3C Last Winner 16 20 304 27 5 2
0x5D0d76787D9d564061dD23f8209F804a3b8AD2F2 Peach Will 6 52 1105 26 5 2
0xB4a448387403554616eB5B50aa4C48f75243a015 Mobius2Dv2 1 4 82 19 1 1
0xbAbED6ca5C86B2347D374e88251Ca8007C417f55 The rabbit 1 1 15 13 1 1
0x42CeaD70158235a6ca4868F3CFAF600c7A7b0ebB ETH CAT 2 23 929 20 2 1
0x29488e24cFdAA52a0b837217926C0c0853Db7962 SuperCard 1 25 319 17 1 1
0xD15E559f6BD5C785Db35E550F9FbC80045b0a049 FDC 1 3 44 18 1 1
0xB7C2e4047Fb76508D4137BE787DaF28B013F00E6 Escape plan 2 3 67 20 2 1
0x9954fF17909893B443E2EE825066373960c2735A F3DPRO 1 1 41 18 1 1
0x3e22bB2279d6Bea3Cfe57f3Ed608fC3B1DeaDADf Star3Dlong 1 3 66 6 1 1
0x2c58B11405a6a8154FD3bbC4CcAa43924f2BE769 ERD 3 3 207 20 2 1
0x0fe2247a20E779a879c647D2b9deA1b896FC0ccf EFS 1 1 33 16 1 1
0xb178EA2c9023bb2DD500a607505D2aa121F92A35 RichKey 1 1 9 8 1 1
0xC75506dEAe7c01F47BCd330B324226CE9ba78e30 FomoXP 1 3 39 19 1 1

Table 6: List of contracts that were victims of suppression attacks.

Cost (USD) Profit (USD) Attacks Attacker Accounts Bot Contracts pay end up being for the miners in the form of transaction fees.
mean 5,340.12 47,102.81 2.27 1.36 1.36 Our results show that miners already earned more than 300K
std 9,320.23 167,264.11 2.98 0.79 0.79
min 4.67 -19,644.68 1.00 1.00 1.00 USD from transaction fees payed by the attackers performing
25% 173.36 -1,418.61 1.00 1.00 1.00 insertion frontrunning attacks. While transaction fees in Jan-
50% 1,001.67 -80.79 1.00 1.00 1.00
75% 4,737.54 3,536.96 2.00 1.00 1.00 uary 2018 only represented 9% of the monthly revenue of a
max 36,308.69 777,548.67 14.00 4.00 4.00 miner, in January 2021 nearly 40% of the monthly revenue
came from transaction fees [16]. Thus, besides attackers, we
Table 9: Distributions for suppression attacker clusters. also concluded that miners profit from frontunning attacks.
However, attackers and miners are not the only entities that
profit from frontrunning. Take the example of Uniswap. In
Competition. We found that suppression attacks only general, Uniswap takes a 0.3% fee on every transaction. This
targeted 15 unique contracts, which are listed in Ta- fee is divided between the liquidity providers, proportionally
ble 6. We can see that only the contracts Last Winner, to their share. For example, if you provide 50% of the liquid-
FoMo3Dlong, and Peach Will were targeted by different ity, then you will earn 50% of the collected fee. Thus, liquidity
attacker clusters. We searched through all the attacks for providers profit from every trade performed by frontrunners.
blocks where any of these three contracts were the vic- However, frontrunning attacks can also have some severe im-
tims and more than one attacker cluster was targeting the plications for normal users in general. For instance, due to
same victim. We found only one case where bot contract multiple attackers trying to frontrun other attackers via gas
0xDd9fd6b6F8f7ea932997992bbE67EabB3e316f3C started price auctions, they temporarily push the average gas prices of
an attack interrupting another attack from bot contract the network and force users that do not engage in frontrunning
0xd037763925C23f5Ba592A8b2F4910D051a57A9e3 target- to either pay higher transaction fees or wait longer for their
ing Last Winner on block 6,232,122. transactions to be mined. This becomes a vicious circle where
once again the miners profit from the fact that benign users
have to pay higher transaction fees for their transactions to be
6 Discussion mined. Thus, the more attackers engage in frontrunning, the
more it will have an impact on benign users. Another issue is
In this section, we discuss the implications of frontrunning suppression, which prevents blocks to be used or filled in an
and why existing mitigation techniques are not effective. optimal way. Ethereum already struggles with a low transac-
tion throughput [19] and suppression attacks only amplify the
6.1 Implications of Frontrunning issue. Suppression attacks can cause the network to congest
and decentralized applications to stop working properly.
Daian et al. [9] emphasize that miners could engage in front-
running activities to maximize or increase their profits. This
will most likely be the case when EIP-2878 becomes accepted 6.2 Limitations of Existing Mitigations
and the current static block award drops from 2 ETH to 0.5
ETH [20]. However, at the moment miners are already prof- There are currently two main reasons why frontrunning is con-
iting indirectly from frontrunning activities performed by ceivable on public blockchains such as Ethereum. The first
non-miners, since the high gas prices that those non-miners reason is the lack of transaction confidentiality. Every node in

12
the network, not just miners, can observe all the transactions miner extractable value. The mix of these two factors leads to
in the clear before they are mined. The fact that transactions new security threats to the consensus-layer itself, independent
are transparent to everyone is undoubted one of the major of already existing ones [4, 13]. However, the authors only
advantages of a public blockchain, however the content and focused on detecting frontrunning on DEXes and in real time,
purpose of a transaction should only be visible to everyone without scanning the entire blockchain history for evidence
once it has been mined. The second reason is the miner’s abil- of frontrunning. Our work builds on the taxonomy defined by
ity to arbitrarily order transactions. This puts a lot of power Eskandari et al. [12], which introduces three different types
into the hands of miners. Miners can decide to censor transac- of frontrunning: displacement, insertion, and suppression. De-
tions or change the order of transactions such that they make spite illustrating a few concrete examples and discussing sev-
the most profit. The idea to order transactions based on the eral mitigation techniques, the authors did not analyze the
gas price sounds rational at first, however this also introduces prevalence of frontrunning attacks in the wild. Zhou et al. [31]
determinism in a way that can be manipulated by outsiders. A estimated the potential effect of frontrunning on DEXes but
suitable mitigation technique must address these two issues, limited their analysis only to insertion attacks on a single ex-
but it must also be efficient in terms of costs for the users, pro- change. Their study estimated the theoretical profit that could
vide fair incentives for miners to continue mining transactions, have been made if users would have engaged in fruntrunning
and be adoptable by everyone and not just by a special group attacks, but did not back their conclusion with real observed
of participants. In our study, we observed that most frontrun- data. Compared to their work, we perform real world mea-
ning is happening on DEXes, since the risk of failure is low surements not only for insertion attacks, but for the complete
compared to the amount of profit that can be made. Uniswap, spectre of attack types (i.e., displacement, insertion, and sup-
the DEX most affected by frontrunning, is aware of the fron- pression). Besides studying frontrunning, a few mitigation
trunning issue and proposes a slippage tolerance parameter techniques have also been proposed to counter frontrunning.
that defines how distant the price of a trade can be before and For instance, Kelkar et al. proposed a consensus protocol to
after execution. The higher the tolerance, the more likely the achieve transaction order-fairness [17]. Breidenbach et al. [5]
transaction will go through, but also the easier it will be for an proposed LibSubmarine [7], an advanced commit-and-reveal
attacker to frontrun the transaction. The lower the tolerance, scheme to fight frontrunning at the application layer. Bentov
the more likely the transaction will not go through, but also et al. [2] present T ESSERACT, an exchange that is resistant to
the more difficult it will be for an attacker to frontrun the frontrunning by leveraging a trusted execution environment.
transaction. As a result, Uniswap’s users find themselves in a Finally, Kokoris et al. [18] describe C ALYPSO, a blockchain
dilemma. Uniswap suggests by default a slippage tolerance of that is resistant to frontrunning due to private transactions. Un-
0.5% in order to minimize the likelihood that users become fortunately, none of these techniques are broadly adopted as
victims of frontrunning. However, in this work we prove that they are either not compatible with the Ethereum blockchain
the slippage tolerance does not work as we measured over or because they are too costly. Another important side-effect
180K attacks against Uniswap. Hence, other mitigations to of decentralized finance is the emergence of flash loans [28].
counter frontrunning are needed. Bentov et al. [2] present Wang et al. [27] discuss a methodology to detect flash loans
T ESSERACT, an exchange that is resistant to frontrunning by using specific patterns and heuristics. We leave it to future
leveraging a trusted execution environment. However, their work to study the implications of flash loans in the context of
design follows a centralized approach and requires users to frontrunning.
have hardware support for trusted execution. Breidenbach et
al. [5] proposed LibSubmarine [7], an enhanced commit-and-
8 Conclusion
reveal scheme to fight frontrunning. However, in the case of
Uniswap, LibSubmarine would require three transactions to In this work, we investigated the prevalence of frontrunning
perform a single trade, making it cumbersome and relatively attacks in Ethereum. To the best of our knowledge, we are the
expensive for users to trade. first to present a methodology to efficiently measure the three
different types of frontrunning attacks: displacement, inser-
7 Related Work tion, and suppression. We performed a large-scale analysis on
the Ethereum blockchain and identified 199,725 attacks with
Daian et al. researched frontrunning attacks from an economi- an accumulated profit of over 18.41M USD for the attackers.
cal point of view by studying gas price auctions [9]. Moreover, We also discussed implications of frontrunning and found
by modeling actions of bots using game theory, and framing that miners profit from frontrunning practices. We found that
the problems in terms of a Nash equilibrium for two compet- miners already made a profit of more than 300K USD from
ing agents, the authors demonstrated that DEXes are severely transaction fees payed by frontrunners. We hope that we shed
impacted by two main factors: the high latency required to val- with this work some light on the predators of Ethereum’s
idate transactions, which opens the door to timing attacks, and dark forest by providing evidence that frontrunning is both,
secondly the miner driven transaction prioritization based on lucrative and a prevalent issue.

13
Acknowledgments [11] Sirer Emin, Gün and Daian Phil. Bancor Is Flawed.
https://hackingdistributed.com/2017/06/19/bancor-is-
We thankfully acknowledge the support from the RIPPLE Uni- flawed. Accessed: 2021-01-29.
versity Blockchain Research Initiative (UBRI). In addition,
this work was partly supported by the Luxembourg National [12] Shayan Eskandari, Seyedehmahsa Moosavi, and Jeremy
Research Fund (FNR) under grant 13192291. Clark. SoK: Transparent Dishonesty: Front-Running
Attacks on Blockchain. In International Conference
on Financial Cryptography and Data Security, pages
References 170–189. Springer, 2019.
[1] 1inch. 1inch introduces Chi Gastoken. https://1inch- [13] Ittay Eyal and Emin Gün Sirer. Majority is not enough:
exchange.medium.com/1inch-introduces-chi-gastoken- Bitcoin mining is vulnerable. In International confer-
d0bd5bb0f92b, 2020. Accessed: 2021-01-31. ence on financial cryptography and data security, pages
436–454. Springer, 2014.
[2] Iddo Bentov, Yan Ji, Fan Zhang, Lorenz Breidenbach,
Philip Daian, and Ari Juels. Tesseract: Real-time cryp- [14] Ethereum Foundation. Ethereum Wiki – Mining Re-
tocurrency exchange using trusted hardware. In Proceed- wards. . Accessed: 2021-02-02.
ings of the 2019 ACM SIGSAC Conference on Computer
and Communications Security, pages 1521–1538, 2019. [15] William Foxley. DeFi Has a Front-Running Prob-
lem. Sparkpool’s Potential Fix Is Launching This
[3] Burton H Bloom. Space/Time Trade-Offs in Hash Cod-
Month. https://www.coindesk.com/sparkpool-taichi-
ing with Allowable Errors. Communications of the ACM,
mining-network-front-running-defi. Accessed: 2021-
pages 422–426, 1970.
01-29.
[4] Joseph Bonneau. Why buy when you can rent? In
[16] William Foxley. Ethereum Miners Earned Record
International Conference on Financial Cryptography
$830M in January. , 2021. Accessed: 2021-02-02.
and Data Security, pages 19–26. Springer, 2016.

[5] Lorenz Breidenbach, Phil Daian, Florian Tramèr, and [17] Mahimna Kelkar, Fan Zhang, Steven Goldfeder, and Ari
Ari Juels. Enter the hydra: Towards principled bug Juels. Order-fairness for byzantine consensus. In Annual
bounties and exploit-resistant smart contracts. In 27th International Cryptology Conference, pages 451–480.
USENIX Security Symposium (USENIX Security 18), Springer, 2020.
pages 1335–1352, 2018.
[18] Eleftherios Kokoris-Kogias, Enis Ceyhun Alp, Linus
[6] Lorenz Breidenbach, Phil Daian, and Florian Tramèr. Gasser, Philipp Jovanovic, Ewa Syta, and Bryan Ford.
GasToken.io. https://gastoken.io, 2018. Accessed: 2021- Calypso: Private data management for decentralized
01-31. ledgers. Technical report, Cryptology ePrint Archive,
Report 2018/209., 2018.
[7] Lorenz Breidenbach, Tyler Kell, Stephane Gosselin,
and Shayan Eskandari. LibSubmarine – Defeat Front- [19] Kenny L. The Blockchain Scalability Problem & the
Running on Ethereum. https://libsubmarine.org/, 2018. Race for Visa-Like Transaction Speed. , 2019. Accessed:
Accessed: 2021-01-31. 2021-02-02.

[8] Bill Cheswick. An Evening with Berferd in which a [20] John Lilic. EIP-2878 – Block Reward Reduction to 0.5
cracker is Lured, Endured, and Studied. In In Proc. ETH. , 2020. Accessed: 2021-02-02.
Winter USENIX Conference, pages 163–174, 1992.
[21] Alex Manuskin. Ethology: A Safari Tour in Ethereum’s
[9] Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Dark Forest. https://zengo.com/ethology-a-safari-tour-
Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and in-ethereums-dark-forest. Accessed: 2021-01-29.
Ari Juels. Flash Boys 2.0: Frontrunning, Transaction
Reordering, and Consensus Instability in Decentralized [22] Naz. How to Front-run in Ethreum.
Exchanges. arXiv preprint arXiv:1904.05234, 2019. https://nazariyv.medium.com/crypto-front-running-for-
dummies-bed2d4682db0. Accessed: 2021-01-29.
[10] Robinson Dan and Konstantopoulos
Georgios. Ethereum is a Dark Forest. [23] Jonathan Otto. Arbitraging Uniswap and SushiSwap in
https://medium.com/@danrobinson/ethereum-is- Node.js. https://messari.io/article/arbitraging-uniswap-
a-dark-forest-ecc5f0505dff. Accessed: 2021-01-29. and-sushiswap-in-node-js. Accessed: 2021-01-29.

14
[24] SAMCZSUN. Escaping the Dark Forest.
https://samczsun.com/escaping-the-dark-forest.
Accessed: 2021-01-29.
[25] Nick Szabo. Formalizing and Securing Relationships
on Public Networks. First Monday, 2(9), 1997.

[26] Zack Voell. Decentralized Exchange Vol-

umes Up 70 percent in June, Pass 1.5B.
https://www.coindesk.com/decentralized-exchange-
volumes-up-70-in-june-pass-1-5-billion/. Accessed:
2021-01-30.

[27] Dabao Wang, Siwei Wu, Ziling Lin, Lei Wu, Xingliang
Yuan, Yajin Zhou, Haoyu Wang, and Kui Ren. Towards
Understanding Flash Loan and its Applications in DeFi
Ecosystem. arXiv preprint arXiv:2010.12252, 2020.
[28] Sam M Werner, Daniel Perez, Lewis Gudgeon, Ariah
Klages-Mundt, Dominik Harz, and William J Knotten-
belt. SoK: Decentralized Finance (DeFi). arXiv preprint
arXiv:2101.08778, 2021.
[29] Gavin Wood. Ethereum: A secure decentralised gen-
eralised transaction ledger. Ethereum Project - Yellow
Paper, 151(2014):1–32, 2014.
[30] Gavin Wood. Solidity 0.8.1 documentation.
https://docs.soliditylang.org/en/v0.8.1, 2021. Ac-
cessed: 2021-01-31.
[31] Liyi Zhou, Kaihua Qin, Christof Ferreira Torres, Duc V
Le, and Arthur Gervais. High-frequency trading on
decentralized on-chain exchanges. arXiv preprint
arXiv:2009.14021, 2020.

15