Article and Paper by Max Holloway (@max_holloway)

tl;dr Nontoxic orderflow creates immense value for LPs of the Uniswap Protocol, both from nontoxic orders’ fees and from the fees paid by sandwich orders surrounding many of these nontoxic orders. Still, we recommend that the protocol should not incentivize nontoxic orderflow until the protocol generates revenue.

The Uniswap Foundation has earmarked 35% of their grants budget to incentivize protocol growth. One possible mechanism for incentivizing this growth is by rewarding users and user interfaces for the trades they route to the protocol. Before incentivizing orderflow, it is essential that the Uniswap Foundation estimate the value of this orderflow. We have conducted research that aims to answer precisely this question: how much should the Uniswap Protocol value orderflow?

We specifically focus on the value that nontoxic orderflow generates for the protocol. To do this, we traverse a lot of ground: formalizing a definition of nontoxic orderflow, determining the impact of sandwich attacks on this value, and much more. We provide all of this information in a paper, and this post covers some of that paper’s fundamental concepts and interesting results.

Defining (non)toxic orderflow

To understand orderflow toxicity, let's begin with a simplified example. Suppose Alice is selling apples at $1/apple, and she does not have access to external price information. Now suppose that a gnarly storm blows through the farms of all of Alice's neighbors, and they are no longer able to sell their apples. A savvy apple trader, Bob, gets access to this information before Alice, and he realizes that the "true" price of these apples is now $2/apple; Bob then immediately buys as many of Alice's $1 apples as he can, and he sells them elsewhere for a profit. In this example, Bob makes a low-/no-risk profit, due to the fact that Alice has worse access to information. If Alice knew that she could raise the price of her apples, with low/no-risk of selling fewer, then she would be able to make the profit that Bob made. Bob's apple order embodies the concept of toxic orderflow.

By analogy, we can apply this same notion of toxic orderflow to Uniswap. Alice is a liquidity provider, Bob is an arbitrageur, apples are tokens, and the news of the storm is equivalent to the price of a token being different on another trading venue. A common example of toxic orderflow on blockchains is the CEX/DEX arbitrage, where a trader places a buy (sell) order on a centralized exchange while simultaneously placing a sell (buy) order on a decentralized exchange, in anticipation of a higher sell price than buy price buy price. This orderflow is toxic for LPs, who would quote a different price if they were aware of prices on external venues.

To measure orderflow toxicity, we utilize the markout metric, which tells us the short-term profitability of the trade from the LPs' perspective. This is a common metric in HFT market making, and it has also been utilized in multiple analyses of Uniswap LP profitability. In our paper, we demonstrate that the expected LP markout from nontoxic orders is at least as large as the fee paid to the LPs, and we also find that a lot of volume comes from a phenomenon called sandwich attacks.

Sandwich attacks

Sandwich attacks consist of a front- and back-running, which pump up the price before another trade and arbitrage it back down to it's pre-pump price for profit. To illustrate this, we give a simplified Uniswap V2 example.

Suppose there are two assets, A and B, in a constant-product pool, and the pool has zero LP fee. The initial reserves are 10 of A, 10 of B. Then a swapper, Charlie, places an Ethereum transaction through the public mempool (e.g. by placing the transaction on MetaMask with default settings) on the pool, stating "give me as many B as I can get for 1 A, and I am willing to receive a minimum of .5 B". If Charlie's swap was incorporated into the next block before any other pool transactions, then Charlie would get 0.909 B. However, since Charlie placed the order through the Ethereum mempool, an adversarial trader, Dan, can sell A before Charlie, then buy A after Charlie, to realize a profit. In this example, if Dan sold 3 A in the front-run transaction, then Charlie would only get 0.55 B back, rather than the 0.909 B that he would get back if he were not front-run. Sandwich attacks are bad for users! On the other hand, sandwich attacks are great for LP revenues.

