This article looks at the mechanics of CEX/DEX arbitrage trading, focusing on the AMM side of the execution, and aims to demonstrate the relations between block times, block basefees, and the actors participating in these trades — LPs, searchers, and others. It includes simulation results with available source code.
An updated and more formal version of this article is available at Eth Research forum.
It’s widely recognized that CEX/DEX arbitrage trades create a large part of DEX volume, perhaps even the majority of that volume. The Loss Versus Rebalancing (LVR) model¹ stands out as a key tool for quantifying and modeling this arbitrage volume from a theoretical perspective. However, the research focusing on LVR so far has mostly ignored transaction cost as a parameter in CEX/DEX arbitrage.
It is also is subject to misconceptions and misunderstandings. For instance, several research papers state (or imply) the assumption that LP losses from arbitrage trading grow with the square root of the block time. This comes from modeling LVR in idealized settings. Yet, works that actually run the simulations (like this one) often reveal minimal impact from shorter block times. How do we reconcile these differing results and bridge the gap between theory and practice?
Arguably, much of the difference comes from the assumption that arbitrage is a two-player, zero-sum game, as typically modeled in LVR research. However, this assumption is invalid in the post EIP-1559 world, where transactions cannot be free. Each arbitrage trade not only divides profits among the searcher, builder, and proposer (SBP, as referred to later in this article) but also burns some ETH, contingent on the blockspace demand at the time of the arbitrage. To borrow a term from physics, the basefee introduces a friction in the process. This friction eliminates a significant portion of potential trades, and reduces LP income.
¹ — Personally, I’d prefer to call it CVR (cost versus rebalancing), since there are no real entities that have loses accurately quantified by LVR in a real-world DEX. Instead, a key question DEX designers and LPs can consider is what % of the nominal LRV they are exposed to, i.e. the part of LVR that is actually the expected loss for the LPs in a model where the DEX is only used by arbitrage traders. That said, I’ll stick to using LVR in this article, to avoid more confusion.
Price action example
Let’s look into the mechanics of arbitrage in detail. The figure below illustrates a typical state in a DEX pool after the price has changed on a CEX enough to potentially attract arbitrage.
The figure below shows the state after the arbitrage trade. The DEX price has shifted from P_Old to P_DEX, and the LP has sold their assets at the price of P_Sale, which represents the geometric mean between the two prices. The new DEX price still slightly deviates from the CEX price but remains within the non-arbitrage region. Consequently, further trades will not occur unless the CEX price increases slightly or decreases significantly enough to fully cross the non-arbitrage threshold and then some.
Wait a minute — the figure still isn’t fully correct!
What will happen if the CEX price will increases by a 0.001%, now? The trade will not happen. This is because on both sides of the non-arbitrage gap created by the pool’s swap fee there is a friction region, created by the blockchain’s basefee and other factors, including the CEX fees (if any), priority fees and bribes to the block proposers, arbitrager’s predictive accuracy and risk tolerance, and so on.
For the purposes of this article, the block basefee is assumed to create most of that friction, and the other factors ignored. The friction created by the base fee is predictable by the arbitragers, and they aren’t likely to ever create any swaps where the expected profit is negative after subtracting the next block’s expected basefee.
Analyzing the single-trade LVR
The difference between the CEX and DEX quoted prices triggers the arbitrage trade. However, the single-trade LVR is not directly proportional to that price difference. Instead, it is proportional to the difference between the trade execution prices on the CEX and the DEX.
Moreover, the single-trade LVR is distributed among three entities:
- Liquidity providers
- The searcher, block builder, and block proposer (SBP) as a collective entity
- Holders of ETH, due to the ETH burned in the transaction.
LPs receive the swap fee, while the SBP collects the arbitrage profits, which are subsequently divided among these three actors. It’s no surprise that integrated searchers-builders dominate the arbitrage market, as for them it is simpler to divide up the profits.
ETH holders do not directly receive compensation, but burning the basefee creates deflationary pressure on ETH as an asset.
High volatility increases the likelihood of price jumps, and as result, arbitrage transactions. Furthermore, it also makes the expected size of a jump larger. The % of the trade taken as LP fee is typically not linked to volatility, resulting in a less equitable split for LPs when volatility rises.
By comparing the single-trade LVR with the LP fees from that trade, we can assess the fairness of the trade to the LP. In a scenario where price evolution is smooth without any jumps, the LP fee nearly recoups the LVR, and the LP loss is minimal. However, if the DEX-to-CEX price difference fluctuates due to block time granularity or actual price discontinuities on the CEX, the LP fee becomes smaller than the LVR, resulting in some loss for the LP against this (theoretical) rebalancing strategy.
Example scenarios
Let’s model the in-range liquidity of the Uniswap v3 ETH/USDC 0.05% pool. As of April 2024, it has approximately $1 billion worth of virtual assets, corresponding to approximately $150 millions of real assets, giving liquidity concentration factor of 6 to 7. It is essential to have deep liquidity if we want the arbitrage trades to happen even on relatively small price changes.
A simple Uniswap v3 swap might consume around 150 000 gas, which corresponds to $10 cost per swap in USD terms, assuming a reasonable 22 gwei basefee cost and $3000 ETH/USDC price. In times of high usage or high volatility, the cost can easily increase several times.
Example 1
Let’s say the starting ETH price is $3000 both on the CEX and the DEX.
First, let’s look at what happens when the price changes +0.1% in the CEX. The CEX price now is $3003, which is out of the non-arbitrage region. The arbitrager computes the DEX target price P_T, equal to 3003 · 0.9995 due to the pool’s 0.05% fee, and swaps some USDC for ETH on the DEX to raise the DEX price to the target. The amount to swap is defined by the liquidity L and (virtual) reserves x and y in the pool:
This returns the amount without fees, to get the input amount with fees the result must be divided by 0.9995 (for the 0.05% pool).
The LVR is computed from the deltas and the CEX price P_C:
The LVR is then divided in the LP fee part, SBP profit part, and the block basefee which does not depend on the particulars of the transaction, except its gas cost:
If the estimated SBP profit is positive, the trade likely happens, otherwise it does not.
For the example pool with $1B worth of virtual assets, the LVR of the swap is $93.66 and the LP fee is $62.46, leading to 33.3% of the nominal single-trade LVR being realized as the LP loss. Approximately on third of that loss comes from the $10 block basefee.
Example 2
Keep the same assumptions, but let the CEX price change by 1% instead.
In this scenario, the LPs do capture an impressive fee of $1184.66. However, the single-trade LVR grows even faster, to $12406.47, meaning that the LP losses constitute 90% of the nominal LVR.
This shows that the LP losses scale super-linearly with the price change. The price increases by a factor of 10 (0.1% vs 1.0%), but the LP losses increase by a factor of >360 ($31.19 vs $11221.81).
Example 3
From the previous example, it follows that the LP is better off if they can take trade more gradually, rather than all at once.
Let’s consider a short-block world where the price changes by +0.1% two times (i.e. from $3000 to $3003 and then to $3006), and a long-block world where it changes by +0.2% at once.
The LP fee is $187.39, the same in both situations. (The trades are path-independent since we assume non-compounding fees.) However, the LVR is higher in the second.
Specifically:
- for short blocks, the cumulative LVR is $343, and LP loss is 45.4%.
- for long blocks, the cumulative LVR is $468, and LP loss is 60.0%.
Example 4
Finally, let’s consider an example with oscillating prices. First, the price changes by -0.1%, then increases to +0.2% from the starting price. In the short-block world, the LP is able to take two trades — both the price drop and its reversion — while in the long-block world, the LPs only take a single trade.
The results are:
- for short blocks, the cumulative LVR is $843, the LP fee is $312, and the LP loss is 63.0%.
- for long blocks, the cumulative LVR is $248, the LP fee is $187, and the LP loss is 60.0%.
This example shows that LVR is a counterintuitive metric. In the short-block world, the pool has much higher volume and collects correspondingly higher fees. Moreover, the final price is the same, so the impermanent loss is equal in both worlds. Yet, both the realized LVR, and the LP loss as quantified by LVR, are higher in the shorter-block world.
Summary of the examples
To summarize the results:
- if the price can be modeled as a GBM process, both models point to the short-block world as a likely preferable, in aggregate.
- if the price follows some other pattern, for instance, oscillations around a mean, then shorter blocks are going to lead to worse outcomes according to the LVR model.
The summary of the outcomes for the LP is show in the figure above.
It’s worth stressing that using impermanent loss + fees as the metric results in very different outcomes from the LP perspective:
However, we know that for volatile pairs that follow the GBM assumptions, IL and LVR based models should eventually converge to the same result, since the expected value of LVR is equal to the expected value of IL. We need to move beyond the case-by-case examples analyzed so far. See the next section!
Simulation studies
The graphs below show the DEX performance metrics using random GBM simulations. The simulations assume 50% yearly volatility, which corresponds to approximately 2.6% daily volatility and 0.03% per-block volatility for 12-second blocks. This is the approximate volatility of ETH in the recent years.
The simulations run for 3600 seconds, and due to a coincidence, the LVR turns out to be approximately $1 per second or $3600 per hour². The LP losses in turn are in the range from $350 to $900 per hour ($3 to $8 million per year). To be clear, this theoretical model does not include any LP fees coming from noise / uninformed traders, which are expected to have zero LVR, and consequently to compensate for the LP losses from the arbitrage trades.
The results show that when the basefee is zero, the LP losses indeed can be more-or-less accurately modeled by the function sqrt(blocktime). However, this result stops being true after we introduce EIP-1559 basefees to the model, since more frequent transactions also burn more ETH, thus canceling out most of the positive impact on the LP fees — see the results below. Even adding a constant offset from the x axis to the sqrt(blocktime) model does not lead to a good fit (the brown line).
² — Due to the settings selected for the simulation, the results can be used as a rough and likely very inaccurate approximation of the Uniswap v3 USDC/WETH 0.05% pool on the mainnet. Analyzing the match and finding the largest reasons for discrepancies between the empirical performance could be a subject of further research.
Generalizing the results
- Generalizing to other pools. The simulation results are specific to the USDC/ETH 0.05% pool, which is typically the most liquid volatile pool on Uniswap v3. For pools with lower liquidity, the importance of the friction created by the basefee would be increased. For instance, let’s say that the ETH/USDT 0.05% pool has 1/3 of the liquidity. Then the results from $10 basefee on that pool would match those of the USDC/ETH pools with $30 basefee. For pools with higher liquidity (such as USDC/USDT and other stable pairs) the friction would be similarly decreased.
- Generalizing to other chains. The model assumes that shorter blocks simply divide the available blockspace differently, rather than add more blockspace. The simulation results would not generalize, and would look very differently if the block time decrease is accompanied with a proportional decrease in the base fee.
Replicating the theoretical results
(This is a more technical section that can be skipped by most readers.) While my simulations are not guaranteed to be accurate, they can be compared with the results from the paper “Automated Market Making and Arbitrage Profits in the Presence of Fees”. There are two main differences in the settings/assumptions between out works:
- The paper assumes frictionless transactions — no basefees or other costs for the arbitragers.
- The paper assumes Poisson-distributed block times.
Instead of redesigning the DEX simulations to incorporate non-uniform block times, I designed a separate function for “quick” simulations instead, which computes just the trade probability per block, not the other metrics. The results match the paper pretty well:
Poisson-distributed blocks, quick simulation
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, arb prob %: 96.7 85.5 74.6 49.6 22.6
block time 120 sec, arb prob %: 92.9 72.4 56.8 30.5 11.6
block time 12 sec, arb prob %: 80.7 45.5 29.4 12.2 4.0
block time 2 sec, arb prob %: 63.0 25.4 14.5 5.3 1.7 
When the function is changed to use uniform block times, the outcome is slightly, but not significantly different. The results from the full DEX simulation match the quick simulations reasonably well, giving confidence that it’s implemented correctly. (Or at least, with the same assumptions 😀):
uniformly distributed blocks, quick simulation
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, arb prob %: 98.1 90.5 81.5 54.2 23.6
block time 120 sec, arb prob %: 95.7 79.4 62.9 32.2 11.8
block time 12 sec, arb prob %: 86.7 49.5 31.0 12.4 4.0
block time 2 sec, arb prob %: 69.8 26.6 14.9 5.4 1.7
uniformly distributed blocks, full DEX simulation
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, arb prob %: 98.1 90.5 81.4 54.3 23.4
block time 120 sec, arb prob %: 95.7 79.5 63.0 32.2 11.7
block time 12 sec, arb prob %: 86.8 49.5 31.0 12.3 3.3
block time 2 sec, arb prob %: 69.9 26.7 14.7 4.8 0.3
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, LP loss %: 96.3 83.5 71.2 44.7 19.6
block time 120 sec, LP loss %: 92.0 68.8 52.1 26.6 9.8
block time 12 sec, LP loss %: 77.9 40.7 25.6 10.3 3.3
block time 2 sec, LP loss %: 58.5 21.9 12.3 4.4 1.4However, when adding the non-zero basefee, the positive impact from the shorter block times is massively reduced:
uniformly distributed blocks, full DEX simulation, $10 swap basefees
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, arb prob %: 92.7 85.2 76.4 50.5 21.7
block time 120 sec, arb prob %: 83.7 68.4 53.5 27.4 9.9
block time 12 sec, arb prob %: 53.1 29.9 19.1 7.7 2.0
block time 2 sec, arb prob %: 20.8 9.4 5.5 1.8 0.1
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, LP loss %: 96.3 83.5 71.3 44.8 19.6
block time 120 sec, LP loss %: 92.1 69.1 52.5 26.9 10.0
block time 12 sec, LP loss %: 80.0 44.2 28.3 11.6 3.8
block time 2 sec, LP loss %: 69.6 31.3 18.6 7.1 2.2
uniformly distributed blocks, full DEX simulation, $30 swap basefees
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, arb prob %: 88.8 81.5 72.8 48.1 20.8
block time 120 sec, arb prob %: 75.4 61.0 47.8 24.5 8.8
block time 12 sec, arb prob %: 36.2 21.3 14.0 5.8 1.5
block time 2 sec, arb prob %: 10.7 5.5 3.3 1.1 0.1
swap fee: 1bp 5bp 10bp 30bp 100bp
block time 600 sec, LP loss %: 96.3 83.6 71.4 45.0 19.8
block time 120 sec, LP loss %: 92.3 69.8 53.3 27.6 10.3
block time 12 sec, LP loss %: 82.5 48.5 32.0 13.5 4.5
block time 2 sec, LP loss %: 76.5 39.5 24.6 9.8 3.2 Implications for blockchain design
The “LP loss” curves in the DEX performance metric figures above clearly show that LP loss doesn’t actually increase proportionally to the square root of the block time, unless the basefee is zero. This isn’t a novel or unexpected finding, but simply a restatement of the principle that trading more frequently results in higher transaction costs. However, it could benefit from a wider dissemination, given that the sqrt-time model has become a common assumption.
To pick just one remarkable result in conflict with that assumption: according to the simulation results it is better to
provide liquidity in the 30 bps pool on a chain with 120-second blocktimes,
rather than to
provide liquidity in the 5 bps pool on a chain with 2-second blocktimes
if the basefee of a trade is equal to $10. The relative loss for the LPs is 26.9% and 31.3%, respectively. In the real world, the 5 bps pool might of course be better, but only if there is a sufficient volume from noisy / uninformed traders.
While it’s true that shorter blocks benefit LPs, the effect is limited and less significant than other factors (basefee, liquidity depth, pool’s fee tier, and potentially others). More compelling arguments for fast block times may stem from the perspective of traders — as faster confirmations improve trading user experience — or from the other actors, such as smaller block builders, who would get more opportunities to win proposer auctions in a short-block environment. However, short block times also create clear centralization risks: increased network bandwidth and latency requirements for network validators; increased processing requirements; greater importance of geographical proximity; and overall design move towards HFT. Needless to say, alternatives exist that could reshape the entire debate depending on their evolution — such as moving away to L2s; adding preconfirmations to L1s; or others.
As a result, we can separate the block time design problem in two:
- L1 perspective: Decentralized, credibly-neutral designs are absolutely essential for Ethereum and other L1 blockchains aiming to compete with Ethereum. They should not be excessively optimized for the performance of a single application, no matter how important.
- L2/appchain perspective: Conversely, an L2 or an appchain doesn’t need to tailor its design for general-purpose applications. L2 fees may already be low enough to minimize the friction caused by the basefee to negligible levels. If this isn’t the case, then paradoxically, exempting CEX/DEX arbitrage swaps from the EIP-1559 basefee would benefit DEX users.
Shorter blocks = less MEV?
To be clear, this article makes no claims about MEV in general, just about CEX/DEX arbitrage in particular. Regarding the latter: the results show that there’s a clear connection between CEX/DEX arbitrage, transaction fees, and block times. However, it is perhaps confusing because the connection goes both ways:
- Shorter blocks increase the number of arbitrage transactions and the proportion of gas that they consume;
- On the other hand, shorter blocks decrease the expected value of LP losses.
The same conflicting results apply to changes in basefees. As a result, there’s potential for a confusion, because MEV is increased in one sense, and decreased in another sense.
Summary
To summarize:
- CEX/DEX arbitrage transactions are not frictionless due to the EIP-1559 basefee and other factors.
- As a result, the nominal LVR in real-world AMMs is divided among three entities: LPs, ETH stakers, and the SBP as a collective entity.
- More gradual price changes result in more equitable LVR distribution among these three entities.
- On chains with significant transaction costs, LP losses under the LVR assumptions are not accurately predicted by the sqrt(blocktime) model.
- The LP losses are determined by several factors, including basefees, swap fees, and block times, the relative importance of which varies.
