Understanding Optimal Swap Behavior for Mempool Transactions
May 23 2023 _ 3 min read
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.
Lucas is an investor and researcher at Jump, where he focuses on protocol and mechanism design, tokenomics and governance, decentralized identity, and core L1/L2 blockchain infrastructure..View All Posts (6)
Nihar is a Researcher focused on token & mechanism design. His work has been cited in the Financial Times, Fortune, and many podcasts. He has a PhD in Economics and worked on the Libra/Diem project..View All Posts (13)
Alex is a researcher at Jump Crypto, focusing on infrastructure and protocols..View All Posts (1)
Suraj is a quantitative researcher at Jump Crypto currently focused protocol design. Previously, he studied math and computer science at MIT while researching control algorithms for soft robotics..View All Posts (1)
Stay up to date with the latest from Jump_
SAFU: Creating a Standard for Whitehats
Whitehats and DeFi protocols need a shared understanding of security policy. We propose the SAFU - Simple Arrangement for Funding Upload - as a versatile and credible way to let whitehats know what to...
Oct 24 2022 _ 17 min
Stop the Chain! CosmWasm Stack Overflow
This post announces a vulnerability we discovered in CosmWasm, a smart contract platform written for the Cosmos ecosystem. The vulnerability was a stack overflow, which would have allowed users who ca...
Jun 01 2023 _ 1 min
The information on this website and on the Brick by Brick podcast or Ship Show Twitter spaces is provided for informational, educational, and entertainment purposes only. This information is not intended to be and does not constitute financial advice, investment advice, trading advice, or any other type of advice. You should not make any decision – financial, investment, trading or otherwise – based on any of the information presented here without undertaking your own due diligence and consulting with a financial adviser. Trading, including that of digital assets or cryptocurrency, has potential rewards as well as potential risks involved. Trading may not be suitable for all individuals. Recordings of podcast episodes or Twitter spaces events may be used in the future.