A2MM: Mitigating Frontrunning, Transaction Reordering and Consensus Instability in Decentralized Exchanges

06/14/2021 ∙ by Liyi Zhou, et al. ∙ 0

The asset trading volume on blockchain-based exchanges (DEX) increased substantially since the advent of Automated Market Makers (AMM). Yet, AMMs and their forks compete on the same blockchain, incurring unnecessary network and block-space overhead, by attracting sandwich attackers and arbitrage competitions. Moreover, conceptually speaking, a blockchain is one database, and we find little reason to partition this database into multiple competing exchanges, which then necessarily require price synchronization through arbitrage. This paper shows that DEX arbitrage and trade routing among similar AMMs can be performed efficiently and atomically on-chain within smart contracts. These insights lead us to create a new AMM design, an Automated Arbitrage Market Maker, short A2MM DEX. A2MM aims to unite multiple AMMs to reduce overheads, costs and increase blockchain security. With respect to Miner Extractable Value (MEV), A2MM serves as a decentralized design for users to atomically collect MEV, mitigating the dangers of centralized MEV relay services. We show that A2MM offers essential security benefits. First, A2MM strengthens the blockchain consensus security by mitigating the competitive exploitation of MEV, therefore reducing the risks of consensus forks. A2MM reduces the network layer overhead of competitive transactions, improves network propagation, leading to less stale blocks and better blockchain security. Through trade routing, A2MM reduces the predatory risks of sandwich attacks by taking advantage of the minimum profitable victim input. A2MM also offers financial benefits to traders. Failed swap transactions from competitive trading occupy valuable block space, implying an upward pressure on transaction fees. Our evaluations shows that A2MM frees up 32.8 transactions. In expectation, A2MM's revenue allows to reduce swap fees by 90



There are no comments yet.


page 1

page 2

page 5

page 6

page 11

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Permissionless blockchains have portrayed their full strength when mediating financial assets among parties within censorship-resilient on-chain exchanges. One of the most popular exchange models is the Automated Market Maker [hertzog2017bancor], where a smart contract autonomously adjusts the price for supply and demand upon incoming trading requests.

In a perfect world, different financial exchanges would all offer the same price for the same asset at the same time — i.e., the exchanges should be perfectly synchronized. In reality, however, competing exchanges must necessarily synchronize their asset prices. High-frequency arbitrage bots are known to conduct transaction fee bidding contests, both on the blockchain’s P2P network and on the consensus layer [daian2019flash, zhou2021just, zhou2020high]. Transaction fee bidding obstructs the available bandwidth on the blockchain’s P2P network [daian2019flash], therefore hinders information propagation and hence negatively influences blockchain security [gervais2015tampering]. MEV was also shown to incentivize miners to fork the chain. For example, a small rational miner with only % hashrate, will fork the Ethereum blockchain given an MEV opportunity yielding the block reward [zhou2021just].

This paper proposes a new type of AMM design, so-called Automated Arbitrage Market Maker, or AMM, which by design performs optimal trade routing and best-effort two-point arbitrage (cf. Figure 1) among peered AMMs. AMM offers various security benefits for the underlying blockchain. First, AMM atomically extracts two-point arbitrage MEV from the peered AMMs, which would otherwise deteriorate the blockchain’s security [zhou2021just]. Second, through swap routing, AMM reduces the risks of sandwich attacks due to the minimum profitable victim input (MVI) [zhou2020high]. Third, AMM deters competitive network layer bidding, freeing the available blockchain network layer bandwidth, reducing the stale block rate and ultimately strengthening blockchain security [gervais2016security].

Fig. 1: AMM design, which peers with two AMMs using their liquidity pools. When AMM receives a swap transaction for a market with the assets X and Y, AMM atomically performs optimal routing and arbitrage among the considered AMM, minimizing subsequent arbitrage transactions.

AMM also offers financial benefits to its users. Routing grants traders better asset prices, and arbitrage can yield positive income. Contrary to centralized MEV relayer, which auctions off MEV extraction111e.g., https://github.com/flashbots/mev-relay-js, AMM is a decentralized and trustless design allowing users to atomically benefit from MEV, while mitigating its negative consequences. One drawback of AMM is that the added smart contract logic necessarily increases the transaction fees for swaps. Our evaluation of AMM with two AMMs (cf. Figure 1), however, shows that AMM’s routing and arbitrage in expectation allow to reduce transaction fees by  compared to a standard AMM swap.

One Blockchain — One AMM

The AMM design space is without a doubt considerable and multi-dimensional [xu2021sok]. Related works have for example explored the various implications of differing AMM pricing formulas [uniswap, balancerexchange, egorov2019stableswap]. Orthogonal to the pricing formula design space, we would like to propose an intuition of how multiple AMMs on the same blockchain can be positively united.

Conceptually speaking, a blockchain is a distributed database, where each blockchain node aims to maintain the same view as the remaining network. If we compare a blockchain to a centralized exchange, which must also maintain its proprietary non-distributed database, then there is little reason to split such a database into multiple competing partitions, which necessarily require synchronization through price arbitrage. We therefore observe the following: (i) multiple DEXes dilute the financial liquidity in each DEX and result in less attractive asset pricing. (ii) multiple DEXes must synchronize through arbitrage, which causes overhead on the blockchain database and the network layer. From a security and financial perspective, it therefore appears to be strictly disadvantageous to deploy multiple DEXes on the same blockchain.222There may be social, competitive, and egocentric reasons for the deployment of competing DEXes (e.g., to sell a token), which we, however, do not further investigate in this work. In this work, we take the stance that a blockchain should ideally only operate one AMM smart contract, to increase the financial efficiency, reduce network layer and block-space overhead, and consequently increase blockchain throughput as well as security.

Fig. 2: Decision tree whether a swap would introduce overhead in terms of the P2P network layer or block space.

We motivate our stance through an AMM swap decision tree in Figure 2. The decision tree departs from a possible AMM state where multiple exchanges on an identical blockchain have the same price for the same asset markets, i.e., the exchange prices are levelled. Then, a user performs a swap on one of the AMM exchanges, which would necessarily depart the AMMs state from their price equilibrium. Given optimal sandwich attack parameters [zhou2020high], we can determine whether the swap can be attacked through a sandwich attack. If the swap is not sandwichable, we find whether the AMMs can reach price equilibrium through optimal asset routing. If routing alone cannot level the prices on the different AMM markets, we can resort to arbitrage. If arbitrage can be performed atomically within the swap, we do not anticipate further overhead from the incoming swap, hence securing the blockchain from possible MEV extraction. In all other cases, there exist the likely introduction of overhead deteriorating the blockchain security, reducing its throughput and increasing transaction fees.

We summarize our main contributions in the following.

AMM Design:

We provide a new AMM design, AMM, which atomically performs optimal swap routing as well as efficient arbitrage among existing AMM liquidity pools, if deemed profitable by the AMM smart contract. Our design does not change the simple usability aspects of existing AMMs, yet allows any user to profit from atomic routing and arbitrage.

AMM Strengthens Blockchain Security:

