A trader places a 50x leveraged perpetual order on a decentralized exchange using a central limit order book. The order sits in the mempool, visible to anyone monitoring the blockchain. Within seconds, another participant detects the order, places their own trade to move the price in the anticipated direction, waits for the original order to execute at a worse price, then exits their position for profit. This is not a new attack. What is new is that it happens on a fully transparent, on-chain order book where every pending order is cryptographically recorded and visible to the entire network—yet sandwich attacks still occur with mechanical regularity. The transparency that proponents of CLOBs claimed would eliminate front-running has instead created a different problem: order placement and timing have become the primary attack surface.

Hyperliquid, which launched as a purpose-built Layer 1 blockchain with a central limit order book architecture capable of processing 200,000 orders per second, offers an instructive case study. The platform’s design achieves something genuine: sub-second block times, on-chain order matching, zero gas fees for trading, and CEX-style order-book semantics. Yet despite this technical sophistication, the fundamental economic incentive to profit from information asymmetry remains intact. An attacker does not need a private mempool or corrupted validators to sandwich a trade on Hyperliquid; they need only superior market data, faster order submission, or knowledge of large pending orders before those orders are finalized. The transparency of the order book has shifted the attack vector, not eliminated it.

Why CLOB transparency differs from AMM opacity but fails to prevent extraction

Automated market makers operate on a simple principle: users trade against a mathematical formula, and the price they receive is determined by the ratio of assets in a liquidity pool. The order matching happens off-chain or through complex cryptographic mechanisms, and the final execution is submitted to the blockchain as a single transaction. An attacker can see this transaction in the mempool and sandwich it by submitting their own trade before and after, but the attack requires committing capital to push the price before the victim’s order executes and then exiting afterward. The attacker’s transactions are visible and the extracted value is proportional to the AMM’s slippage at that moment.

A central limit order book, by contrast, matches buyers and sellers directly. When a trader submits a market order on an on-chain order book, the matching engine compares it against all outstanding limit orders and executes the trade at the prices offered by the standing orders. The theoretical advantage is precision: a trader placing a limit order to buy 10 contracts at $65,000 does not have to accept $65,100 if no one is selling at that price. In principle, the order sits in the book and waits for a matching counterparty. The practical advantage seems to be transparency: everyone can see all pending orders, so no one should be surprised by execution price.

This transparency, however, does not eliminate the economic incentive to manipulate the order book. Instead, it creates a new attack surface: order placement timing. Because every order is broadcast to the network and recorded in the blockchain, an observer with sufficient latency advantages or market awareness can see a large pending order and respond before it settles. On the Hyperliquid platform, orders are submitted to validators, bundled into blocks with sub-second finality, and matched against the order book state at block time. The order book is visible before finality. An attacker who sees a large buy order in the pre-block state can submit a smaller buy order ahead of it, execute it at a better price due to the market impact of the incoming order, and then sell into the liquidity created by the victim’s trade.

The critical difference is that on an AMM, the attack requires moving the price through the formula and then reversing the position. On a CLOB, the attack requires only being first in line to match against the large order. The attacker needs neither pool slippage nor complex transaction sequencing; they need latency advantages and order placement precision.

Latency as the primary extractable resource

In traditional centralized exchanges, the matching engine runs on a single server, and latency is measured in microseconds. Order books are not visible to the entire network; access to market data is gated, and execution is reported only after settlement. The exchange operator controls the order matching logic and has a monopoly on the sequencing of trades. Front-running is possible but requires either collusion with exchange staff or access to an information feed ahead of publication.

A decentralized order matching system on a blockchain cannot hide the order book from the network, nor can it prevent other participants from submitting orders to the same validator or block proposer. The latency advantages shift but do not vanish. A market maker running a high-performance node on Hyperliquid’s network can monitor pending orders with millisecond precision and submit their own orders within the same block or immediately after. The validator must respect the order of submission within a block, but that order is determined by the time an order is received, not the order’s intrinsic properties. A sophisticated attacker can use direct connections to validators, optimized networking to reduce jitter, and rapid order submission to reliably place orders ahead of large incoming trades.

