PaperlayerView exact revision on arXiv

Source-linked AI summary

High-Frequency Trading on Decentralized On-Chain Exchanges

Liyi Zhou, Kaihua Qin, Christof Ferreira Torres, Duc V Le, Arthur Gervais

arXiv:2009.14021v1cs.CR

TL;DR

Blockchain transparency and transaction latency make AMM DEX users vulnerable to predictable sandwich attacks that combine front- and back-running. The paper formalizes and evaluates these attacks, finding substantial single-adversary revenue on Uniswap and reduced profitability under competition, while exposing a security–scalability dilemma.

  • Problem

    Blockchain transparency and execution latency make front-running easier, exposing DEX traders to exploitation despite retaining custody of their assets.

  • Method

    The paper formalizes sandwich attacks on AMM DEXs, analytically and empirically evaluates them on Uniswap, and simulates competing adversaries.

  • Results

    3,414 USD average daily revenue is achieved by a single adversary in the Uniswap evaluation, while 2, 5 and 10 attackers reduce expected profitability by 51.0%, 81.4% and 91.5%.

  • Takeaways & Limitations

    The paper identifies a DEX security–scalability dilemma: low slippage can limit trades, whereas high slippage can permit adversarial profit.

  • Takeaways & Limitations

    The work does not consider on-chain margin platforms using AMM exchanges for short or long positions.

Abstract

from arXiv · show

Decentralized exchanges (DEXs) allow parties to participate in financial markets while retaining full custody of their funds. However, the transparency of blockchain-based DEX in combination with the latency for transactions to be processed, makes market-manipulation feasible. For instance, adversaries could perform front-running -- the practice of exploiting (typically non-public) information that may change the price of an asset for financial gain. In this work we formalize, analytically exposit and empirically evaluate an augmented variant of front-running: sandwich attacks, which involve front- and back-running victim transactions on a blockchain-based DEX. We quantify the probability of an adversarial trader being able to undertake the attack, based on the relative positioning of a transaction within a blockchain block. We find that a single adversarial trader can earn a daily revenue of over several thousand USD when performing sandwich attacks on one particular DEX -- Uniswap, an exchange with over 5M USD daily trading volume by June 2020. In addition to a single-adversary game, we simulate the outcome of sandwich attacks under multiple competing adversaries, to account for the real-world trading environment.

I. Introduction

DEXs preserve trader custody and censorship resistance, but blockchain transparency and execution latency expose users to sandwich attacks. The paper formalizes these attacks, evaluates their profitability and positioning, and identifies a security–scalability tradeoff.

  • DEXs let traders retain asset custody, while blockchain smart contracts execute orders without a third-party intermediary.
  • Blockchain transparency and execution latency make front-running easier and can negatively affect trader-asset security.
  • Sandwich attacks combine front-running and back-running around a victim transaction, with the adversary trading before and after an anticipated price change.
  • The paper formalizes AMM mechanisms and sandwich attacks, then analytically and empirically evaluates optimal revenue and transaction positioning.It focuses on AMM DEXs because their deterministic nature permits analysis with fewer assumptions.
  • 3,414 USD average daily revenue is achieved by an adversary in the empirical evaluation on Uniswap.The evaluation also reports Uniswap as having 5M USD trading volume at the time of writing.
  • 51.0%, 81.4% and 91.5% reductions in expected profitability occur with 2, 5 and 10 competing attackers, respectively.Expected profitability falls to 0.45, 0.17 and 0.08 ETH under the stated Uniswap scenario.
  • Lower default slippage improves security but makes trades more likely to fail under high transaction volume, whereas higher slippage permits adversarial profit.

B. AMM Mechanism

The paper models AMM markets through asset pools and deterministic pricing, focusing on the constant-product mechanism. It distinguishes expected slippage from execution-time deviations caused by intervening state changes.

  • An AMM asset pair X/Y consists of separate liquidity pools containing assets X and Y, with market state defined as (x, y).
  • AMM actions include adding liquidity, removing liquidity, and transacting one asset for another through a pricing function f(·).Trade fees are represented by c_x(·) and c_y(·).
  • The constant-product AMM keeps x×y constant for taker transactions, while liquidity-provider deposits or withdrawals can change k.The paper focuses on this model because it represented over 75% of AMM market liquidity.
  • Expected slippage is estimated from trade volume and available liquidity before execution, and larger trades produce greater expected slippage.
  • Unexpected slippage is the additional price change arising when AMM state changes between transaction submission and execution.It is measured as P − E[P], with the unexpected slippage rate dividing this difference by E[P].
  • 0.05 unexpected slippage results when a trade expected to receive 20 Y for 1 X instead receives 10 Y after the price changes from 0.05 to 0.1.

