High-Frequency Trading on Decentralized On-Chain Exchanges

In three numbers

What a sandwich is worth

The problem

A transparent exchange with a delay is a front-runner's dream

An automated market maker (AMM) holds two pools of assets, $x$ of asset $X$ and $y$ of asset $Y$, and quotes prices from a fixed formula. Uniswap keeps the product constant, $x \cdot y = k$. A taker who pays in $\delta_x$ moves the pool to

$$ (x,y) \xrightarrow{\ \textsf{TransactXForY}(\delta_x)\ } \Big(x+\delta_x,\ \frac{xy}{x+\delta_x-c_x(\cdot)}+c_y(\cdot)\Big) $$

where $c_x, c_y$ are fees (0.3% on Uniswap). Every price is deterministic and every pending order is public in the mempool for seconds before a miner includes it. So an adversary knows exactly how a victim's trade will move the price, and has time to act.

Traders defend themselves with a slippage limit: “fill me only if the price is at most 0.5% worse than quoted”. The attack exploits exactly that tolerance. The adversary front-runs just enough to push the price to the edge of the victim's limit, lets the victim trade at the worse price, then back-runs to unwind. The victim's trade still succeeds, only more expensively.

Table I: example price slippages on an AMM DEX

	AMM state 1		AMM state 2
Liquidity $X$ ($x$)	100		1,000
Liquidity $Y$ ($y$)	10		100
Product ($k = xy$)	1,000		100,000
Purchase amount X	1	10	1	10
AMM price Y/X	0.1000	0.1000	0.1000	0.1000
$\mathbb{E}[P]$ Y/X	0.1010	0.1111	0.1001	0.1010
Expected slippage	0.0010	0.0111	0.0001	0.0010
Slippage rate	1.01%	11.11%	0.10%	1.01%

Interactive · attack 1

Sandwich a trade: the liquidity-taker attack

A victim sells ETH for a token. Pick one of the five largest Uniswap markets, a trade size and the victim's slippage tolerance. The adversary front-runs with the largest trade that still leaves the victim's order inside its limit, then sells the tokens back.

Recomputed in your browser from the paper's constant-product model (0.3% fee, pool reserves at block 9M from §IV-A). At the default settings it reproduces the Fig. 5 example exactly, and across markets it reproduces all 15 minimum-victim points of Fig. 7. The model is continuous; the mainnet bot also searched over Uniswap's integer rounding (§V). Dollar values use the paper's rate of 1 ETH = 148.97 USD.

Interactive · attack 2 (new in this paper)

Pull the rug, then put it back: the liquidity-provider attack

A liquidity provider can hurt a victim without trading at all. By withdrawing a share $L$ of the pool just before the victim buys ETH, it thins the market so the victim's order moves the price further. Afterwards it re-deposits the same share and rebalances with one swap. The cost is the 0.3% commission its share would have earned on the victim's trade.

Derived for this page from the paper's appendix equations: withdraw $L$, victim buys an exact amount of ETH, re-deposit to restore share $L$, then one swap. At the default settings it reproduces the paper's 100 ETH example (26.58%, 0.28 ETH vs 0.08 ETH passive) and its 60 ETH example (37.76%, 0.07 ETH after 0.01 ETH gas). For minimum victim sizes, see note 6 under Notes on the numbers.

Interactive · positioning

Can you land in the sandwich?

The attack works only if the miner places $T_{A1}$ directly before the victim and $T_{A2}$ directly after. The adversary does not collude with miners. It prices $T_{A1}$ at the victim's gas price $+1$ Wei and $T_{A2}$ at $-1$ Wei, then relies on the miner's ordering policy. The authors classified every block from Uniswap's launch (block 6,627,917) to block 9M: 388 days.

Interactive · missed revenue

158 days of Uniswap, replayed

