In this report we peel back the curtain on slippage - we take a look at what slippage is and dig deeper into 0x Swap API data to quantify its impact. In analyzing the extent of slippage experienced by DEX users and in which circumstances it’s more likely to occur, we determine when it’s safer to offer alternative settlement methods, such as RFQ, when slippage is expected.

If you’ve used a DEX product, you might have noticed that sometimes the amount received in your wallet is different from the original quote shown in the app when preparing the trade. How’s that possible? Enter the world of slippage.

This slippage is de facto a ‘hidden price impact’ that users experience when trading against an automated market maker (AMM). The last 12-24 months have seen explosive growth in DEX trading, fueled by an influx of users utilizing self-custodial wallets and dApps. With that retail usage has come more opportunities for sophisticated market participants to seize. As a DEX aggregator, it is 0x Labs’ mission to provide the best prices to users, so it became imperative to look deeper into the effects these actors have on the market.

In this report, we dig deeper into 0x Swap API data to quantify the impact of slippage and outline our findings. The purpose of this study is to answer the question: is there any model we can build to reasonably estimate when - and by how much - slippage will occur? We are obviously interested in extracting the non-random slippage. In other words, can we reasonably estimate how likely a trade is to be MEV-attacked?

What is slippage?

When trading against an AMM, the price quoted in the UI typically reflects the liquidity pool distribution and fees at quote time. After confirmation, the trade enters a limbo state in the Ethereum transaction mempool where other awaiting transactions could be targeting the same liquidity pool, altering its state, and, ultimately, the price your transaction is settled (i.e. mined) at.

Any transaction modifying the state of the same liquidity pool you’re targeting will result in a slightly different price than the one you were quoted. In other words, the realized price can differ from the quoted price after you submit your transaction on chain.

The concurrency of transactions targeting the same liquidity pools and their sequencing is what ultimately causes slippage. Typically, users are not aware of each other’s concurrent trading, and this results in an equal likelihood of positive or negative slippage (ignoring other market effects for simplicity). However, there are some actors that are actively watching the sequencing of transactions and participating in re-ordering of the transaction prior to block mining in order to seize opportunities. That is, they will actively trade against you, and thus you will experience negative slippage.

We will not go into too much detail on the mechanics of MEV attacks (sandwich attacks) in this report, but there are several technical deep dives available on the topic. If interested, we recommend this deep dive (more resources here and here).

Below is a distribution of trades against AMMs with their corresponding slippage:

First, you can see that the largest slippages are encountered at times with larger price action, which is somewhat expected. At the same time, you can see that there are some trades (in red) that typically result in negative slippage (below the zero line), typically settled via flashbots. These trades result in fewer tokens for the users than previously quoted.

Based on the data described in the following sections, we quantified that in 2021, ~33% of all Swap API trades resulted in negative slippage, while ~17% experienced positive slippage (i.e. the user got a better deal than quoted). This imbalance helps us formalize the hypothesis that this is the fruit of the action of active market participants.

This phenomenon is not unique to Swap API - every DEX product is affected by it, as long as the trade is settled on a public AMM on public mempools.

The role of slippage tolerance

Slippage tolerance is a parameter that determines the worst acceptable price for a trade. The transaction reverts if the resulting price is worse than this threshold. Without this constraint, nothing would stop bad actors from front-running trades and driving the price up to absurd values, especially on illiquid trading pairs.

This parameter is typically found in the ‘settings’ section of DEX or Aggregator UIs. For example, here is where you can find slippage tolerance in Uniswap and Matcha:

Note that for each DEX trade its negative slippage is capped by the slippage tolerance set by the trader, while the positive slippage can go up to infinity given random trade collision. For example, this particular user enjoyed 8 ETH of positive slippage on a $90k trade. We calculated that approximately $600k was returned to users by Swap API in 2021 (applications using Swap API return this quantity entirely to their users).

Modeling slippage behavior in relation to other parameters

It is most likely impossible to produce a perfect model to estimate slippage. However, we can make reasonable assumptions on how we expect slippage to behave based on certain indicators.