III. Sandwich Attacks on AMM DEXs

AMM DEX transparency and deterministic pricing make the price impact of pending trades predictable, while execution delays enable adversaries to sandwich victims. The paper studies taker- and provider-based attacks within this setting.

  • Front-running traditionally exploits information about a pending trade, while AMM DEXs make price impact predictable through transparent liquidity and deterministic pricing.
  • A victim transaction can suffer unexpected slippage when concurrent transactions change the AMM state between its expected-price block and execution block.The figure describes victim execution in block N + 3 while intervening transactions are based on block N.
  • Two sandwich attack types are studied: a liquidity taker attacks a liquidity taker, and a liquidity provider attacks a liquidity taker.Both exploit execution delay and knowledge of the direction of a price change.
  • An adversary observes pending zero-confirmation transactions through a spy node and seeks transaction placement before or after the victim in a miner-selected block.
  • The liquidity-taker attack emits front-running and back-running transactions around the victim, with transaction fees used to influence their relative ordering.

D. Liquidity Provider Attacks Taker

The paper introduces a liquidity-provider sandwich attack that manipulates pool liquidity before a victim trade, then restores liquidity and asset balances afterward. Analytical evaluation on Uniswap examines profitability across markets, victim sizes, slippage settings, and transaction costs.

  • Attack mechanism: A liquidity provider removes liquidity before the victim transaction, restores the pool afterward, and rebalances its asset position through a subsequent trade.The three transactions are RemoveLiquidity, AddLiquidity, and TransactYforX.
  • Attack mechanism: Liquidity providers forgo commission fees during the victim transaction because their assets are withdrawn from the pool.The foregone commission is proportional to the liquidity removed.
  • Analytical evaluation: The analytical evaluation uses Uniswap parameters and liquidity-pool distributions from Ethereum block 9M.The evaluation covers Uniswap markets and assumes direct Uniswap endpoint transactions, excluding internally routed transactions.
  • Analytical results: 0.01 ETH (2.03 USD) revenue is obtained for a 25 ETH victim trade, increasing to 0.14 ETH (20.71 USD) for a 50 ETH trade at 0.5% unexpected slippage.The analysis compares victim trades of 25 ETH and 50 ETH to SAI.
  • Analytical results: 24.26 ETH is the example minimum profitable victim input for SAI under a 0.01 ETH transaction fee and 0.3% commission.The minimum profitable input increases with liquidity-pool size.
  • Analytical results: Higher-liquidity markets yield higher potential revenue at fixed total slippage, provided the victim transaction is suitable.The paper contrasts SAI and MKR with SNX and DAI.

B. Adversarial Liquidity Provider

The liquidity-provider attack manipulates pool liquidity around a victim trade and can generate revenue despite foregone commissions. The paper evaluates this attack across Uniswap markets, including profitability thresholds and token-decimal effects.

  • Attack and revenue: Both the victim and honest liquidity providers lose money in the illustrated liquidity-provider attack.The victim pays 15,223.02 SAI for 100 ETH instead of 15,147.28 SAI without the adversary.
  • Token decimals: 44.54 ETH is the minimum victim transaction amount when SAI uses 17 decimal places, compared with 43.93 ETH at 18 decimals.For ETH-to-SAI transactions, the threshold increases from 45.3 ETH to 56.3 ETH.
  • Empirical evaluation: The experimental setup uses a modified Parity client that monitors pending Uniswap transactions and computes profitable adversarial strategies.Experiments were conducted on the ETH/VERI market and classify outcomes by transaction inclusion in the same block.
  • Attack and revenue: 0.07 ETH (10.55 USD) is the reported profit from removing and later regaining 37.76% of liquidity around a victim trade.The attack uses 785.97 ETH and 415,030.47 SAI when removing liquidity, then deposits 2,749.57 ETH and 420,542.21 SAI.

A. Liquidity Taker Attacking Taker

The liquidity-taker sandwich attack exploits pending victim transactions by placing trades before and after them. Experiments and historical estimates evaluate execution success, slippage configurations, transaction ordering, and revenue potential.

  • Experimental execution: 450ms is the average time to discover a victim transaction, while computing and sending both adversarial trades takes less than 200ms.The experiment uses 0.001 ETH victim trades on the ETH/VERI Uniswap market.
  • Experimental execution: 19 of 20 attacks succeeded, although 8 of 20 were only partially successful because the back-running transaction was mined later.The victim remained in the adversary’s mempool for an average of 35.84 seconds, and one attempt failed.
  • Revenue estimates: 440,749.02 USD is the estimated taker-attack revenue across 79 Uniswap exchanges over 158 days, assuming a 0.01 ETH break-even cost.The corresponding liquidity-provider estimate is 98,666.15 USD.
  • Slippage and ordering: Past Uniswap transactions used an average expected slippage of 0.58%, while Figure 10 estimates expected and maximum permitted unexpected slippage.The slippage estimates use block N’s state for transactions mined at block N+1.
  • Slippage and ordering: The most common unexpected-slippage setting was 1%, higher than Uniswap’s 0.5% default total-slippage setting at the time.The paper links the higher unexpected-slippage configuration to higher front-running profit.
  • Slippage and ordering: Transaction-ordering heuristics may misclassify blocks because both Geth and Parity sort transactions by gas price by default.The number of blocks classified as Parity default is therefore treated as a lower bound.