Like any other Uniswap transactions, the front- and back-run transactions in a sandwich attack are required to pay fees. Add to this the fact that typical sandwich attacks have nearly identical front-run and back-run transaction sizes, we find that sandwich attacks pay fees while not substantively changing the pool reserve/position state. In plain English: LPs make revenue from sandwich attacks, while not taking on additional price risk.

Furthermore, sandwich attacks' benefit to LPs is not just theoretical. We find that from July 1 through Dec 31 of 2022, over 13.59% of volume on the Uniswap V3 USDC-ETH-0.05% pool on Ethereum was front-/back-run volume; over 26.80% of volume on the Uniswap V3 ETH-USDT-0.05% pool was front-/back-run volume.

We estimated the percentage of Uniswap volume that is nontoxic, and we found that for every dollar of nontoxic orderflow (e.g. retail orderflow), there is, on average, $0.6969 of sandwich orderflow, for the USDC-ETH-0.05% pool; we call this value the sandwich multiple, since it gives us an estimate for how much front-/back-run volume is created for each unit of non-sandwich nontoxic volume.

This result is particularly interesting in the context of a potential incentive program. The value of nontoxic orderflow to Uniswap LPs is not just the value from fees paid by a nontoxic order, but also the value from the fees paid by the front- and back-run transactions surrounding a nontoxic order.

The value of nontoxic orderflow

We utilize a hypothetical protocol fee to determine the revenue that the Uniswap protocol would expect to receive for each unit of nontoxic orderflow, including both the fees paid by nontoxic orders and their sandwich counterparts.

If/when protocol fees are turned on, we can use this revenue metric as a proxy for value to the protocol. But since there is no protocol fee, our revenue metric would suggest that we should not value nontoxic orderflow to the protocol.

Is it fair to say that nontoxic orderflow generates zero value for the protocol? We believe that the answer is yes, or at least nontoxic orderflow does not carry a meaningful enough value to be incentivized unless that orderflow generates revenue. Our reasoning boils down to the following: (a) there is no apparent benefit to incentivizing nontoxic orderflow earlier rather than after there is protocol revenue, and (b) incentivizing nontoxic orderflow currently has limited opportunity for flywheel/feedback loop effects, due to the small addressable market of liquidity-sensitive nontoxic orderflow.

Conclusion

We covered a lot in this post, and these are only summaries of the important results from our research. See our paper for much greater depth on topics like optimal Uniswap V3 sandwich computations, interface-disaggregated orderflow toxicity, orderflow<>liquidity feedback loops, orderflow incentive mechanism design, and further analysis on sandwich attacks.

Only after conducting this full analysis were we able to reach our main recommendation: the Uniswap Foundation should wait until the protocol generates revenue before incentivizing orderflow. Specifically, the 35% of grants budget that was earmarked for incentive programs should be allocated to other efforts or returned to the protocol treasury.

With better information comes better decision-making. There is a wealth of information to be gained from further research on Uniswap’s orderflow. In this report, we married data and theory to determine the value that nontoxic orderflow can create for the protocol, which can be utilized by the community once the protocol generates revenue. We hope that the Uniswap community can harness these results to thoughtfully and sustainably grow the protocol in the future.

Links. Research Paper and Research Code.

Credit. Thanks to the following individuals for their help in reviewing this research: @eljhfx, @AlanaDLevin, @thiccythot_, @0x94305, @_julianma, and @raholloway. And thank you to the Uniswap Foundation (@UniswapFnd) for subsidizing this research!

Disclosure. The author(s) do not own UNI token, nor are they affiliated with Uniswap Labs or any of its affiliates. This research was funded by a grant from the Uniswap Foundation. Any opinions or results stated here are those of the author(s), not of the Uniswap Foundation or its affiliates. Henceforth any mention of “Uniswap” is in reference to the Uniswap Protocol, unless explicitly stated otherwise. Nothing in this paper should be construed as financial advice or trading advice.