Understanding Optimal Swap Behavior for Mempool Transactions

Decentralized exchanges (DEXs) are one of the core foundations of DeFi, facilitating billions of dollars in daily transactions. One would expect that such a critical and battle-tested component of the ecosystem would be subject to intense optimization pressure, and many aspects of the “transaction supply chain” have indeed been optimized, from DEX aggregators that route trades across pools to gasless swaps.

The protocol level is also rich with innovative designs, including RFQ platforms, private relay services, order flow auctions (OFAs), and even competing tools to recapture the value created by transaction activity. However, surprisingly little analysis has been devoted to examining the basic parameters that make those transactions “vulnerable” in the first place.

“Sandwiching,” the practice of extracting value created by a swap or similar operation by surrounding it with trades on the same assets, remains a major issue for transactions submitted openly via the mempool. Researchers at Eigenphi estimate sandwiches have yielded over $8 million in 30-day profits on Ethereum alone, which constitutes the bulk of all on-chain “maximal extractable value” or MEV.

While it is certainly possible to make transactions private or otherwise protect them from leaking value using the services outlined above, the continuing prevalence of sandwiching indicates that most users have yet to adopt them. In practice, the bulk of DeFi swaps are submitted directly via protocol frontends using default execution parameters (such as 0.5% max slippage on Uniswap). Whether this is due to unfamiliarity or a reluctance to rely on third-party services, we believe it indicates a need for a simpler solution. One such solution is intelligent trade structuring — optimizing both the number of trades and per-trade parameters — which can be implemented purely on DEX frontends with no additional trust assumptions or changes to infrastructure.

Recent work on game-theoretic sandwich prevention illustrates how size-dependent slippage limits can reduce anticipated losses for many Uniswap traders (some by an order of magnitude or more). However, the broader design space requires answers to three questions:

• Single-swap parameters: How should a mempool trader set slippage limits to minimize expected losses on a single transaction?
• Optimal swap splitting: Within a single pool, how should a mempool trader split a single large swap into multiple parts executed across sequential blocks?
• MEV-aware DEX routing: Across multiple pools, how should a DEX aggregator account for MEV to minimize expected end-to-end losses?

In our recent note, we present a theoretical framework to address the first and second questions, simplifying the problems to a set of closed-form solutions. First, we show how to set parameters for a given trade size to balance expected losses from execution (e.g. transaction failures and gas costs) with losses from extraction such as sandwiching. Second, we show that, given a concave value function where slippage increases with size (e.g. constant-product DEXes such as Uniswap and Curve), the optimal solution is to split a large block trade into equally-sized trades across sequential blocks, with the exact size determined by the value function.

While the current piece is theoretical and preliminary, we welcome both implementations of and extensions to our framework. Future work could include extensions to smaller swaps, where per-trade gas constitutes a larger fraction of wealth, and work that generalizes multi-block swaps to multiple pools. More broadly, we encourage DeFi builders to approach swap market efficiency from both sides, helping users express intelligent front-end defaults while continuing to improve market design and architecture. As volumes increase, applications mature, and adoption widens, it will become increasingly important to give users the tools to transact efficiently no matter their level of sophistication or experience with the nuts and bolts of crypto.