There are multiple factors contributing to price movement: the AMM fee (or LP fee), the price impact (dependent on the liquidity depth of the pool), and the on-chain slippage. While the first two can be reasonably estimated and are deterministic at the time of the quote, the slippage is uncertain.

In June, we posted the following graph, speculating about the possible distributions of slippage for AMM liquidities. The goal of this research is to explore the slippage distribution from a real dataset and potentially validate the assumption of the impact of MEV attacks on this distribution.

The following hypotheses seem plausible without looking at the data:

• Slippage tolerance represents the ‘attack domain’ that an attacker can play with.
• Slippage will be low on small trades. The price impact is low, and thus less sensitive to the pool’s ratio, and arbitrage opportunities are heavily limited by the gas price and pool fee.
• As a corollary to the above, the slippage probability will go up when the trade size increases.
• Trades with near-maximal slippage are likely attacked by MEV bots, as bots' way of operating attacks is to push the return amount of pending transactions as close to the slippage tolerance as possible while not reverting.

Dataset and exploratory stats

The dataset used in this report includes over 673k Swap API trades that occurred between April to November 2021 on the Ethereum blockchain. A significant portion of these trades was sourced from AMMs, especially from Uniswap v2/v3 and Sushiwap, and therefore potentially subject to slippage.

For each trade, we collected 3 data points necessary to perform the slippage estimations, along with various “metadata” such as token price, symbol and decimals.

1. Worst acceptable price — decoded from the on-chain calldata
2. Quoted price — from the Swap API internal database
3. Realized price — decoded from the on-chain event logs

Knowing the worst acceptable price and the price quoted by the Swap API, we can compute the slippage tolerance and compare it with the actual settled amounts.

Note that Swap API compares across both on-chain AMM liquidity sources and Request for Quote (RFQ) quotes from private marker makers. We include RFQ trades in the result overview but exclude them from the detailed negative slippage discussion, as all RFQ trades have zero slippage by design.

Positive vs. negative slippage

The first natural question to answer was: how often does the slippage occur? We observed that ~50% of all Swap API trades had zero slippage (including ~4.2% RFQ trades whose slippage are zero by design), while ~17% experienced positive slippage (i.e. the user got a better deal than quoted). The remaining 33% of trades resulted in negative slippage. The focus of our analysis will be in this latter group.

The three AMMs most commonly used were Uniswap v2, Uniswap v3, and Sushiswap. We observed that the rough slippage distribution buckets were not significantly different, apart from higher positive slippage on Uniswap v2 and a slightly higher negative slippage experience on Uniswap v3. This data in itself isn’t sufficient to draw conclusions. We need to break it down by slippage tolerance and, most importantly, by volume traded.

Slippage tolerance

Of interest to our analysis is what slippage tolerance values are selected by apps and their users. This consideration is important for the subsequent analysis.

We can see that slippage tolerance values are usually round, which means that users of Swap API integrators seldom change the slippage settings on their platform of choice. The largest chunk of trades had slippage tolerance equal to 3%, while most of the trades at 1% came from Matcha (along with the 0.5% trades, as Matcha’s slippage default was changed in May 2021). Overall, very few Swap API trades have custom slippage settings (typically set beyond 3%), which will also become evident when looking at the slippage distribution.

Slippage histogram

The following chart contains the raw distribution of frequency of slippage in the dataset. We decided to cap the slippage histogram plot at 10%, as over 99.5% of all trades fall in this range. Both the sharp drop on the left and asymmetrical distribution were expected since we have already seen that over 95% of all trades have max slippage capped at 3% or less.

The positive slippage on the right side follows a power-law distribution (the y-axis is in log scale). It is worth reiterating that these are trades where users got a better deal than originally quoted, as Swap API doesn’t extract positive slippage from their users. The negative slippage distribution, on the other side, shows an interesting pattern.

Near zero, we can observe that the frequency on the negative side is a bit larger than on the positive. This is most likely due to “trade collisions” - multiple traders accessing a pool’s liquidity and settling trades, which affects each other’s trades.

