Skip to content

Back to the catalog

How Much Must a Private Mempool Hide? Exact Leakage Thresholds for Sandwich Attacks
arxiv.orgpaper

How Much Must a Private Mempool Hide? Exact Leakage Thresholds for Sandwich Attacks

This arXiv paper derives exact conditions under which private/encrypted mempools still leak enough information (transaction pair, direction, and a coarse size range) to make sandwich attacks profitable against a fee-free constant-product AMM (the Uniswap v2 pricing rule). It shows the smallest size consistent with the leak determines the optimal front-run and its guaranteed profit in closed form, and that multi-trader first-price auctions for sandwich rights hand all expected rent to the auctioneer; it also shows hiding trade direction prevents a single non-contingent front-run from covering both directions, though post-trade arbitrage can survive even perfect pre-trade hiding. The results give privacy-layer designers a precise threshold for how much size information must stay hidden to rule out profitable sandwiching.

TL;DR Derives exact leakage thresholds showing how much a private mempool must hide about trade size/direction to actually stop sandwich attacks on constant-product AMMs.
Document

What it is

A theory paper deriving exact formulas (not just a qualitative result) for when leaked transaction-size information in a private mempool makes sandwich attacks profitable, in the fee-free constant-product AMM (Uniswap v2 pricing rule) model.

How it works

Only the lower bound ℓ of the leaked size interval matters — the upper bound is irrelevant to profitability. The largest robustly-admissible front-run size is:

a_max(ℓ,τ) = [ -(2X+ℓ) + √((2X+ℓ)² + 4τX(X+ℓ)) ] / (2(1-τ))

and it is optimal under pointwise, expected, and worst-case profit criteria alike. The guaranteed worst-case gross profit at that front-run is closed-form:

W(I) = τℓ(X+ℓ) / (X+τℓ)

Given execution cost c, a guaranteed-profitable sandwich exists iff ℓ exceeds the threshold:

λ_c = [ -(X-c) + √((X-c)² + 4cX) ] / (2τ) ... wait, as given: λ_c = ( -(X-c) + √((X-c)² + 4cX/τ) ) / 2 — stated in the paper as Eq. 14, with first-order approximation λ_c ≈ c/τ.

With multiple traders bidding in a first-price auction for sandwich rights, every pure-strategy equilibrium transfers the entire expected net rent to the auctioneer (not to the winning trader) — so competition among front-runners doesn't erode the attack's cost, it just redistributes who captures the profit.

Hiding direction (not just size) blocks a single non-contingent front-run from covering both buy/sell directions, but post-trade arbitrage (profit up to q²/(X+q)) can survive even with perfect pre-trade hiding of size.

Preconditions / Affected

Applies specifically to fee-free constant-product AMMs (Uniswap v2 rule); fee effects are only bounded in one direction (their Prop 6.7) and other pricing curves are explicitly not covered (Remark 6.10). Requires that the mempool/privacy layer leaks a lower bound on transaction size — a half-open interval (0, u] (no positive lower bound revealed) with c>0 guarantees no universally-profitable robust sandwich exists, though expected-profit attacks can still appear in equilibrium.

What to do

For privacy-layer designers: the actionable design constraint is to ensure leaked size information never reveals a lower bound ℓ above λ_c ≈ c/τ (execution cost divided by victim's slippage tolerance). Revealing anything else about size (upper bound, exact midpoint, etc.) does not matter for ruling out guaranteed-profit sandwiches — only suppressing the lower-bound leakage above that threshold does.

Caveats

The "no profitable sandwich" guarantee is distribution-free (worst-case across the leaked interval); the paper separately notes that expected-profit (not worst-case) sandwiches can still clear in equilibrium even after near-perfect size hiding, if the posterior is concentrated (e.g., mass near the top of the range). Results are derived for the no-fee case only; real Uniswap v2 fees are treated as a one-directional bound, not an exact extension.

Technologies named here

Techniques named here