MEV resistance: why UPEE is sandwich-proof by construction

Theorem 7.3 — UPEE transactions resist sandwich/frontrun/liquidation MEV by construction. Theorem 7.4 — block MEV bounded by public-bit leakage, not transaction value. Independent of V, not super-linear.

MEV is the second-order tax on public DeFi. Searchers monitor the mempool, see your swap before it confirms, and front-run / back-run / sandwich it for profit. On Ethereum L1 in 2024-2025, MEV extracted from retail users approached $700M/year — straight value transfer from end users to searchers and validators.

UPEE eliminates the dominant classes of MEV by construction. This post derives why, and quantifies what’s left.

This is post 10 of 11 in the relayerless-privacy series.

What MEV is, formally

Definition. Let B = (tx_1, ..., tx_n) be a block of transactions, σ_0 the pre-block state. The MEV of block B relative to validator V is:

\mathrm{MEV}(B, V) \;=\; \max_{\pi \in S_n,\ \mathsf{tx}_{\mathrm{ins}}} \Bigl[\,\mathrm{profit}_V(\sigma_0, \pi(B) \cup \mathsf{tx}_{\mathrm{ins}}) - \mathrm{profit}_V(\sigma_0, B)\,\Bigr].

The maximum is over (a) all permutations π of the transaction ordering and (b) all sets tx_ins of transactions the validator may insert. profit_V is the validator’s balance change after executing the reordered/augmented block.

Concretely, the four dominant MEV categories:

Category	What the adversary needs	Public DeFi cost
Sandwich	Trade direction + size	$(V^2 / L)$ for a $V$ -sized swap, $L$ pool liquidity
Frontrunning	Transaction content	Up to full tx value
Backrunning	Observable state change	Bounded by arbitrage opportunity
Liquidation	Position state	Liquidator’s bonus %

Theorem 7.3 — MEV resistance of private transactions

Statement. Let tx be a private UPEE transaction. For any PPT adversary A (including a colluding validator):

\Pr[\mathrm{MEV}_A(\mathsf{tx}) > 0] \;\leq\; \mathsf{negl}(\lambda)

for sandwich attacks, frontrunning, and liquidation MEV. Backrunning is bounded separately by public-output leakage.

Proof of sandwich resistance

A sandwich attack requires the adversary to determine the trade direction (buy or sell) and approximate size of the victim’s swap. In UPEE, the transaction content — including the program being invoked, the private inputs, and the state transition — is hidden by the ZK proof.

By Theorem 3.12 (simulation-based privacy), there exists a simulator S that produces a computationally indistinguishable view using only the public outputs ({nf_i}, {cm_j}, f, program_id). S does not receive the trade direction or size:

\bigl|\,\Pr[\mathcal{A}(\mathsf{View}_{\mathrm{Real}}) = \mathrm{direction}] - \tfrac{1}{2}\,\bigr| \;\leq\; \mathsf{negl}(\lambda).

Without the direction, a sandwich attack is a coin flip — expected profit zero (the adversary is equally likely to lose as to gain).

Proof of frontrunning resistance

Frontrunning requires the adversary to know what the transaction will do before it confirms. In UPEE the transaction content is encrypted within the ZK proof; the adversary sees only the public tuple, which is simulatable without the witness. The adversary has no advantage in predicting the transaction’s effect on state, so frontrunning degenerates to random speculation. ∎

Proof of liquidation resistance

Liquidation MEV requires knowing that a specific position has become undercollateralised. In UPEE, position state lives in the private state tree as committed values. The adversary can see that a position exists (via its commitment) but not whether it is liquidatable — that requires opening the commitment, which the ZK proof guarantees they cannot do. ∎

The backrunning caveat

Backrunning exploits observable state changes after the fact. Even with UPEE, some public state changes leak: a private DEX swap might cause an observable change in a public AMM’s price oracle, and that’s a backrunnable event. The leakage is bounded by the number of bits of public state affected by the transaction.

This is the point of Theorem 7.4.

Theorem 7.4 — MEV revenue bound

Statement. For a block containing n private UPEE transactions, the expected MEV revenue for a validator is bounded by:

\mathbb{E}[\mathrm{MEV}] \;\leq\; n \cdot f_{\max} \;+\; \ell_{\mathrm{bits}} \cdot v_{\mathrm{bit}}

where:

f_max = max_i f_i is the maximum public fee — validators trivially “extract” fees, but those are legitimate compensation for inclusion.
ℓ_bits = sum |public outputs of tx_i| is total information leakage in bits across the n transactions.
v_bit is the maximum economic value per bit of leaked information (application-dependent).

Proof. Each private transaction contributes at most f_i ≤ f_max in direct revenue. Additional MEV requires exploiting information beyond the fee. By Theorem 7.3, the only exploitable info is from public outputs. Each bit of public output conveys at most one bit about private state. The economic value extractable per bit is bounded by the application’s value density — for a DEX trade of value V, one bit of direction info yields expected profit O(√V) due to the square-root law of market impact. Sum over bits and transactions. ∎