For the 79 exchanges listed in the Uniswap UI (§V-C and Table III; §V's setup paragraph says 78, see note 11), the authors replayed every transaction between blocks 8M and 9M. For each one they asked whether a sandwich would have beaten a 0.01 ETH break-even cost. Out of 105,161 trades, 7.4% were profitable targets for a taker and 4.2% for a provider.

Transactions were crawled from a full archive Geth node. Most takers traded with about 1% maximum unexpected slippage (the Uniswap default at the time); the estimated averages were 0.58% expected and 1.16% unexpected slippage (Fig. 10).

Interactive · many adversaries

When the bots compete

With several attackers watching the same victim, whoever gets their front-run $T_{A1}$ mined first wins. The loser's front-run fails the victim's slippage check. Each bot follows the reactive counter-bidding strategy: when it sees a rival bid, it re-issues with a 10% higher gas price (Geth's replacement bump). The authors simulated this 100,000 times per setting on the Uniswap DAI market at block 9M, with the victim's slippage fixed at 0.5%.

Simulation inputs from the paper: transaction size 426.27 ± 68.94 bytes; victim gas price 8.76 ± 61.18 GWei; victim pending time uniform on 0–30 s (block interval 13.5 ± 0.12 s); gas used 85,488 ± 34,782; latency and bandwidth interpolated from prior measurements (Table VII). The minimum profitable victim input is 14.75 ETH (2,197.30 USD) for a single taker adversary and 27.8 ETH (4,141.37 USD) for a single provider adversary.

Side by side

Two ways to make a sandwich

Measured

Results

Live attacks on Ethereum mainnet (Table II)

The authors ran a modified Parity client (mempool raised from 1,024 to 2,048 transactions) on AWS in Ireland, with a Python bot subscribed to pending transactions. The only victims were their own transactions, sent through the Uniswap UI and MetaMask to the smallest-liquidity market in the UI: ETH/VERI (0.01 ETH and 0.07 VERI, 3.50 USD in total).

Victim: 0.001 ETH at 5 GWei (taker runs), 0.002 ETH at 2 GWei (provider runs). Clock difference between adversary and victim: 8.781 ms ± 6.189 ms. “Partial” means the front- and back-runs both succeeded but $T_{A2}$ was mined in a later block than $T_V$. The one failure had $T_V$ in the mempool for only 1.677 s.

Top 10 miners by blocks mined, blocks 6,627,917 to 9M (Table IV)

Miners seem to switch among strategies. Four of the ten always follow a known strategy, and 0xb293…0347 is the only one that mined no empty blocks.

Gas prices, 189,951,899 transactions over the same 388 days

Mean 17.2 ± 10,520.1 GWei; median 10 GWei. The most common price, 20 GWei, was used by 23,759,990 transactions (12.5%).

Notes on the numbers

Everything on this page comes from the paper's source. Where the paper disagrees with itself, or where our recomputation departs from it, both values are shown here rather than silently reconciled.

1. ETH/SAI pool size. §IV-A first gives the pool as 7,377.53 ETH and 521,468.62 SAI, then as 7,377.53 ETH and 1,099,040.91 SAI. Only the latter reproduces Fig. 5 (2,754.32 SAI for 18.59 ETH) and the stated rate of 148.97 USD per ETH, so the calculators use it.
2. Taker success rate. §V-A says the attack succeeded in “19 out of 20” attempts; Table II counts 11 full and 8 partial successes. The two agree only if partial successes count.
3. Provider mempool time. §V-B says $T_V$ stayed in the mempool “on average less than 10 seconds”; Table II reports a mean of 23.09 s.
4. Table III denominators. Two taker rows print 602,85 and 196,72. The provider rows and the column total show these are 60,285 and 19,672.
5. ETH/USD conversions. 0.01 ETH is given as 1.97 USD and 0.001 ETH as 0.2 USD. At the paper's own 148.97 USD per ETH these would be 1.49 and 0.15 USD.
6. Provider minimum victim. The Fig. 9 caption says “adversary break even at 0.01 ETH tx fees”, yet its 43.93 ETH (SAI), and the appendix's 27.8 ETH (DAI), match where the model's revenue first turns positive (43.85 and 27.70 ETH). At a 0.01 ETH cost the model gives 45.84 and 29.70 ETH. Fig. 13's curves also begin where revenue turns positive. The model is real-valued, so the token's number of decimal places cannot affect it. The paper's own computation is sensitive to decimals: Fig. 9 reports that 17 instead of 18 decimals moves the SAI minimum from 43.93 to 44.54 ETH. The remaining ~0.1 ETH gap is therefore something this model cannot reproduce.
7. Simulation scale. §VII reports 0.45 ETH expected profit per attacker with two attackers on a 20 ETH → DAI victim at 0.5% slippage, and Fig. 11's colour bar reaches 3 ETH. The §IV model gives a single attacker 0.030 ETH revenue for that same trade. The paper does not explain the gap, so the §VII numbers are shown as stated and not mixed with the calculators.
8. Taker minimum on DAI. §VII gives 14.75 ETH; Fig. 7 gives about 16.07 ETH at 0.5%. §VII uses simulated gas costs rather than a flat 0.01 ETH, so these need not agree.
9. Fig. 13, middle panel. The axis is labelled in percent (0.10%–0.60%), but the values are fractions of the pool (0.2658 = 26.58%, as stated in §IV-B).
10. Congestion threshold. The introduction says break-even gets harder once the victim waits longer than the average block interval (13.5 s); §VII says more than 15 s.
11. Number of exchanges. §V's experimental setup mentions “the 78 Uniswap exchanges on the Uniswap UI as of block 9M”; §V-C and the Table III caption use 79 exchanges.

Reference

Cite this work

@inproceedings{zhou2021high,
  title     = {High-Frequency Trading on Decentralized On-Chain Exchanges},
  author    = {Zhou, Liyi and Qin, Kaihua and Ferreira Torres, Christof and
               Le, Duc V. and Gervais, Arthur},
  booktitle = {IEEE Symposium on Security and Privacy (S\&P)},
  year      = {2021}
}

The linked PDF is the arXiv version, arXiv:2009.14021v1.

Code and data. The paper contains no code or data availability statement and points to no public repository, so this page links none. The Uniswap figures come from the authors' crawl of a full archive Geth node; the mainnet experiments attacked only the authors' own transactions.