MEV is a design problem threatening blockchain security [qin2021quantifying, zhou2021just]. AMM mitigates two MEV sources, namely two-point arbitrages and sandwich attacks. We show that adopting an AMM design reduces both block-space and network layer overhead caused by MEV bots, therefore, strengthening the blockchain consensus by reducing the stale block rate. We find that of the back-running arbitrage transactions are accompanied by what we call back-run flooding (BRF), an observed denial of service practice on the blockchain P2P layer.


We implement and evaluate AMM as shown in Figure 1, while synchronizing with two AMMs (i.e., Uni- and Sushiswap). By replaying past blockchain data, through routing and arbitrage revenue, on average, we find that AMM reduces the consumed transaction fees of a standard AMM swap by . Moreover, in expectation, AMM reduces the consumed block-space by .

The remainder of the paper is organized as follows. Section II provides a background, while Section III introduces our system and threat model and outlines the AMM design. Section IV presents our evaluation and empirical results. We highlight AMM’s security implications in Section V and shed light on the cost when AMM peers with more than two AMMs in Section VI. We summarize related works in Section VII, provide a discussion in Section VIII and conclude the paper in Section IX.

Ii Decentralized Finance (DeFi)

Since the inception of permissionless blockchains with Bitcoin in 2008 [bitcoin], it became apparent that their most well-suited use case is the transfer or trade of financial assets without trusted intermediaries [wust2018you]. A blockchain is considered permissionless when entities can join and leave the network at any point in time. Users authorize transactions through a public key signature and a subsequent broadcast on the blockchain P2P network. The formatted public key corresponds to an address that a user can receive assets at. Miners accumulate transactions and solve a proof of work (PoW) puzzle to append a block to the blockchain (various alternatives to PoW emerged, such as PoS [saleh2021blockchain, bano2019sok]). Miners are financially rewarded for performing work for the network through block rewards and transaction fees. A third miner reward source, which is gaining traction [qin2021quantifying], is the extraction of Miner Extractable Value. While Bitcoin supports basic smart contracts through a stack-based programming language, the support for loops and higher-level languages (such as Solidity) have gained widespread adoption. For a more thorough blockchain background, we refer the reader to several helpful SoKs [bonneau2015sok, atzei2017survey, bano2017consensus].

Smart contracts provide the building blocks for an ecosystem of decentralized finance [schar2020decentralized], where users can interact with lending pools, AMM exchanges, stablecoins, derivatives, asset management platforms etc. At the time of writing, DeFi has grown to an accumulative locked value of over USD. For a more thorough background on DeFi, we refer the interested reader to an SoK [schar2020decentralized]. We proceed to separate the background into a finance- and security-related overview.

Ii-a Finance Background

Market Maker: Market makers (MM) help the market (i.e., the traders buying and selling assets) having access to sufficient liquidity (i.e., monetary asset amounts) for buy/sell orders to match at the ask/bid price. Traditionally, market makers are incentivized to operate as they can profit from the spread (i.e., the difference) between the bid and ask prices.

Automated Market Maker Exchanges: AMMs govern through smart contracts a pool of assets, where a pricing formula defines the asset purchase and sell price. Several AMM pricing formulas are proposed in the literature; the most popular form is the constant product AMM [hertzog2017bancor]. While Bancor introduced the AMM concept, at the time of writing, Uniswap [uniswap] is the most prominent AMM with a daily trading volume of over USD and USD of the total supplied liquidity among different asset pairs333https://info.uniswap.org/. One of the better-known forks of Uniswap is Sushiswap [sushiswap].

Arbitrage: The process of selling/buying an asset in one market while concurrently buying/selling in another market at a different price is known as arbitrage. Arbitrage encourages economic stability and is generally regarded as benign. DeFi traders/miners track new blockchain state changes and conduct arbitrage if the anticipated revenue from synchronizing two markets exceeds the expected transaction costs. To perform arbitrage, a trader may operate on the previous block state or on the state of the pool of unconfirmed transactions (i.e. the mempool) [qin2021quantifying].

Slippage: The adjustment in the price of an asset during a transaction is known as price slippage. Expected price slippage is the anticipated rise or decrease in price depending on the amount to be exchanged and the available liquidity [zhou2020high]. The expected slippage increases as trading volume increases. Unexpected price slippage is the rise or decrease in price during the interim time between creating a transaction and its execution. The sum of the expected and unexpected slippage represents the price impact of a trade.

Swap Routing Aggregators: An exchange aggregator is a service to aggregate liquidity from multiple exchanges. Aggregators may split a single trade into numerous smaller transactions to receive the best overall trade price. The sub-trades are then routed to various exchanges to provide the best exchange price and minimize the trading slippage. In March 2021, the three most significant off-chain aggregators (1inch, Mocha, and Paraswap) amassed a total monthly volume of  USD 444https://www.theblockcrypto.com/data/decentralized-finance/dex-non-custodial/dex-aggregator-trade-volume. Off-chain aggregators are not guaranteed to yield optimal execution parameters due to the unexpected slippage. To the best of our knowledge, off-chain aggregators also do not perform arbitrage.

Flash Loans: Atomic blockchain transactions may execute several actions in a rigorous sequence. If a single transaction fails in one of its execution steps, the entire transaction fails atomically and does not alter the blockchain state. This atomicity property enables a novel financial product, flash loans. Flash loans are loans drawn from a smart contract pool of assets and are only valid within one atomic transaction. The flash loan must be paid back by the end of the transaction; otherwise, the loan fails. When a flash loan fails, the blockchain state is not modified, corresponding to a state where the loan was never granted to the borrower. Because lenders bear no risks by the borrowers defaulting on the loan, flash loans quickly grow to billions of USD [qin2020attacking].

Ii-B Security Background

Front- and Back-running: is the process by which an adversary observes a victim’s pending transaction on the network layer and then acts upon this information by placing trades before or after the victim’s transaction. While custodian and centralized financial services are known to be under the supervision of regulatory bodies [finma-ban], DeFi (and blockchain) are not yet thoroughly regulated. Previous studies have observed front-running bidding wars between DEX arbitrage bots [daian2019flash, qin2021quantifying]. Transaction fee bidding causes on-chain congestion and introduces network layer overhead, which necessarily increases the stale block rate and hence weakens the consensus security of the underlying blockchain [gervais2016security].

Sandwich Attack: A sandwich attack is a predatory trading strategy, which exploits a pending, not yet executed trade [zhou2020high]. Suppose an asset’s price is expected to rise/fall due to a pending trade. In that case, a malicious front-runner can buy/sell the asset before the victim transaction executes and then close its position by selling/buying the same asset after the victim transaction is confirmed. Because AMMs provide complete transparency about the exchange’s state and the pricing formula, sandwich attackers can derive the optimal attack parameters. Previous works investigate AMM-specific mitigations and find that sandwich attacks are not profitable if the victim’s input amount remains below a safe, market-state-specific threshold.

