Skip to content
Like a computer, a blockchain has an internal clock: the blocktime [1]. Users send the blockchain transactions which contain sequences of instructions that modify the shared state of the network (for example, instructions to buy an asset on a decentralized exchange). Each time this clock “ticks,” it executes an entire batch of transactions—instantaneously from the blockchain’s perspective. You’d think, if the blocktime is the system’s clock, nothing at a finer-scale resolution should matter. You’d be wrong.
In most blockchain systems today (e.g., Ethereum), the order of transactions within a block matters. The consensus leader responsible for proposing the next block [2] has unilateral control over both the transactions included in this block and their ordering. This control, coupled with trading on decentralized exchanges, can cause trouble.
Guarantees provided by the blockchain
Each blockchain transaction must be digitally signed by the sender. As a result, the leader cannot tamper with the sequence of instructions specified by any transaction; they only control inclusion and ordering. This point is important: blockchains offer strong, cryptographic guarantees that, if your transaction is included, your transaction’s instructions cannot be modified [3].
Of course, the leader may have included other transactions before yours, so your transaction might execute against a different state than that of the last block. For example, if your transaction is a trade on a decentralized exchange, the price on the exchange may change before the blockchain executes your transaction.
Trading on decentralized exchanges
Buyers on decentralized exchanges typically submit market orders [4]. This order includes a slippage tolerance: the maximum price at which the buyer is willing to buy. This tolerance accounts for potential price movement between transaction broadcast and inclusion. (If the true price—in the astrological economic sense—of the asset is going up, many others are likely trying to buy as well [5].) For example, if you see an asset at \$100 and submit a buy order with 1% slippage tolerance, you might get this asset for \$100, but you’d take it at \$101 too.
Arbitrage
Why include the slippage tolerance? Sometimes, the true price changes between the time you place the trade and the time of trade execution, especially in systems with a long blocktime (i.e., a slow clock). Decentralized exchanges—like any market—rely on arbitrageurs to keep prices accurate. If the true price of this asset is \$101 but the exchange quotes a price of \$100, then an arbitrageur will try to buy the asset at \$100 and sell it elsewhere at \$101. (And your order will likely be filled at \$101, which is within your slippage tolerance.)
So who captures this arbitrage? In traditional markets, which effectively operate in continuous time, it’s captured by the fastest arbitrageur. In blockchain-based markets, it’s captured by the highest bidder.
Auctions
Using auctions to award arbitrage opportunities differs from latency races in public markets. If I think that the price will continue to go up, perhaps to \$102, I’m willing to pay more than an arbitrageur who wants to sell the asset right away at \$101. These payments go to the current consensus leader, since they have monopoly control over the next block contents. This leader includes the set of revenue-maximizing transactions from the auction. (Note that this auction typically happens out of protocol; for example, the auction is not part of the Ethereum protocol itself.) Unfortunately, the leader’s monopoly control over transaction ordering, coupled with trading on decentralized exchanges, introduces a system quirk: sandwiches.
Sandwiches
Let’s say you submit an order to buy an asset at \$100 with a 1% slippage tolerance. A malicious auction participant could bid for the following “bundle” [6] of transactions:
- Txn 1. A buy order before yours that pushes the price up to \$101
- Txn 2. Your buy order, which executes at \$101 (within your slippage tolerance)
- Txn 3. A sell order, selling the asset they bought at \$100 for \$101
Your trade executed at a different price than what you saw—but not due to some true price movement. The true price remained the same; the “sandwicher” manipulated the price before your transaction and then sold immediately after to make an instantaneous, risk-free profit. As previously discussed, arbitrage transactions like the frontrun (Txn 1) and the backrun (Txn 3) are not inherently bad; these trades can help keep markets efficient. The combination feels… wrong.
Here, there was no real arbitrage opportunity; an actor used a system quirk to artificially create one. Although there is limited precedent for regulatory enforcement against sandwich attackers, the practice arguably constitutes market manipulation under federal securities and commodities laws—particularly when an actor exploits monopoly power to create artificial prices (i.e., prices that do not reflect independent market forces of supply and demand) [7]. While establishing intent in these cases can be a challenge (and may explain the limited precedent), it is difficult to argue sandwich attackers are unaware of their action’s impact on prices. Sandwiching, despite being common, is manipulative and exploitative.
Better designs
We can do better. This attack vector comes down to the fundamental mismatch of blockchain events with the system clock. What if there was no concept of order within a block? In the exchange setting, this means that all trades get executed in a batch—everyone in the block gets the same price. Eric Budish and others have proposed these designs (called frequent batch auctions) to ameliorate harmful effects of latency arbitrage in stock exchanges [8]. The associated clocks can be fast—measured in milliseconds. Traders, whether retail or institutional, won’t notice a difference. We think similar designs hold promise in the blockchain setting [9].
The design space of new mechanisms is only beginning to be explored [10]. Blockchain-based financial systems offer an opportunity to reimagine financial infrastructure from first principles. Let’s build systems that prohibit harmful behavior by design. Manipulability is a bug, not a feature.
Acknowledgements
Thank you to Alex Evans, Max Resnick, Lucas Bruder, and Henry de Valence for helpful comments on drafts of this post.
Footnotes
[1] Henry de Valence inspired this viewpoint.
[2] In most blockchains, the consensus leader for each block (called the “proposer” in Ethereum) is randomly selected based on resources contributed to the network (e.g., compute power in proof of work systems or capital in proof of stake systems).
[3] But your transaction could be included in a different context! For an example, see “uncle bandit attacks”.
[4] We don’t think this is a good thing.
[5] For academic purposes, think of the true price as the price on an external, infinitely liquid market.
[6] Note that the blockchain does not enforce the sanctity of this bundle; order flow auction systems use out-of-protocol techniques to do so.
[7] See, Barczentewicz, Mikolaj and Sarch, Alex F. and Vasan, Natasha, Blockchain Transaction Ordering as Market Manipulation (February 3, 2023). (2023) 20 Ohio State Technology Law Journal 1-87, Available at SSRN.
[8] Arbitrage, of course, still exists in batch systems. Our paper Concave Pro Rata Games analyzes a simple model of this type of arbitrage.
[9] These batched mechanisms aren’t a total panacea due to transaction censorship. For a discussion of these concerns see Censorship Resistance in On-Chain Auctions.
[10] Relatedly, many have proposed more restrictive transaction ordering rules to prevent specific types of harmful behavior.