The qualitative shift

For public DeFi, MEV from a swap of value V scales as O(V^2 / L) for sandwich attacks (super-linear in V).

For UPEE, MEV is bounded by public-bit leakage × per-bit value, which is independent of V.

That’s the shift. MEV no longer scales with transaction value. A user moving $10M through UPEE is not 10× more valuable to an MEV searcher than a user moving $1M — both leak the same number of public bits.

Model	Sandwich MEV scaling	Frontrun scaling
Public DeFi (Uniswap on ETH)	$O(V^2 / L)$	$O(V)$
UPEE	$O(\ell_{\mathrm{bits}})$ — independent of V	0

Public outputs of a UPEE transaction

Concretely, the public bits leaked per transaction:

Output	Bits	Information content
Nullifiers	256 × n_in	Pseudorandom from the adversary’s view (PRF security)
Commitments	256 × n_out	Pseudorandom from the adversary’s view (Poseidon hiding)
Merkle root	256	Public state, doesn’t carry tx-specific info
Fee	64	Reveals fee tier, ~10 bits effective entropy
program_id	256	Identifies which program; partial function privacy leak

Pseudorandom outputs by definition leak nothing about the underlying state. The MEV-relevant leak is the fee tier (~10 bits) and the program_id (which program executed). For a DEX program, the program_id reveals that some swap happened in that DEX — but not the direction, size, or counterparty.

What about backrunning a private DEX?

A private swap might still cause an observable state change in the DEX’s public price oracle. In that case the backrunner observes:

A nullifier was consumed (the swap happened).
The price oracle moved by some amount Δp.

Δp encodes the trade size. The backrunner can arbitrage based on Δp without knowing who swapped or in which direction.

Mitigation. Use a batch-auction DEX (Penumbra’s ZSwap is the reference design): aggregate all swaps in a block into a single batch with a uniform clearing price. The price oracle moves once per block, not per trade. Individual trade direction and size remain hidden; only the net batch flow is visible.

This is on the F_RP roadmap as a separate construction (Private Batch Auction, PBA).

What stays public no matter what

Three things UPEE can’t hide while still letting validators do their job:

The fee f. Validators need to know f to prioritise inclusion. This is a 64-bit public input.
The fact a transaction occurred. The validator inserts the nullifier and commitment, both public.
Block timing. Block-level patterns (transactions per block, time-of-day) leak metadata about overall protocol usage.

The first two are inherent to any chain with fees and global state. The third is mitigated by batch-auction DEX design and by encouraging client-side delay sampling on the user side.

The Ethereum ecosystem has been working on MEV mitigation for years:

Approach	Mechanism	What’s hidden	What still leaks
Flashbots private mempool	Direct submission to builder	Tx contents pre-confirmation	Builder sees + can extract MEV
MEV-Share	Selective metadata disclosure	User chooses	What user discloses
Shutter Network	Threshold-encrypted mempool	Tx until block sealed	Tx after seal
EIP-8105 enshrined encrypted mempool	Protocol-level encryption	Tx during ordering	Some patterns
UPEE (this work)	ZK-encrypted execution	All inputs/outputs	Fee + program_id + state-change side-effects

The Ethereum approaches are all about delay — hide the tx until the moment it’s executed, accepting the leak after that. UPEE is structurally different: the tx is never visible in plaintext. Even after execution, the inputs and intermediate state remain encrypted.

Why this matters for retail

The user-facing implication: a retail user on UPEE doesn’t pay an MEV tax that scales with their trade size. They pay their explicit fee f and a small bounded leakage cost. For a $1M trade on UPEE, MEV cost is bounded by the same ℓ_bits · v_bit term as a $1k trade.

That’s the point of building this on a smart-contract chain. Public DeFi is great for liquidity but hostile to retail. Private execution restores the property that “I trade because I want to trade”, not “I trade and pay an invisible 30-50bps tax to the searchers between me and the AMM”.

Open problem 7.5 — tightness

The bound in Theorem 7.4 is an upper bound. Is it tight? Specifically: construct an adversary that achieves MEV revenue within a constant factor of ℓ_bits · v_bit, or prove the bound can be tightened by structural analysis of SPST/UPEE.

This is open. My intuition is the bound is loose — most public outputs are pseudorandom and don’t carry economic value. But proving it requires careful analysis of the per-application leakage channels, which depends on the application.

Bibliography

Daian, P., Goldfeder, S., Kell, T. et al. (2019). Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. IEEE S&P 2020.
Flashbots Collective. MEV-Share: programmably private orderflow.
Shutter Network. EIP-8105: Universal Enshrined Encrypted Mempool.
Penumbra Labs. ZSwap: shielded sealed-bid batch auctions.
ESMA (2025). Maximal Extractable Value: Implications for Crypto Markets. European Securities and Markets Authority.

Previous: F_RP vs the rest ← · Next: The post-quantum migration path →