Miner Extractable Value: Miners retain the authority to decide on the transaction order of their mined blocks. Miners observe pending transactions on the network layer and may maximize their revenue through the optimal transaction order. For instance, the miners can perform front-running or sandwich attacks [zhou2020high]. The term “Miner Extractable Value” or MEV [daian2019flash], refers to the entire potential revenue that miners can extract through transaction order manipulation. Related work quantified that at least  USD in profit was extracted over two years following the st December  [qin2021quantifying]. Because non-MEV miners order by default transactions in descending transaction fee (gas price) amount [zhou2020high], a non-mining trader can also capture MEV by adjusting their transaction fees. Related work, for example, shows how trading bots engage in competitive transaction fee bidding contests [qin2021quantifying].

Stale Block Rate: Previous works have extensively shown that blockchain forks increase the stale block rate and deteriorate the consensus security by increasing the risks of double-spending and selfish mining [gervais2016security, eyal2014majority, bonneau2016buy]. Zhou et al.  [zhou2021just] quantified an MEV threshold at which MEV-aware miners are incentivized to fork the blockchain. For instance, on Ethereum, a miner with a hash rate of would fork the blockchain if an MEV opportunity exceeds × the block reward. Because arbitrage is one of the prime sources of MEV, it is therefore of utmost importance to minimize the need for arbitrage to increase blockchain security.

Ii-C AMM Arbitrage

We outline the traditional AMM design coupled with the necessary third-party arbitrageurs in Figure 3. This AMM design necessarily requires at least two separate transactions, and to synchronize the prices on AMM1 and AMM2 after the swap. Moreover, because and are non-atomic (i.e., do not necessarily execute in succession), multiple arbitrageurs, as well as miners, are likely to compete over benefiting from the created arbitrage opportunity [daian2019flash].

Fig. 3: Overview of the back-running arbitrage process in AMM exchanges. The liquidity taker initiates a swap on AMM1 by broadcasting its transaction () on the P2P network. An arbitrageur listens on the public P2P network and observes . The arbitrageur then issues a back-running arbitrage transaction (), if creates a profitable arbitrage opportunity between AMM1 and AMM2. Note that miners can collude with arbitrageurs to extract profits without failure risks.

Ii-D Off-chain AMM routing

Off-chain swap routing services calculate the best routing path and parameters based on their local blockchain state (cf. Figure 4). Off-chain routing avoids complex smart contract operations, thereby minimizing transaction costs. However, off-chain routing paths and parameters are not necessarily optimal during execution, because the blockchain state might change intermittently between route generation and execution. To mitigate this problem, aggregators (such as 1inch) cooperate with miners on privately mined transactions, which arguably renders DeFi more centralized [1inch-frontrunning, qin2021quantifying]. Moreover, the goal of routing is to only optimize the liquidity takers’ swap transactions, while forgoing possible arbitrage opportunities between other AMM exchanges.

Fig. 4: Off-chain routing aggregator. Upon (0) incoming swap, the routing service calculates (1) optimal paths and trading parameters given a blockchain state. The routing service (2) issues the transaction () on the P2P network. An arbitrageur (3) observes , and another swap (). The arbitrageur then (4) performs a back-running arbitrage (). Because the transaction order execution is not guaranteed off-chain routing paths and parameters may be suboptimal.

Iii AMm

We proceed to introduce the AMM design, system, threat, and state transition model by adding arbitrage actions on top of a known AMM model [zhou2020high]. Note that we only study two-point arbitrages, and we, therefore, focus on markets with two assets in the following.

Iii-a System Model

We consider a blockchain P2P network, where traders interact with AMMs by signing transactions with their respective private keys. For example, traders can exchange cryptocurrency assets, deposit/withdraw assets to/from different exchange pools, perform arbitrages, etc. Traders can freely adjust the parameters of these transactions, such as the transaction fees (e.g., gas price), slippage limit, expiration time, etc. A trader then broadcasts a transaction on the asynchronous blockchain peer-to-peer (P2P) network [decker2013information, kim2018measuring, kifferunder], or may privately send transactions to miners [zhou2020high]. The transaction propagation typically utilizes gossip or publish-subscribe mechanisms, and nodes (including miners) may have different views of the pending (i.e., unconfirmed) transactions stored in the mempool. By default, miners order transactions according to the paid transaction fees but were also shown to adhere to private ordering policies [qin2021quantifying].

Iii-B Threat Model

We do not constrain the mining behavior of the miners but assume that no miner can accumulate more than 33% of the total hash-rate [eyal2014majority]. Miners can manipulate transaction ordering by transparently ignoring the default transaction ordering rules (i.e., highest-priced transactions first) or by attempting to hide private agreements by pretending to participate in transaction fee bidding contests [qin2021quantifying]. We assume that smart contracts are secure and free from vulnerabilities.

Iii-C AMM State Transition

We follow the standard model for AMM exchanges [zhou2020high]. An AMM consists of mainly two types of traders, namely the liquidity providers and liquidity takers. A liquidity taker buys or sells an asset in exchange for another asset, using the liquidity providers’ disposable assets.

[title = AMM State,arc=0pt,outer arc=0pt]

Definition III.1.

The state (or depth) of an AMM market with two assets and is defined as . The sum of and correspond the total amount of assets from and deposited by liquidity providers.

Two-asset AMMs typically support the following two-state transition functions for liquidity takers to convert between asset X and Y.

  1. Swapto: A liquidity taker can trade of asset , increasing the available liquidity of asset , in exchange for of asset , decreasing the available liquidity of asset (cf. Equation 1).

  2. Swapto: The mirroring action for Swapto.

Note that both Swapto and Swapto use a pricing function to determine the maximum amount of asset the taker can receive. Each AMM exchange may choose a custom pricing function for governing the asset exchange. A liquidity taker can exchange amount of asset for up to amount of asset , while choosing to withdraw fewer assets voluntarily.

[title=Pricing Formula,arc=0pt,outer arc=0pt]

Definition III.2.

A pricing formula is a differentiable function , which maps the AMM state () and input amount () of asset to the best exchange rate the AMM offers.

Assumptions: We assume that the AMMs we consider abide by the following properties.

[title=Liquidity Sensitivity,arc=0pt,outer arc=0pt]

Property 1.

Given an AMM state , the price decreases as the trade size () increases. Similarly, the price decreases as the trade size () increases.

Liquidity sensitivity (cf. Property 1) enables the underlying AMM market to adjust autonomously the price based on the trading volume and direction. The more asset a liquidity taker purchases from an AMM, the more scarce becomes in the liquidity pool, and therefore the price of increases relative to (and vice versa). Property 1 implies that the pricing functions are monotonically decreasing as the trade volume increases.

[title=Path Independence,arc=0pt,outer arc=0pt]

Property 2.

Given an inital market state , the following sub-properties holds:

  1. Two consecutive Swapto transactions, respectively swapping asset to asset , are equivalent to one Swapto transactions, swapping asset to asset .

  2. Two consecutive transactions, swapping asset to asset (Swapto) followed with asset back to asset (Swapto), where , are equivalent to one Swapto transaction, swapping asset for asset .

Path Independence is a desirable AMM property because it ensures that liquidity takers have no incentive to split a trade into multiple smaller transactions on the same AMM market. Note that when there exist numerous appropriate AMM markets, it can still be more profitable to split a trade and perform routing (cf. Section III-D).

[title=Market Independence,arc=0pt,outer arc=0pt]

