Measuring the impact of hidden DEX costs

How RFQ protects users from MEV-induced slippage.

April 14, 2022

Under the Hood

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.

Fig. Slippage type distribution across Swap API trades

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.

Fig. Slippage type distribution across AMM pools

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.

Fig. Slippage tolerance distribution across Swap API trades

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.

Fig. Slippage tolerance distribution by Swap API affiliates

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.

Fig. Trade slippage histogram (capped at 10%, log scale)

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.

Fig. Trade slippage histogram by trade size (capped at 10%, log scale)

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.

Fig. Average trade slippage by trade size and pair (capped at 3%)

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.

Fig. Slippage exhaustion histogram (slippage capped at 3%, log scale)

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.

Fig. Slippage exhaustion likelihood by trade size (slippage capped at 3%, log scale)

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.

Contents

Subscribe to newsletter

By submitting you're confirming that you agree with our Terms and Conditions.
Yay! You’re signed up.
Oops! Something went wrong, but it's not your fault.

Up next

Fundamentals: SocialFi

Nov 26, 2024

Unlock powerful onchain insights with 0x Trade Analytics API

Nov 5, 2024

Fundamentals: Smart Contract Wallets

Oct 15, 2024

Compliance made easy with 0x Address Screening

Sep 26, 2024

0x's next-gen pricing engine is now live

Sep 25, 2024

Introducing state-of-the-art Buy/Sell Tax support

Sep 4, 2024

Take control of your balance sheet with 0x v2

Aug 15, 2024

0x v2 bug bounty program

Jul 30, 2024

What does the "best price" in DeFi really mean?

Jul 23, 2024

Eliminate allowance risk with Permit2

Jul 17, 2024

Introducing 0x's next-gen pricing engine

Jul 15, 2024

0x Dev Digest: May 2024

May 31, 2024

Frame spotlight: Paycaster

May 21, 2024

Frame spotlight: Airstack

May 9, 2024

Power up your Farcaster Frames with 0x swaps

May 2, 2024

0x Dev Digest: April 2024

Apr 30, 2024

Introducing 0x Trade Analytics

Mar 12, 2024

Coinbase Case Study

Jan 30, 2024

Introducing gasless swaps and approvals with Gasless API

Jan 22, 2024

Bitcoin ETFs have arrived

Jan 12, 2024

Building in the open: 0x pricing update

Dec 11, 2023

Matcha leverages Gasless API to bring users the most frictionless trading experience in DeFi

Nov 30, 2023

0x Dev Digest: October 2023

Nov 2, 2023

Monetize crypto trading in your app with Swap API

Oct 26, 2023

0x Dev Digest: September 2023

Oct 3, 2023

A comprehensive analysis of RFQ performance

Sep 26, 2023

Unlock optimal trades in Swap API with 0x RFQ liquidity

Sep 20, 2023

0x Dev Digest: August 2023

Aug 31, 2023

Portal launches swaps in its white label MPC wallet powered by 0x

Aug 16, 2023

0x Swap API is now live on Base

Aug 9, 2023

Introducing paid plans for Swap API

Jul 24, 2023

Decreasing Frictions in DeFi hackathon recap

Jul 12, 2023

0x's pricing principles

Jul 3, 2023

0x Dev Digest: June 2023

Jun 30, 2023

App spotlight: tastycrypto

Jun 27, 2023

App spotlight: 31Third

Jun 22, 2023

0x 101: Intro to gasless API

Jun 13, 2023

Inspiration for building with Swap API

Jun 8, 2023

0x Dev Digest: May 2023

May 31, 2023

Fundamentals: What are gas fees?

May 25, 2023

Decreasing Frictions in DeFi Hackathon

May 12, 2023

Swap API liquidity management

May 18, 2023

0x 101: Getting started with Swap API

May 16, 2023

0x 101: Intro to Swap API

May 9, 2023

0x 101: Intro to 0x Orders

May 4, 2023

0x 101: Intro to 0x Protocol

Apr 27, 2023

A new home for 0x Protocol

Apr 24, 2023

Say hi to the new 0x

Apr 20, 2023

0x Year in Review 2022

Jan 5, 2023

0x Swap API expands to Arbitrum

Sep 22, 2022

Managed liquidity

Apr 23, 2020

0x Smart Order Routing

May 19, 2020

App spotlight: Taho

Mar 8, 2022

Fundamentals: What is a Layer 2 chain?

Apr 19, 2023

Fundamentals: What is the difference between quoted, executed, and adjusted prices?

Apr 19, 2023

Fundamentals: What is price impact?

Apr 19, 2023

Fundamentals: What is slippage?

Apr 19, 2023

Fundamentals: What is an automated market maker (AMM)?

Apr 19, 2023

Fundamentals: What is market making?

Apr 19, 2023

Fundamentals: What is a DEX aggregator?

Apr 19, 2023

Fundamentals: What is liquidity?

Apr 19, 2023

Fundamentals: What is a decentralized exchange (DEX)?

Apr 19, 2023

0x at ETHDenver 2023

Mar 21, 2023

The 0x Mission and Values

Jun 7, 2018

Announcing support for new testnets

Aug 10, 2022

0x Swap API expands to Binance Smart Chain

Mar 17, 2021

Scaling DeFi — Layer One

Sep 1, 2021

Introducing Slippage Protection

Jul 14, 2022

San Francisco Blockchain Week 2022 Recap

Nov 21, 2022

0x Swap API adds new liquidity sources

Jul 11, 2022

Review of slippage performance

Sep 14, 2022

Phuture case study

Oct 20, 2022

Market making in DeFi

Aug 12, 2021

Introducing 0x Labs

Jun 22, 2020

Introducing 0x Explorer

Oct 26, 2022

Growing DeFi with professional market makers

Aug 26, 2020

0x 101: How to Access 0x Data

Apr 25, 2023

GameStop chooses 0x Swap API

Jul 8, 2022

Build on Base with 0x

Feb 23, 2023

A comprehensive analysis on DEX liquidity aggregators’ performance

Oct 1, 2020

Announcing 0x Swap API v1

Oct 1, 2020

Access all DEX liquidity through 0x Swap API

Jan 28, 2020

Announcing the 0xpo Summit 2022

Aug 24, 2022

0x Protocol, a preview of what’s to come

Mar 16, 2023

Update to our Privacy Policy

Mar 14, 2023

Price Impact Protection has arrived

Dec 14, 2022

0x Limit Orders Go Multi-Chain

Dec 23, 2021

0x Labs raises $70M Series B led by Greylock to continue expanding Web3’s core exchange infrastructure

Apr 26, 2022

0x launches Tx Relay API in beta, with Robinhood Wallet as first partner

Mar 1, 2023

0x Labs raises $15M Series A to bring decentralized exchange markets to a global audience

Feb 5, 2021

App spotlight: Zerion

Jun 22, 2022

App spotlight: Matcha

Nov 24, 2021

App spotlight: DexGuru

Jun 17, 2021

App spotlight: DEXTools

Sep 23, 2021

App spotlight: DODO

Aug 10, 2021

App spotlight: DappRadar

Dec 16, 2021

App spotlight: DeFi Saver

Jul 20, 2021

0x + Brave partner to make crypto and DeFi more accessible to everyone

Jul 7, 2021

0x Swap API now supports 0x Protocol v4

Mar 1, 2021

0x Swap API is now available on Fantom

Oct 26, 2021