A. Miner Transaction Ordering Results

Miner transaction ordering is predominantly gas-price based, giving adversaries a practical way to influence transaction placement. The section also models competing attackers, network conditions, transaction fees, and miner behavior in simulations.

  • Observed miner ordering: 79% of miners order transactions by gas price, while 16% follow Parity’s default strategy and 2% of blocks are empty.Another 3% of miners use an unknown ordering method.
  • Observed miner ordering: A higher or lower gas price by 1 Wei is sufficient to position a transaction before or after a target with 79% probability, absent other adversaries.Equal gas prices are ordered FIFO by Parity and Geth.
  • Gas-price data: 189,951,899 transactions across 388 days had a median gas price of 10 Gwei and a modal gas price of 20 Gwei.The average gas price was 17.2 ± 10520.1 GWei.
  • Simulation model: The multiple-attacker analysis assumes equal resources and evaluates 2, 5, and 10 adversaries using reactive counter-bidding.The strategy raises a transaction-fee bid after observing a competing transaction and may estimate a lower bound for front-running cost.
  • Simulation model: The model incorporates propagation, transaction-size, fee, congestion, and miner-ordering assumptions, including direct adversary–miner and adversary–victim connections.Transaction sizes are calibrated from 100,000 consecutive Uniswap DAI blocks, with mean 426.27 ± 68.94 Bytes.

C. Simulation Results

Simulations evaluate sandwich profitability under multiple competing adversaries on Uniswap. Profitability declines as attackers compete and can disappear after sufficiently long victim-transaction delays.

  • Liquidity taker simulations: 14.75 ETH (2,197.30 USD) is the minimum profitable victim input under 0.5% slippage on the Uniswap DAI market at block 9M.The result concerns the expected profit of an adversarial liquidity taker facing 2, 5, or 10 adversaries.
  • Multiple-attacker simulations: 27.7, 20.3, and 16.3 seconds of victim-pending time make the attack unprofitable with 2, 5, and 10 adversaries, respectively.These thresholds apply when the victim transacts 20 ETH for DAI.
  • Multiple-attacker simulations: 51.0%, 81.4%, and 91.5% reductions in expected profitability occur with 2, 5, and 10 attackers, respectively.The setting is a 20 ETH-to-DAI victim transaction pending for 10 seconds before mining.
  • Multiple-attacker simulations: Multiple attackers divide total revenue among adversaries after transaction-fee overhead, while congestion makes attacker break-even harder to attain.The congestion condition is described as a victim transaction remaining pending for more than 15 seconds.
  • Implications: The conclusion reports that sandwich attacks may remain profitable under multiple competing adversaries.The paper frames this result within the security and scalability tradeoff of AMM DEXs.

Appendix A Sandwich Attack Details

The sandwich attack executes an adversary’s transactions around a victim swap, changing AMM states before and after the victim trade. Profit is assessed by comparing the adversary’s input and output while accounting for costs.

  • Victim transaction: The victim transaction changes the AMM state from initial state s0 according to the no-unexpected-slippage transition.The formal model represents the initial market as (x0, y0).
  • Front-running: TA1 is planned before TV, commonly through a higher transaction fee, producing the first AMM state transition.The adversary’s first transaction opens the position used by the later back-run.
  • Victim transaction: The victim transaction produces a subsequent AMM-state transition after the front-running transition.The formal sequence labels the victim transition as TV and specifies its state update in Equations 10 and 11.
  • Back-running: TA2 is planned after TV, commonly through a lower transaction fee, and closes the position opened by TA1.TA2 swaps asset Y from TA1 for asset X.
  • Profitability: The attack is profitable when the adversary’s profit exceeds costs such as transaction fees and equipment costs.A rational adversary undertakes the attack under that condition.

B. Liquidity Provider Attacks Taker