Property 3.

Given two state transition actions on two different AMM markets, the execution order of these two transitions will not impact the final states of the two AMMs.

Property 2 and 3 are applied in the following to compress routing and arbitrage transactions in Section III-G. Note that the same AMM can have multiple markets trading the same asset pairs (), but we assume these markets to have different states. A state change on one market will hence not affect the state or price of another market.

Iii-D AMM Design

In the following section we describe the proposed AMM design (cf. Figure 1). On a high-level, AMM minimizes the arbitrage opportunities between itself and other AMM exchanges, after any AMM state transition (e.g., a swap, add or remove liquidity). Upon an incoming swap, the AMM first checks if the swap amount is sufficiently large to synchronize the prices on the considered AMMs, and then performs optimal routing (cf. Figure 5). Otherwise, AMM performs optimal routing and best-effort arbitrage among the considered AMMs. A flash loan can be requested if the swap’s trader holds an insufficient balance for arbitrage [qin2020attacking].

Fig. 5: Decision tree of the AMM exchange logic. AMM encourages first optimal routing, and if routing alone isn’t sufficient, best-effort arbitrage may synchronize the markets.

We assume that an AMM market () is synchronizing with other AMM markets. The state of the th () AMM market is denoted as . We formally introduce the state transitions for arbitrage and routing.

  1. ArbitrageFor: An arbitrageur can perform an arbitrage between two or multiple AMM exchanges. Given two AMMs with states and respectively. The trader initiates the arbitrage by swapping of for amount of on AMM . The arbitrageur then reverses the trade by exchanging amount of on AMM for amount of . If the arbitrage is successful, the arbitrageur gains amounts of (cf. Equation 2).

  2. ArbitrageFor: The mirroring action for ArbitrageFor.

  3. Routeto: When a liquidity taker swaps of asset for of asset , the taker can split its trade () across AMMs (cf. Equation 3).

  4. Routeto: The mirroring action for Routeto.


Iii-E Optimal On-Chain Swap Routing

AMM performs Routeto to maximize the amount of asset the liquidity taker purchases after paying . We proceed to formally define the optimal routing problem among AMMs.


[arc=0pt,outer arc=0pt]

Theorem 1.

Routing optimization aims to level the asset price on multiple AMMs and can be solved by greedily routing transaction volume.

PROOF BY CONTRADICTION: This proof shows that the optimal routing among N AMMs must greedily route transaction volume to the exchange with the best price (cf. Theorem 1). We assume the existence of an optimal routing strategy () for Routeto, which in total routes amount of asset to amount of asset . More specifically, this optimal strategy routes of asset to N AMMs, in exchange of of asset (, ). After the routing, we assume that AMM 2 still offers a better price than AMM 1, meaning that contradicts Theorem 1 and does not route all trading volume greedily to the AMM with the best price. Equation 5 shows the state transition process.


To prove that is not the optimal routing strategy, we show that the routing can output more asset if more trading volume is routed to AMM 2, without changing the routing strategy for AMM 3 to N. We denote this alternative strategy as , which routes of asset to AMMs 1 and 2 respectively. AMM 2 still offers a better price for swapto after executing , because the additionally routed amount () is arbitrarily small and is a continuous function. Equation 6 shows the state transition process for .


Based on the liquidity sensitivity property (Property 1), AMM 2 offers a worse price for Swapto after executing compared to executing (cf. Equation 7). This is because routes more trade volume to AMM 2, where both strategies have the same initial state for AMM 2 .


In Equation 8 we derive that the amount of asset outputs is greater than using the path independence property (cf. Property 2), which contradicts the assumption that is the optimal routing strategy. Theorem 1 is therefore proven by contradiction.


Iii-F Arbitrage Profit Maximization