What is also evident, and more important, is the presence of upticks at specific points [-0.5, -1, -2 and -3], which represents the trades where slippage reached its limit because of MEV activities. This pattern becomes even more evident when the data is broken down by trade size. The higher the trade size, the more prominent the spikes, while the smaller the trade size, the smoother the distribution.

These upticks are not as pronounced for trades greater than $100k, probably due to a combination of lower data sample size and the competitiveness of RFQ liquidity (with zero slippage) in that trade segment. We will come back to this pattern in the next section.

We also compared the average slippage between markets, focusing on the top 6. In the chart below, the x-axis shows different trade size buckets and the y-axis shows the average slippage (capped at 3%, including the positive range). The bubble size indicates the sample size for reference.

It’s clear from the chart below that the higher the trade size, the higher the chances that the trade will experience a MEV attack that will result in negative slippage. The DAI-WETH market seems to be the most affected in the period of reference.

Slippage exhaustion and MEV

In the previous section, we noticed frequency upticks at specific slippage points: 0.5, 1, 2, 3. You guessed it, these are the slippage tolerance set by the users! It is reasonable to assume that in those instances a MEV attacker purposely moved the price to the maximum allowed by the slippage tolerance in order to capitalize on the opportunity at the expense of the user.

In order to get a better view of this phenomenon, we normalize the slippage axis and consider a metric called slippage exhaustion, defined as (slippage)/(slippage tolerance).

When slippage exhaustion approaches 100%, it means the trade settled exactly at the user’s worst acceptable price, which can be considered as an intended outcome. When plotting the negative slippage distributions using this metric, an interesting pattern emerges.

We can see that the actual distribution of this metric aligns with our hypothesis. MEV attacks are usually designed to extract all value from the trade, moving the price to the worst acceptable price, resulting in a sharp uptick on the right side of the chart. On the other hand, most of the trades are not the target of MEV bots, even if there is value left on the table.

In fact, MEV attackers need to consider other factors before initiating an attack, with price impact and gas price being the predominant factors. Typically, the larger the trade size, the more likely it is that an attack is profitable and worth taking. Breaking down the chart above by trade size seems to confirm this hypothesis. In this case, we divided the slippage cases by total number of trades in the bucket of reference to uniformize the sample.

In-depth analysis of MEV behavior is beyond the scope of this article. However, we examined a subset of over 5,000 Matcha trades with the largest slippage for potential value extraction (the default slippage tolerance on Matcha is 0.5%). We employed a naive heuristic classifying a swap as “sandwiched” if the sender’s address of the preceding and following transaction in the block are the same to find that over 90% of trades with slippage in the interval [0.49%, 0.5%] were MEV attacked and very little other trades.

Turning data into more value for users

We didn’t stop at this analysis. Once we discovered the extent of slippage experienced by DEX users, and in which circumstances it’s more likely to occur, we knew we had a way to do something about it.

Since then, we turned this one-off analysis into always-on monitoring of AMM slippage, which computes coefficients we plan to leverage to calibrate our aggregation, so as to return the best deal to Swap API applications and their users.

Thanks to this data, we will be able to determine when it’s safer to route trades to RFQ liquidity, which comes with zero slippage. According to our most recent data, in 5% of trades above $1,000, users would have gotten a better deal by getting an RFQ quote but instead suffered AMM slippage. The math can be difficult to explain as sometimes a seemingly good quoted price can hide a fee. Refer to the following chart. Even if the AMM quoted price is better than the RFQ one (green), in certain instances slippage (red bar) could turn that into a worse deal for the user.

The good news is that we plan to automate this evaluation for all users of Swap API applications. This methodology is already being tested in Matcha, where slippage is taken into account when recommending the best route. In addition, we are planning to introduce new experiences that will make that calculation transparent and clear to users.

At 0x Labs, we use data to push the envelope in terms of understanding DEX markets, providing better prices for users and following through on 0x’s mission of building a tokenized world where all value can flow freely. Stay tuned for further updates on our research around slippage. In the meantime, traders can benefit today by using Swap API-powered apps, including Matcha. Looking to integrate swap functionality into your app? Check out our developer docs to get started.