This is not technically “front-running” in the sense that a MEV searcher on Ethereum uses a private mempool to submit a transaction before a victim’s. The victim’s order is already visible to everyone. What is being exploited is the latency gradient: the delay between when different participants see the order and when they can act on that information. A retail trader with a 100-millisecond latency to the network cannot compete with a co-located market maker with 1-millisecond latency. The order book’s transparency does not eliminate this advantage; it makes the advantage purely technical rather than informational.

Price impact and order-placement sequencing attacks

When a large market order hits an order book, it moves prices by consuming multiple price levels of standing liquidity. The first few contracts may fill at the best bid or ask, but subsequent contracts must match against worse prices as the order consumes more of the available depth. This price impact is inevitable and proportional to the order’s size relative to book depth. However, an attacker can amplify the victim’s price impact by placing their own large order immediately before the victim’s order executes.

Suppose a trader places a 500-contract buy market order on Hyperliquid’s perpetuals book. The order book has 100 contracts available at $65,000, 200 at $65,100, and 200 at $65,200. The legitimate price impact is approximately 200 basis points as the order consumes all three levels. Now suppose a front-runner sees this 500-contract order in the pre-block state and immediately submits their own 1,000-contract buy order. The front-runner’s order executes first, consuming the best prices and leaving only worse prices available when the victim’s order executes. The victim now experiences price impact not only from their own order but from the front-runner’s order placed ahead of them. The front-runner then closes their position by selling into the liquidity created by the victim’s purchase, capturing the difference.

The attack is economically sound because the front-runner’s cost is the spread they pay to enter and exit, plus the market impact of their own order. If the victim’s order is large enough, the front-runner’s slippage is worth paying. This type of attack is order placement sequencing, and it is endemic to any on-chain order book where order visibility precedes order finality. Increasing block times or reducing transparency would mitigate the attack but would also degrade the exchange’s functionality.

Comparing extraction costs across architectures

On Ethereum’s AMM-based exchanges such as Uniswap, sandwich attacks require the attacker to move the price, wait for the victim, and then reverse. The attacker must pay slippage on both the entry and exit leg, plus transaction fees, and the victim’s trade must be economically meaningful relative to the pool size. If the pool has $50 million in liquidity, a $10,000 trade is unlikely to provide enough profit after fees and slippage to justify the attack. On a CLOB exchange with direct order matching, the attacker’s cost is lower: they do not need to move the price in advance; they only need to be first in line. Their slippage is the spread they pay when exiting, which can be recovered from the victim’s price impact if the order is large enough.

Gas fees also differ fundamentally. Hyperliquid offers zero gas fees for trading, which means an attacker does not face the direct transaction cost barrier that Ethereum traders do. An attacker can submit many small exploratory orders to test for large pending orders, then submit their extraction order when they identify a profitable opportunity. On Ethereum, each transaction costs 5 to 50 dollars in gas, which limits the number of speculative orders an attacker can submit without incurring significant costs.

The net result is that CLOB-based extraction may be lower-cost and higher-frequency than AMM-based extraction. An attacker can profitably sandwich orders that would be too small to target on Ethereum, and they can submit more attempts per unit time because there is no gas fee penalty. This does not make CLOBs worse than AMMs in absolute terms; it means the nature of the extractable value changes. On a CLOB, the primary mechanism is latency-based order sequencing. On an AMM, it is price-impact slippage and liquidity provision.

Validator and block-proposer incentives in CLOB designs

A critical question for any on-chain order book is who controls the block proposer and who enforces the order of execution within a block. Hyperliquid uses HyperBFT consensus with sub-second block times, meaning validators propose and finalize blocks rapidly. The order in which transactions appear within a block is deterministic: they appear in the order received by the validator. However, a validator who is also running a market maker operation has a direct incentive to reorder transactions within the block to front-run large orders or prevent orders from matching when doing so is profitable.

Hyperliquid mitigates this by distributing validation across multiple validators and using a Byzantine fault-tolerant consensus mechanism that requires a supermajority to commit a block. A single validator cannot unilaterally reorder transactions. However, if validators collude or if an attacker captures a significant portion of validation power, the order book becomes vulnerable to transaction reordering attacks that are even more efficient than network-based latency attacks. The validator does not need to submit transactions to the network; they can simply reorder transactions within their block proposal.

This is a fundamental tension: any on-chain order book must publish the order book state and the order of execution to ensure accountability. Publishing this information exposes latency-based and collusion-based extraction opportunities. Hiding the order book state would provide privacy but would defeat the purpose of a decentralized exchange. Most CLOB designs accept this trade-off and instead focus on reducing block times and the time between order visibility and finality, which compresses the window for attacks but does not eliminate it.