In the following, we formally introduce the arbitrage profit maximization problem between AMMs. An arbitrage between multiple DEXes may include multiple sub-arbitrage steps. Given an arbitrage strategy with steps, we use the superscript, such as , , to denote the state and parameters at a sub-step , where . The objective of the arbitrageur is to maximize the revenue after executing all sub-arbitrage steps (cf. Equation 9). Because the solution of Equation 9 depends on the implementation-specific AMM pricing formulas for the AMMs, we do not provide a general solution here. The reader, however, can find an optimal solution for two AMMs with constant product pricing formula in Section B-B (corresponding to Uni- and Sushiswap capturing over  of the total AMM market trading volume at the time of writing555https://www.theblockcrypto.com/data/decentralized-finance/dex-non-custodial/dex-volume-monthly, accessed March 2021).


Iii-G Swap Compression

To minimize the required transaction fees of a swap, we show in the following how AMM compresses multiple transactions of an atomic swap (cf. Figure 6).

Fig. 6: Overview of the swap compression process.

[arc=0pt,outer arc=0pt]

Theorem 2.

An optimal strategy () performing routing and arbitrage among AMMs on market () is equivalent to a batch execution strategy (). consists of at most swaps (Swapto or Swapto). Both and change the states of AMMs from to .

PROOF: Both arbitrage and routing only consist of Swapto and Swapto transactions (cf. Equation 2 and 3). Because the AMMs are independent (cf. Property 3), these transactions can be reordered into groups, where each group only consists of transactions for the same market. We can then batch the transactions within each group based on the path independence property (Property 2).

Iii-H Limitations

In this work, we consider AMM in isolation from other exchanges on other blockchains or external centralized exchanges. However, asset prices realistically move outside of the regarded AMM, which may still create arbitrage opportunities, even if AMM minimizes required arbitrages among the synchronized AMMs. Moreover, the cost of price synchronization grows with the number of AMMs that AMM peers with and is therefore limited (cf. Section VI). While in this work we only consider AMM with similar pricing formulas, we believe that AMM is adoptable any AMM pricing formula, given the corresponding on-chain computation overhead.

Iv Evaluation

In our evaluation we rely on the blockchain states of Uni- and Sushiswap, two of the biggest on-chain DEXes capturing  of the market volume at the time of writing666https://www.theblockcrypto.com/data/decentralized-finance/dex-non-custodial/dex-volume-monthly, accessed March 2021. Therefore, our AMM implementation peers with two AMMs of the same pricing formula. In this scenario, the optimal strategy for both routing and arbitrage can be mathematically derived as we show in the appendix (cf. Section B). We use Uniswap as a pricing oracle to fetch the X/ETH prices for any arbitrary asset 777

To avoid overestimating the revenue, we estimate the ETH value of

amount of asset by simulating a Uni/Sushiswap trade, instead of relying on the spot price.. We assume that the X/ETH price is zero when we cannot determine the price, thus ignoring the corresponding transaction. We adopt a price of  USD/ETH as of April .

Iv-a Empirical Comparison of AMM and AMm

We perform an empirical comparison between AMM and AMM through concrete execution on past blockchain data. Our experimental setup corresponds to the system model in Figure 7, where we assume that we deploy an AMM contract with a user interface while using Uni- and Sushiswap’s liquidity pools. Upon receiving a swap request, AMM derives the routing and arbitrage parameters on the fly on-chain.

Fig. 7: System model of the AMM evaluation. We concretely execute on past blockchain data, and assume that AMM initially does not provide a liquidity pool and rather operates through Uni- and Sushiswap.

We implement AMM in 761 lines of code using Solidity v.8.2.0. The deployment of the AMM contract costs  gas ( ETH,  USD) at a gas price of  gWei. We crawl all asset swap transactions that are sent directly to Uni- or Sushiswap from block  ( September, ) to block  ( March, ) ( days). Note that AMM aims to reduce the number of two-point arbitrage and sandwich opportunities, where arbitrage and sandwich bots often use smart contract accounts. Because we assume that all AMM swaps initiate at the AMM’s user interface, we expect the number MEV related transactions to decrease. To avoid double-counting MEV transactions in our evaluation, we chose to only consider AMM swaps from non-smart contract accounts (i.e., EOA accounts).

Num. sub-swaps per swap Total
1. Swap
2. Swap + Routing - - - -
3. Swap + Arbitrage
TABLE I: Empirical transaction fee comparison between the AMM and AMM model. We consider three cases: (i) without routing/arbitrage (ii) with routing, and (iii) with arbitrage.

Transaction Fees When Peered With Two AMMs: AMM requires more computation for a single swap than a standard AMM, because AMM derives the routing and arbitrage parameters across AMMs on-chain. A natural question is how much more expensive AMM’s execution ends up when compared to an AMM, when it peers with Uni-/Sushiswap. Table I presents our concrete execution results. For a swap without arbitrage nor routing, we find that on average, liquidity takers pay  higher fees for a swap on AMM vs. AMM. For a swap with routing, we find that AMM requires an excess  in terms of transaction fees compared to the average transaction fee of an AMM swap. Finally, for a swap with routing and arbitrage, AMM’s excess in transaction fees amounts to . We estimate that the arbitrage action by itself costs .

Type Num. of Txs(%) Total Revenue Avg. Revenue Avg. AMM Fee Avg. Avg.
TABLE II: Revenue and cost of our concrete execution on past blockchain data, replaying previous Uni/Sushiswap transactions on AMM (i.e., the for Swapto remains unchanged, cf. Equation 1). We adopt a price of  USD/ETH as of April . Excess fee is the additional transaction fee AMM costs when compared with an AMM (i.e., ).

Extractable Arbitrage/Routing Revenue of AMM: In the following, we quantify the income potential from AMM’s design, as arbitrage is known to yield positive incoming from synchronizing prices. Routing provides better swap asset prices by sourcing several liquidity pools simultaneously. We proceed to measure both the positive income from arbitrage and the price advantage from routing, allowing us to offer an objective view of the costs of using AMM compared to an AMM.

Our results suggest (cf. Table II) that within  days of blockchain data, in total  () of the executed AMM transactions perform either arbitrage and/or routing, extracting a total of  ETH ( USD). Due to this positive income and the routing price advantage, in expectation, AMM reduces transaction fees by an average of  compared to a standard AMM swap.

Percentile 10 20 30 40 50 60 70 80 90
Profit(USD) -20.3 -9.9 -3.8 -1.8 -1.0 -0.4 0.4 4.3 31.0
TABLE III: Percentile analysis of individual swaps’ profit from our prototype implementation. We assume that traders pay the same transaction fee price (gas price) in our concrete execution. While only  of the swaps realize a positive profit, AMM in expectation provides a better price than an AMM.

Iv-B Two-point Arbitrage Overhead

While AMM only mitigates two-point arbitrage overhead, Qin et al.  [qin2021quantifying] show that historically  of the on-chain arbitrages are two-point arbitrages. Therefore, we estimate that AMM will decrease about  of the on-chain and network overhead caused by arbitrage bots, helping to reduce the stale block rate, thus increasing blockchain consensus security.

In the following, we quantify both the on-chain and network layer overhead for the past two-point arbitrages between Uni- and Sushiswap to test the above intuition.

Block-space Overhead Heuristics:

In the following we use to denote a block with height , and to denote a transaction mined within block at index . We use to denote the blockchain state after executing all transactions in block . We use the function to denote the blockchain state after iteratively applying transactions in the exact order on the blockchain state . In other words, if there are transactions in block , then . We use the function

to classify whether a transaction

successfully performs an arbitrage at blockchain state (cf. Section E in Appendix).

We classify transaction as an block-space overhead caused by front-/back-running arbitrages if Heuristic C1, and one of Heuristics C2a and C2b are satisfied.

Heuristic C1:

If transaction performs a successful arbitrage, then is not classified as an block-space overhead (cf. Equation 10).

Heuristic C2a (Front-running):

We test, if a re-positioning of as the first transaction in each of the previous five blocks (i.e. a -minute time window), would make a successful arbitrage transaction. This test allows us to classify whether is a failed front-running arbitrage overhead (cf. Equation 11).

Heuristic C2b (Back-running):

By iterating backwards through the transactions of the last  blocks, starting at ’s position, we sequentially interleave after each , and test through concrete execution, whether yields an arbitrage profit. This test allows us to identify whether a transaction attempted an arbitrage operation (cf. Equation 12).


Network Layer Overhead Heuristics: We classify a transaction as a network layer overhead targeting a successful arbitrage transaction , if the following three heuristics (N1, N2 and N3) are satisfied. Note that while a transaction may propagate on the P2P network, that transaction doesn’t necessarily appear in the blockchain. The helper function returns the time of a transaction or block’s first known appearance on the P2P network.

Heuristic N1:

N1 tests whether a transaction on the P2P layer is a failed arbitrage attempt. Given an identified successful on-chain arbitrage transaction , we replace iteratively with each transaction recorded by our P2P network node. If yields an arbitrage profit under concrete execution, we classify as a failed network layer arbitrage attempt, caused by either GPA or BRF.

Heuristics N2 and N3 attempt to narrow down the issuance time of an arbitrage transaction . If both the two tests in Heuristics N2 and N3 are satisfied, we then classify as a network layer overhead transaction targeting .

Heuristic N2:

N2 tests the lower time of appearance of an arbitrage attempt. We find the earliest appearance of all related transactions on the P2P network, such as: (i) the transaction that attempts to front-/back-run (denoted as ), and (ii) all failed block-space overhead transactions competing with (denoted as ). For each network layer overhead transaction , we test if is discovered after the earliest appearance of all related transactions on the P2P network (cf. Equation 13).

Heuristic N3:

N3 tests the upper time of appearance of an arbitrage attempt. For each network layer overhead transaction , we test if is discovered before is mined (cf. Equation 14).


Empirical Results: To quantify the amount of P2P network layer overhead caused by two-point arbitrages, we modify the Ethereum geth client to store all transactions received on the P2P network layer over  blocks ( days) from block  (Feb--) to block  (Mar--). Intuitively, the number of transactions the Ethereum node can observe increases with the number of peer connections, the network bandwidth, and the computation power of the machine. Our geth client operates on a Ubuntu  LTS machine with AMD Ryzen Threadripper  (-core,  GHz),  GB of RAM and  TB NVMe SSD in Raid  configuration. We limit the geth client to at most  connections with other Ethereum peers instead of the default of  peers (cf. Figure 8). We captured in total B transaction propagation messages from  unique peers originating from unique IP addresses and unique IP:Port combinations.

Fig. 8: Number of connections of our modified geth node while listening on the Ethereum P2P network from block  (Feb--) to block  (Mar--).
Position Front-running Back-running Total
Same block 13,460(73%) 117,728(90%) 131,188(88%)
After 1 block 2,876(16%) 7,657(6%) 10,533(7%)
After 2 blocks 909(5%) 2,118(2%) 3,027(2%)
After 3 blocks 465(3%) 1,353(1%) 1,818(1%)
After 4 blocks 419(2%) 860(1%) 1,279(1%)
After 5 blocks 268(1%) 775(1%) 1,043(1%)
TABLE IV: Statistics of the block-space overhead we detect. of the on-chain failed arbitrages are mined within block after the MEV arbitrage opportunity is extracted.
Fig. 9: For every two-point arbitrage opportunity on-chain, we correlate the accumulative overhead transactions propagated on the P2P network layer. We capture front- as well as back-running transactions, covering PGA and BRF.
Fig. 10: Cumulative weekly revenue of the AMM implementation extracted through arbitrage and routing based on concrete execution of past blockchain data.
Potential Freed up Block-Space by AMM

Given the heuristics C1 and C2, we identify in total  on-chain two-point arbitrage overhead transactions (cf. Table IV). Surprisingly, the majority are back-running arbitrage failures (). On average,  and  overhead transactions are mined on-chain for each front- and back-running opportunities, with an average gas cost of  K. As front-running arbitrageurs participate in PGA, front-runners pay a  premium average gas price compared to back-runners. We use Equation 15 to quantify AMM’s on-chain reduction over blocks ( days), where denotes the average on-chain space cost. We find that in expectation, AMM reduces the consumed block-space by .

Potential Network Overhead Reduced by AMM

Given the heuristics N1, N2 and N3, we identify  network overhead transactions, where the majority () are caused by back-running arbitrageurs. On average,  and  network overhead transactions are issued for every front-/back-running arbitrage opportunity, which corresponds to a factor of  more than the block-space overhead. When an arbitrage opportunity appears, we measure that the off-chain overhead transactions sum to an average of  kb per block, which is around  of a block’s size on the 1st of March 2021888https://etherscan.io/chart/blocksize.

Limitations: Our evaluation may consist of false negatives. For example, an overhead arbitrage transaction may be dropped in the asynchronous P2P network before reaching our network node. The blockchain overhead statistics we report should therefore only be regarded as a lower bound of the actual network overhead. Note that a transaction is only classified as an overhead, if it does perform a two-point arbitrage during concrete execution. Therefore, our overhead evaluation suffers from no false positives.

V Security Implications of AMm

In the following, we quantitatively outline the relevant security improvements AMM provides on the blockchain consensus.

V-a Stale Block Rate Simulation

This section simulates the P2P network of four blockchains (Ethereum, Bitcoin, Litecoin, and Dogecoin) to estimate quantitatively the relationship between the stale block rate and the miner bandwidth. To capture the block propagation in the P2P network, we extend our system model from Section III. The asynchronous nature of blockchain P2P propagation is extensively studied by related works [ersoy2018transaction, decker2013information, gervais2016security, gencer2018decentralization, zhou2020high], on which we build upon.

Various factors influence block propagation, including the number of miners, the network topology, the peer internet latency, bandwidth, and overall network congestion. To ease our experiments and operate under the best network connectivity, we assume that the miners create direct point-to-point relations among themselves. Consequently, the number of sporadic network nodes, the network topology, intermediate devices (relay nodes, switches, and routers), and the TCP congestion management are all abstracted. We approximate the block propagation duration by dividing the block size over the bandwidth and adding the communication latency. To parameterize a realistic block size distribution in our simulations, we assume that the block size follows a normal distribution, where the mean and variance are derived using 

days of blockchain data (cf. Table V) 999https://bitinfocharts.com, accessed Apr 2021. To capture latency distribution, we apply the mean percentile statistics [kim2018measuring, gencer2018decentralization, zhou2020high]

and use linear interpolation to estimate the underlying cumulative probability distribution (cf. Table 

IX in the Appendix). We only consider the hashing power of the top miners for each blockchain (cf. Table VIII in the Appendix), and assume that miners have a symmetrical upload and download bandwidth.

Ethereum Bitcoin Litecoin Dogecoin
Block interval (min) 0.223 9.474 2.59 1.07
Block size mean (kB) 44.0 863.8 61.1 15.9
Block size std (kB) 3.0 25.0 33.4 14.9
TABLE V: Blockchain parameters we use to simulate the P2P network for Ethereum, Bitcoin, Litecoin and Dogecoin. These statistics are measured using  days of blockchain data, from Jan-- to Apr--.
Fig. 11: Simulated stale block rate given the average P2P network bandwidth for Ethereum, Bitcoin, Litecoin and Dogecoin. We fit a least square regression line for Ethereum ().

MEV network overhead deteriorates the miners’ P2P bandwidth and hence increases the blockchain’s stale block rate. The most significant arbitrage back-running in terms of overhead we capture amounts to a total of  Mb data from repeated transactions within one block interval ( seconds). Note that the total amount of data miners receive is amplified as the number of connected peers increases. For instance, if miners have an initial upload and download speed of Mbit/s, and overhead transactions are propagated back and forth  times, the average bandwidth will decrease to Mbit/s 101010. Based on our nd degree least-square polynomial fitting, this decrease in bandwidth leads to a  increase in stale block rate (cf. Figure 11).

Note that miners have an incentive to connect with as many nodes as possible to minimize the risks of eclipse attacks [heilman2015eclipse], while the network layer overhead is amplified with the number of connections. We leave the estimation of such network overhead amplification factor to future works.

V-B Sandwich Attack Mitigation

Sandwich attacks are not profitable if the victim’s input amount remains below the MVI [zhou2020high]. This threshold depends on the AMM pricing formula, the total underlying pool liquidity, as well as the trader’s slippage configuration. The MVI threshold for instance increases if the market liquidity increases.

By routing the trading volume onto multiple AMM exchanges, AMM aggregates the MVI thresholds among the underlying liquidity pools. In the simple case, where two AMM markets have the same liquidity and pricing formula, AMM’s accumulative MVI threshold is  the MVI of a single AMM.

V-C Back-run Flooding Overhead Reduction

We observe back-run flooding on the P2P network, where MEV bots broadcast multiple similar back-running transactions for a single MEV opportunity (cf. Table VI). It appears that BRF may increase the success rate of back-running. For instance, each of the flooding transactions is likely to follow a different network propagation path in the asynchronous P2P network, which could increase the likelihood of a swift miner reception. While we find that of the successful arbitrage transactions are accompanied by BRF, we cannot provide quantitative insights to what degree BRF improves the success-rate of back-running.

Front-running Back-running
Strategy Priority Gas Auctions Back-run Flooding
Target State Confirmed Block State Pending Block State
On-chain? Yes Yes
Network? Yes Yes
TABLE VI: If an MEV bot acts on a confirmed block state, it performs PGA against other competing front-running bots. If an MEV bot acts on a pending block state, we observe back-run flooding. Both GPA and BRF cause on-chain and network layer overheads.

To quantify the network layer overhead, we identify past arbitrages on-chain and correlate the dropped transactions on the P2P network provided by our network listening node. We find that one of the most amplified flooding events entails  transactions on the network layer for a single arbitrage opportunity. These back-running transactions are identical, except the last byte of the transaction message, floods kb of data traversing the P2P network. This is equivalent to  the average block size on the 1st of March 2021111111https://etherscan.io/chart/blocksize. Only one of these transactions is confirmed on-chain1212120x49bc22c9c45d31064f3cf7f7bd5e1494439603d4f6e809b0a715bc08d1b585c8, classified as a failed arbitrage attempt by us. The remaining  transactions have a conflicting nonce with the confirmed transaction, and therefore discarded. We observe that back-run flooding is comparatively cheap because bots issue conflicting MEV transactions (e.g., with the same nonce), while only one transaction is mined.

Vi Arbitrage/Routing Among AMMs

In this section, we shed light on the performance of AMM when peered with N AMM markets (abbreviated as -AMM). While Section B in the appendix provides an optimal arbitrage strategy of -AMM, Algorithm 1 presents our sub-optimal two-point arbitrage strategy for -AMM, where . Intuitively, our strategy starts with the two AMMs offering the best and worst prices, and gradually narrows the price gap through arbitrage. Along this narrowing process, if the prices of a group of AMMs are synchronized, we aggregate their liquidity and treat them virtually as a single exchange. Executing a swap on a virtually aggregated exchange is equivalent to performing routing, where the trade volume is routed to each of the underlying AMM based on their liquidity. Our strategy, therefore, translate the arbitrage problem of -AMM into -AMM sub-problems.

To ease the reader’s understanding, we visualize the arbitrage process among three AMMs in Figure 12. The three AMMs we consider have prices sorted in ascending order (, , and respectively). Our algorithm hence performs arbitrage by considering only AMM  and  first. As the price gap narrows, we can encounter three different cases. In the first case, the price of AMM  increases from to , which is synchronized with the price of AMM 2. Our algorithm then aggregates these two exchanges, and continues the arbitrage process between the newly aggregated virtual AMM and AMM . The second case is the symmetric to the first case, where the price of AMM  falls from to , and our algorithm aggregates AMM  and . In the last case, (due to fees) the prices of all three AMMs are not synchronized, therefore we do not aggregate any AMMs.

Table VII shows the cost of Algorithm 1 among constant product AMMs. We estimate that the transaction cost of -AMM is  the cost for -AMM. We estimate the costs by applying linear interpolation based on our empirical cost evaluation from Table I.

Number of synchronized AMMs
Number of
Arbitrage computation
Synchronize volume
Cost over AMM average swap cost
Routing to one AMM
Arbitrage computation
Threshold computation N/A
Swap execution
Total cost
TABLE VII: Cost prediction of performing two-point arbitrages among multiple AMMs when a user sells asset X to purchase asset Y. The underlined cost ratios are taken from our two-point arbitrage evaluation (cf. Table I). The synchronize volume quantifies the amount of trading volume required to synchronize the asset price among multiple AMMs. We estimate that the cost of synchronize volume is similar to the cost of a single optimal routing.
Fig. 12: Visualization of the two-point arbitrage process among three AMMs, which performs at most  swaps (either Swapto or Swapto). In the first case, the liquidity from and are aggregated for Swapto. The second case is symmetric to the first. In the third case, the arbitrage does not trigger AMM aggregation.

Vii Related Work

AMM: The literature proposes various blockchain-based exchange models covering limit order book models [kyber2019, oasis2019, idex2019], auctions [dutchx2019], payment channel [luo2019payment] and trusted hardware [bentov2019tesseract] were proposed in the literature. Uniswap is to date the most actively used constant product AMM, while alternative weighted AMMs emerged [balancerexchange].

Arbitrage: Identifying arbitrage opportunities is extensively studied in traditional, centralized finance (or CeFi) [cai2003approximation, cui2020arbitrage]. One common methodology is to create a graph of all pairwise assets that can be traded to use a greedy search strategy, such as the Bellman-Ford-Moore algorithm, to search the trading space. For instance, the Bellman-Ford-Moore algorithm operates with a complexity of in a graph of edges and vertices. Such a greedy search methodology aims to create a circular, profitable trading opportunity. Greedy search approaches are restricted to actions such as trade asset for . However, because a greedy search algorithm only follows the locally optimal choice at each action, it might fail to explore and find profitable trading strategies. Zhou et al. show two mechanisms to automatically discover profitable arbitrage opportunities in the intertwined DeFi contract graph [zhou2021just]. Bartoletti et al. distill fundamental structural and economic aspects of AMMs, and in particular discuss the arbitrage problem [bartoletti2021theory].

Front-Running and Miner Extractable Value: Bonneau et al.  [bonneau2016buy], introduce the concept of bribery attack, which incentivizes miners to adopt a blockchain fork instead of the longest chain. Daian et al. [daian2019flash], introduce the concept of gas price auctions (PGA) among trading bots as well as the concept of MEV. MEV widens the variance of block rewards, encourages both bribery and under-cutting attacks [bonneau2016buy, carlsten2016instability]. The literature captures front-running by allowing a “rushing adversary” to interact with a protocol [beaver1992cryptographic]. Previous studies [baron2019risk, zhou2020high] suggest that HFT performance is strongly associated with latency and execution speed. The (financial) high-frequency trading (HFT) literature [angel2013fairness, menkveld2016economics] explores several trading strategies and their economic impact, such as arbitrage, news reaction strategies, etc. in traditional markets. Most of the traditional finance market strategies are applicable to AMM and decentralized exchanges [daian2019flash, angeris2019analysis, qin2020attacking, qin2021quantifying, zhou2020high, zhou2021just].

Eclipse Attacks: Strategically placed blockchain network nodes may control when and if miners receive transactions, affecting the transaction execution time [marcus2018low, henningsen2019eclipsing, gervais2015tampering, heilman2015eclipse].

Malpractices on Exchanges: Malpractices on financial exchanges is a well-studied domain. Besides the traditional market manipulation techniques [jarrow1992market] (such as cornering, front-running, and pump-and-dump schemes), previous works [lin2016new]

studies techniques such as spoofing, pinging, and mass misinformation, which leverage, e.g., social media, artificial intelligence, and natural language processing. Techniques were shown to deceive HFT algorithms 

[arnoldi2016computer]. To counterbalance this inherent trust, regulators conduct periodic and costly manual audits of banks, brokers, and exchanges to unveil potential misbehavior. Because DEXes operate under weak identities and censorship resilience (from both the creators, users, and miners), regulators may face challenges to impose anti-money laundering legislation.

Viii Discussion

We hope that our work engenders a wider corpus of orthogonal blockchain application designs which take into account the nature of the underlying ledger. We would like to emphasize that our work is based on a non-optimized prototype implementation which can likely be improved through additional engineering efforts.

Our evaluation shows that AMM does lower the required exchange block-space by . As such, AMM classifies as a scaling solution for both the network as well as the blockchain layer. While most existing backward-compatible scaling solutions such as payment channels, off-chain hubs, etc [gudgeon2019sok] provide weaker security guarantees, AMM inherits as a decentralized application the native blockchain security properties, and moreover improves the security of the blockchain consensus as shown in this paper.

Ix Conclusion

By means of the realization that one blockchain should only operate at most one AMM exchange, we design a novel AMM exchange, which allows exchange users to atomically extract Miner Extractable Value, instead of leaving such opportunity to others. We show how AMM can avoid two-point arbitrage MEV overhead on the P2P network and the blockchain transaction space. Reducing such overhead allows to strengthen the blockchain’s consensus security, without resorting to centralized relayer which undermine the very reason permissionless blockchains exist.

While AMM inherently takes advantage of the atomic nature of blockchain transactions for arbitrage and routing, our proposal can serve as inspiration to design further MEV-friendly DeFi protocols, e.g., for liquidations in lending markets. We hope that our work provides insights into a previously unconsidered and orthogonal design space for secure DeFi protocols which sustainably recognize the decentralized characteristics of permissionless ledgers.


Appendix A MEV Overhead Taxonomy

In the following, we provide a high-level taxonomy of the different sources of technical overhead introduced by MEV opportunities. We primarily differentiate between MEV opportunities on (i) the not-yet-confirmed network layer state and on (ii) the confirmed blockchain state. Note that we ignore the existence of blockchain forks for simplicity. We consider the MEV aware bots to not being miners, while the following reasoning also applies to miners extracting MEV.

Confirmed Block State MEV: An MEV extraction bot can choose to only act on a confirmed blockchain state, i.e., once a block is mined. Once a block at height is received by the bot, the bot attempts to front-run all other transactions in the next block . Confirmed state front-running is destructive, meaning that the bot bears no consideration to the subsequent transactions in the same block [qin2021quantifying, eskandari2019sok].

Unconfirmed Block State MEV: An MEV extraction bot may observe the unconfirmed blockchain transactions and anticipate how the next miner would order these transactions within a block (e.g., given the paid transaction fees). Based on the anticipated transaction ordering, the arbitrageur then verifies whether new MEV opportunities surfaced. If an MEV opportunity is found, the bot ideally issues a back-running arbitrage transaction as an exploit  [qin2021quantifying, eskandari2019sok].

Priority Gas Auction (PGAs) Overhead: PGA is the process by which MEV aware bots are competitively bidding on transaction fees to obtain a specific transaction position (usually the first) in the next block. Because a transaction in the miner’s mempool can be replaced before it is confirmed, PGA bots usually emit a new transaction with higher bids to replace their previous transaction [daian2019flash, zhou2020high]. Although the replaced transaction is dropped by the network eventually after the new transaction is confirmed, the replaced transaction is still broadcasted on the network layer. Therefore PGA causes an overhead on the blockchain network layer.

Block-space Overhead: Trading bots increasingly extract MEV with optimal parameters [qin2020attacking], bequeathing no revenue for following MEV bot transactions, which should then either revert with an error or fail silently. We classify failed successful MEV transactions as on-chain MEV overhead.

Appendix B Implementation

In this section, we present a concrete AMM implementation with two constant product AMM DEXes, namely Uniswap V2 and Sushiswap. Both these two exchanges follow a constant product formula, with a commission fee of (cf. Equation 16).


In the following, we denote the Uniswap and Sushiswap () market as DEX 1 and 2, where the price of AMM 1 is greater than or equal to the price of AMM 2 for Swapto (i.e., ). We use and to denote the states of DEX 1 and DEX 2 respectively.

B-a Routeto

As we have shown in Section III-E, the optimal routing strategy is to greedily route the trading volume to AMM 1 until the prices of both markets are synchronized. After the price synchronization, the remaining volume is routed to both AMM 1 and 2, while keeping the prices the same (cf. Theorem 1).

In Equation 17, we compute the threshold (), such that the prices between AMMs 1 and 2 will be synchronized after swapping exactly of asset for asset on AMM 1.


We now consider the optimal routing strategy if the prices between AMMs 1 and 2 are synchronized (i.e., ). We use to denote the ratio of funds between the two DEXes. In Equation 18, we compute the optimal routing ratio given that the liquidity taker trades amount of asset , where we route to AMMs 1 and 2 respectively.


Therefore, the optimal routing strategy routes to AMM 1 first, such that the prices between the two exchanges are synchronized. The routing strategy then routes of the remaining liquidity to AMM 1, and to AMM 2 (cf. Equation 18).

B-B ArbitrageFor

In the following, we derive profitable arbitrage constraints among two constant product AMM exchanges (e.g., Uniswap and Sushiswap). The constraints are mathematically simple, such that a smart contract derives it at low costs on-chain. We also derive the formulas to calculate optimal two-point arbitrage parameters to maximize arbitrage revenue. Equation 19 shows the specific arbitrage objective function for two constant product AMMs, derived by substituting Equation 16 into Equation 9.


To find the optimal arbitrage parameter (), we solve the derivative of the objective function . Equation 20 shows the only positive solution for .


In Equation 21, we substitute into the objective function to derive the optimal revenue.


In Equation 22, we find the constraint for the arbitrage opportunity to be profitable, without considering transaction fees.


We, therefore, apply Equation 22 to verify whether arbitrage is profitable given a blockchain state and use the optimal parameters (cf. Equation 20) to extract the maximum revenue.

Appendix C Miner Hashing Power

Table VIII shows the hashing power we extract from various sources to simulate the P2P network for Ethereum131313https://etherscan.io/stat/miner?blocktype=blocks, accessed Apr 2021, Bitcoin141414https://btc.com/stats/pool, accessed Apr 2021, Litecoin151515https://www.litecoinpool.org/pools, accessed Apr 2021 and Dogecoin161616https://explorer.viawallet.com/doge/pool, accessed Apr 2021.

Rank Ethereum Bitcoin Litecoin Dogecoin
1 24.3% 17.9% 16.0% 14.9%
2 19.3% 15.5% 14.4% 13.61%
3 10.4% 11.9% 14.0% 13.38%
4 5.8% 11.4% 12.2% 12.58%
5 4.6% 9.9% 11.4% 11.46%
6 4.3% 8.7% 10.2% 10.74%
7 3.8% 8.1% 9.2% 8.68%
8 2.8% 4.3% 7.4% 7.35%
9 2.6% 2.7% 1.8% 1.47%
10 2.5% 2.5% 1.2% 0.73%
TABLE VIII: The hashing power distribution for Ethereum, Bitcoin, Litecoin and Dogecoin as of April .
Pct % 0% 10% 33% 50% 67% 90% 100%
[kim2018measuring] - 99 151 208 231 285 -
[gencer2018decentralization] - 92 125 152 200 276 -
This work 0 95.5 138 180 215.5 280/5 300
TABLE IX: We base the latency distribution(ms) in this work on the mean statistics of the Ethereum P2P network provided by related works [kim2018measuring, gencer2018decentralization].

Appendix D Sub-optimal two-points arbitrage for