The liquidity-provider formulation tracks pool ownership and adversary assets before and after a state transition. It compares outcomes with and without front-running a victim transaction.

  • State and ownership: The model denotes the AMM pool state at block N by asset amounts xN and yN.It also defines the USD value of pool assets and the liquidity-provider share.
  • State and ownership: A liquidity provider with share L deposits δx,N = xN L/(1−L) and δy,N = yN L/(1−L) into the pool.The formulation represents the provider’s contribution relative to pool assets.
  • Profitability: Profitability is evaluated by comparing the adversary’s asset holdings and pool proportions before and after the attack.The model uses xA, xA*, yA, yA* and Lx, Lx*, Ly, Ly* for these comparisons.
  • Victim interaction: Without front-running, the victim’s X-for-Y transaction changes the AMM state and the adversary receives a commission fee.The liquidity-provider attack model explicitly contrasts this outcome with front-running.

2) Attack Execution:

The liquidity-provider sandwich attack executes around a victim transaction by altering liquidity before and after the victim, then rebalancing assets to preserve the provider’s position while generating profit.

  • Attack Execution: TA1 front-runs the victim by withdrawing the adversary’s proportional liquidity from the AMM pool.The withdrawal changes the pool state before the victim transaction executes.
  • Attack Execution: The victim transaction TV then modifies the AMM state according to the exchange’s trading equations.Its execution occurs between the adversary’s front-running and back-running transactions.
  • Attack Execution: TA2 back-runs TV by adding liquidity so the adversary retains the same proportion of overall liquidity.The resulting state is specified by Equations 27 and 28.
  • Attack Execution: TA3 rebalances the AMM assets by converting Y to X, restoring the adversary’s original amount of asset X.This is necessary because TA2 adds more asset X to liquidity than TA1 withdrew.
  • Attack Execution: The completed attack preserves the adversary’s liquidity proportion and asset-X holdings while increasing asset Y holdings and generating profit.Equation 33 yields the resulting profit.

Appendix B Additional Details For Liquidity Provider

The appendix examines adversarial revenue and protections for liquidity-provider sandwich attacks, including competition, slippage-based defenses, and protocol-level alternatives.

  • Additional Details For Liquidity Provider: Figure 13 quantifies optimal adversarial revenue for a liquidity provider when no other attacks are running.It considers victims selling assets for ETH across five Uniswap exchanges with 0.3% fees and a 0.01 ETH adversarial break-even.
  • Additional Details For Liquidity Provider: The minimum profitable victim input with a single adversary is 27.8 ETH (4,141.37 USD) on the Uniswap DAI market at block 9M.Figure 14 compares expected profit with 2, 5, and 10 competing adversaries under 0.5% victim slippage protection.
  • Additional Details For Liquidity Provider: Zero-slippage protection causes a user’s trade to fail if front-running occurs, while the user remains liable for blockchain transaction fees.The protection is not scalable because it limits AMM DEX execution to one transaction per blockchain block.
  • Additional Details For Liquidity Provider: Disabling transactions above the minimum profitable victim input is proposed as a protection whose threshold depends on market liquidity and AMM design and configuration.The threshold depends on the pricing formula and fees as well as total market liquidity.
  • Additional Details For Liquidity Provider: Trusted sequencing nodes could order transactions before execution, but would make an AMM DEX such as Uniswap permissioned and could themselves manipulate ordering.The proposal is discussed as a possible response to Ethereum consensus-level ordering manipulation.

1) Multi-Party Computation (MPC):

The paper discusses commitment-based defenses that hide or sequence trader actions, then identifies usability, residual attack probability, and unavoidable state leakage in constant-product AMMs.

  • Multi-Party Computation (MPC): A standard commit-and-reveal protocol orders hidden function calls by commitment order and executes them after traders reveal their calls.Traders commit during one round and reveal during a later round.
  • Multi-Party Computation (MPC): Commit-and-reveal requires participants to understand both protocol rounds and still permits probabilistic sandwich attacks.An adversary can submit commitments around honest traders’ commitments and reveal only profitable transactions.
  • Multi-Party Computation (MPC): Submarine commitments hide commitment transactions among newly generated Ethereum addresses using the CREATE2 EVM opcode.The scheme commits funds to an address derived from the AMM address, taker address, key, and contract code.
  • Multi-Party Computation (MPC): During revealing, the AMM verifies the commitment’s block membership, recomputes the commitment address, checks the deposit, and executes the requested action and input.The reveal supplies the transaction data, commit block, key, and a Merkle-Patricia proof.
  • Multi-Party Computation (MPC): Confidential AMM trading must hide function names, parameters, and current pool state, but hidden-state approaches may require trusted off-chain components.The pool state is needed to compute the asset amount returned to the liquidity taker.
  • Multi-Party Computation (MPC): For a constant-product AMM, the paper argues that confidentiality of the pool state is impossible because two consecutive actions let an adversary solve for the state variables.The adversary uses the two resulting equations and the known outputs to determine (x, y).
Loading 2009.14021v1…