Latency Games: the Good, the Bad, & the Ugly
The path to keep DeFi decentralized AND useful
Phil Daian from Flashbots recently published a post arguing:
- Geographic decentralization is super important (💯 agree!)
- MEV design should strive to be completely latency agnostic, so MEV players shouldn’t be to able to profit more by being faster (strong disagree)
In this post I’ll outline:
(i) Fallacy in being a maxi , even a geo-decentralization maxi
(ii) Importance of Ethereum being useful
(iii) The good, the bad and the ugly of latency games
Usefulness Matters
Let’s start by saying I agree 100% with Phil that geo-decentralization is super important, and we should be very mindful of it.
Having so much ETH stake managed by US entities isn’t a problem yet, but it’s borderline becoming one, and even Flashbots themselves included an OFAC-censoring component in their code due to US regulation.
But Ethereum is more than (i) a decentralized network (ii) to withstand a nuclear war.
🌈 Ethereum is useful 🦄
If we didn’t care about usefulness, we could have stayed with Bitcoin’s 10 min block-time, which you can transmit globally over radio waves.
As I wrote in the past, the FTX implosion was my wakeup call that so far DeFi failed to compete with CeFi, and the latest USDC and banking system shenanigans just emphasize this further.
For DeFi and crypto to succeed, it must be useful.
So we should strive for a useful geo-decentralized system, not maxi-out.
The Good
“Avoid TradFi latency games” has a nice ring to it — it actually persuaded me for a while! — but let’s dig a bit deeper.
Here’s how low latency is actually good for DeFi users in general, and specifically in the context of MEV (and then dig into the bad & ugly).
For DeFi Users
1) Correct Price
When a simp like me goes on Uniswap to buy ETH, I don’t expect to have an edge in “timing the trade just right”, but I do expect to get the fair correct price.
I want traders to quickly identify when the price moves up/down and arbitrage accordingly, so when my trade executes it’s at the correct price.
2) Global Liquidity
Simps like me also don’t trade on 20 venues simultaneously. Instead, I want my trade to “push” against all the global liquidity and hardly move the price, not just against the liquidity in my venue (well, my trades don’t move the market at all, but think of all us simps combined).
So if I’m using something like CoW Swap or DEXs allowing to set a max price, I want traders to quickly move liquidity to trade in the opposite direction.
3) Execution Confirmation
Simps like me also don’t care that much if the trade took 2 sec or 30 sec, but for large entities moving size it really does matter. When they make a $30M trade and are obliged to remain delta-neutral, they want their trade in the current price, they want to know whether it executed and at what price, and they need to know it now, often since it relates to other trades.
The slower the confirmation, the less useful DeFi is for them, and very practically speaking, it forces many of them to stay in CeFi and avoid DeFi.
For MEV Systems
1) Better for Small MEV Actors
Yep, that’s right.
Low latency MEV systems are better for small actors (and decentralization), who cannot compete on longer time scales.
Here’s why, using Al’s favorite analogy — Formula One (F1) races:
i. Many drivers manage to win a single lap
ii. Few drivers win a race
iii. The same guy always win the championship
(starting at 2010, Vettel won 4 yrs straight, then Hamilton 6 out of 7 yrs, now Verstappen for 2 yrs).
In shorter intervals (lap) many drivers manage to gain an edge, but this edge is eroded when averaged over a long interval (championship).
In longer intervals, the very very good always lose to the single best.
Similarly, small block-builders often have an edge to produce more MEV, just like an F1 driver might do a great job and win a lap. But the small builder’s momentary edge is eroded compared to the larger builders edge when averaged over longer times , just like the F1 drivers who win a lap usually don’t win a race, and never wins a championship.
In an imaginary world where block-builders produce mini-blocks every 1 sec, smaller builders are successful more often and the builder landscape is a lot more decentralized.
(note —I don’t think this is the solution! Just pointing out that lower latency is good for small actors.)
2) Minimize MEV
Before everyone got so excited about extracting more MEV, the truly ethical goal was to minimize MEV 🫡
Lower latency creates less MEV in 2 ways:
Less Reordering
In the imaginary 1-sec mini-blocks world mentioned above, the amount of MEV you could extract from reordering transactions is strictly smaller.
Why?
because you could do the same reordering and injecting Tx with 12 sec blocks, but you‘ll also have a lot more combinations to try.
Fun fact — if you’re about to produce 2 consecutive blocks, you’re better off not including any MEV Tx in the first, and then capture more MEV in the second. It’s called Lazy MEV 🥱
Less Arb
If you could trade against stale prices from (i) 1 sec ago, or (ii) 10 minutes ago, which one would you choose?
Obviously you will choose (ii) and trade assets that are clearly mis-priced.
That’s exactly the service Uniswap LPs are providing — providing stale quotes — and they lose $ (MEV) to CeFi/DeFi arbitragers.
The lower the latency, the less obviously-bad trades LPs take, and more “good trades in hindsight” they do.
The Bad
But low-latency games are not all 🦄 and 🌈
There are two main reasons high frequency traders (HFTs) are considered predatory, and both have to do with seeing trades before they execute, aka front-running.
Bad
HFTs see “normal” users’ trades before they execute, and leverage their faster connectivity to adjust their positions/trades accordingly.
One such example is the Robinhood — Citadel partnership, where Robinhood charge no fees from its users, and instead charges Citadel for the right to see these trades, which is fast enough to adjust its market-making strategies before they execute. If users are about to buy some share at size, Citadel will identify it, buy it before them, and probably sell it to the users at a higher price.
Worst
Sometimes its your dealer — the exchange terminal you’re using — that’s front-running you! It sees your buy/sell order, identify an opportunity, buy/sell before your trade executes, and profit from trading against you at a worse price for you.
This is as rigged as it gets…
As a normal user, you have no chance to compete with them — they will always be faster than you, they will react to a trend before you can even see it, and they are making your trades worse.
You’re playing in their field.
The Ugly
It makes zero sense to cripple DeFi’s usefulness by trying to make it latency-agnostic, while normalizing front-running — the actual negative effect low-latency brought to TradFi 🤯
Yes, we should experiment with new, never-seen-before models, like ordering trades not according to their order, but we shouldn’t replace valuable constructs just because we can, just like Tesla didn’t replace the steering wheel with an Xbox controller just because it could.
Takeaway
I’m all in favor of “avoiding TradFi mistakes”, but
- crippling crypto and DeFi usefulness in an attempt to maxi-out on geo-location makes little sense.
- Normalizing front-running while arguing against TradFi latency games makes even less sense.
- Doing so while introducing new centralized points like searchers, builders, and relays, makes no sense.
We should explore ways to leverage latency to improve both utility and decentralization:
- Could multiple proposers compete on producing the next block, balancing MEV profit and the need to be first?
- Could validators individually operate open-source code without introducing new points of centralization?
- Could strategic propagation to validators prevent front-running (pico-seconds won’t help HFTs when the original Tx had 50 ms head-start racing to the other side of the globe).
- Could validators serve and protect users to earn more $ than front-running make?
There’s plenty to explore in building a better, fair, open, global, decentralized financial system.