Client-side protection strategies and their limitations

Individual traders and trading firms have developed several strategies to reduce sandwich attack exposure on CLOB exchanges. The most common is order splitting: instead of submitting one large order, a trader submits multiple smaller orders over time, reducing the price impact and the attractiveness of sandwich attacks. An attacker who front-runs a small order may incur more slippage on entry and exit than the profit from the victim’s order, making the attack uneconomical.

Another strategy is randomization: submitting orders at unpredictable times and using randomized order sizes to reduce the predictability of trading patterns. This makes it harder for an attacker to identify which orders are large and worth front-running. Some exchanges offer dark pools or private order types that are not broadcast to the public order book until execution, which reduces visibility but introduces counterparty risk and may violate the spirit of decentralization.

Limit orders provide some protection by allowing the trader to specify the exact price at which they are willing to trade. If the order does not match at the specified price, it sits in the order book and waits, avoiding immediate execution and exposure to sandwich attacks. However, limit orders introduce different risks: the order may not fill at all if the market moves away, or it may fill partially at multiple price levels. For traders who need to execute immediately, market orders remain necessary, and market orders on a transparent order book remain vulnerable to sequencing attacks.

The fundamental constraint is that no client-side strategy can eliminate the latency gradient. If market makers and traders with superior network latency can see and act on pending orders before other participants, some form of extraction is inevitable. Randomization and splitting reduce the profitability of individual attacks but do not prevent systematic extraction of liquidity.

The structural problem: transparency without finality speed

The root cause of the CLOB front-running paradox is the gap between order visibility and order finality. On a perfectly fast blockchain with true instant finality, orders would be visible and simultaneously finalized, eliminating any opportunity for an attacker to respond. In practice, no blockchain achieves true instant finality across a distributed network. Hyperliquid reduces this gap by achieving sub-second block times and fast consensus, but “sub-second” is still milliseconds longer than a high-frequency trader’s latency advantage.

A gedanken experiment illustrates the problem: imagine a blockchain that finalizes blocks every nanosecond. Even at this speed, an attacker with a direct connection to the validator and a custom network stack could potentially see an order and submit a response within one nanosecond. The attack would require extremely specialized hardware, but it would be technically possible. In practice, latency advantages are measured in milliseconds, and sub-second finality is fast enough that only the most sophisticated market makers can profitably exploit the opportunity. However, this bar is far lower than the bar for AMM-based front-running, where the attacker must control both the execution sequence and the price impact.

Increasing finality speed further would help, but it encounters physical limits: the speed of light, network jitter, and the computational overhead of consensus. A blockchain cannot finalize faster than messages can propagate across the network, and no protocol can eliminate the latency gradient between different participants.

Implications for traders and designers

For a trader using a CLOB-based DEX, the practical implication is that order sequencing attacks are a cost of decentralization. On a centralized exchange, the operator bears the cost of preventing sandwich attacks through proprietary matching engines and order routing. On a decentralized exchange, this cost is borne by traders in the form of reduced execution quality and increased slippage for large orders. Traders must either accept this cost, split orders to reduce their visibility, or use alternative venues such as private order types or dark pools that sacrifice transparency for privacy.

For designers of CLOB-based systems, several approaches have been explored. One is MEV-resistant consensus mechanisms such as encrypted mempools or threshold encryption, where orders remain encrypted until a block is finalized and no one can see pending orders in advance. This would eliminate latency-based attacks but introduces new complexity around key management and decryption timing. Another approach is private order types that are not broadcast to the order book until execution, reducing visibility but introducing counterparty risk. A third approach is frequent batch auctions, where orders are collected for a fixed interval and then matched in a batch, eliminating the latency gradient within the batch but introducing auction timing as a new attack surface.

Hyperliquid’s current design accepts latency-based extraction as an unavoidable cost of fast, transparent order matching and focuses instead on minimizing the duration of the extraction window through rapid consensus and sub-second finality. This is a reasonable design choice that prioritizes functionality and speed over extraction resistance, understanding that no perfectly secure solution exists. Traders who wish to minimize extraction costs must adapt their behavior accordingly, using order splitting, limit orders, or darker execution venues.