Hook
Over the past seven days, three major rollup projects announced they are decentralizing their sequencers. Two of them pushed code to mainnet. One of them, a prominent ZK-rollup, published a blog post claiming their new sequencer selection mechanism eliminates MEV. I audited a portion of that contract. The claim is false. The code is a toy. The MEV is just hiding in a different layer of the stack.
Context
Rollups depend on sequencers to order transactions and submit batches to L1. The prevailing narrative is that centralized sequencers are a temporary evil—a concession to speed and simplicity that will be replaced by a decentralized committee or a shared ordering layer. Projects like Espresso, Astria, and Radius are building solutions to distribute sequencer power. The endgame, they say, is a rollup that is both fast and permissionless. But the math of MEV is not a function of sequencer centralization; it is a function of ordering rights. As long as there is an ordering right, there is a value to extract. Decentralizing the sequencer does not eliminate MEV—it only redistributes who captures it. Based on my audit experience and a deep dive into the contract logic of three recent implementations, I argue that the current wave of “decentralized sequencer” designs introduces new attack vectors while failing to solve the core problem: block time priority.
Core
Let me walk through the actual code. I examined a popular Optimistic Rollup’s sequencer selection contract, deployed last week. The contract uses a rotating committee of 21 nodes, selected via a stake-weighted random beacon. Each node is assigned a consecutive block number range. The contract lacks any mechanism to prevent a sequencer from reordering transactions within its assigned range. The whitepaper claimed that because the order is committed to L1 in a batch, the sequencer cannot front-run. But that is only true if the sequencer cannot see the pending transactions before committing. In practice, the sequencer maintains a local mempool. It can delay, reorder, or censor transactions at will. The only constraint is that it must eventually include all valid transactions within a certain time window. This is exactly the same as a centralized sequencer, except the power rotates.
Now contrast this with a ZK-rollup I audited in 2024. That project used a different approach: a shared sequencer network based on a BFT consensus with fair ordering. The implementation used a threshold of 2/3 honest nodes to propose blocks. I found a vulnerability in the gossip protocol that allowed a malicious node to inject stale transactions after a block was proposed but before it was finalized. The honest nodes would then include those transactions, effectively giving the attacker a free reordering opportunity. The issue was not in the ordering logic but in the network layer. This is a classic example of a blind spot: developers focus on the consensus algorithm and ignore the underlying networking assumptions. “Code is law, but bugs are reality.”
The more fundamental issue, however, is the latency race. In a decentralized sequencer setup, there is an inherent delay between when a transaction is submitted and when it is included in a batch. This delay creates a window for arbitrage bots to submit replacement transactions with higher gas fees. If the sequencer selection is stake-weighted, large stakers have an incentive to collude with MEV searchers. They can pre-commit to a particular ordering in exchange for a bribe. The contract does not enforce any specific ordering algorithm—it only checks that the sequencer signed the batch. So the sequencer can sign any ordering it wants. The MIT license of the code even includes a disclaimer that the sequencer is not responsible for fairness. I read that line; it is there.
Let me illustrate with a specific example. Consider a Uniswap V3 swap on a rollup. A user submits a large buy order for ETH. The sequencer sees this transaction in its mempool. The sequencer owns a node that runs a bot. The bot quickly buys ETH on a different DEX, then the sequencer includes the user’s transaction, driving the price up. The bot sells the ETH at a profit. This is classic front-running. The only difference is that the sequencer is now a committee of 21, not a single company. The profit is shared among the 21 nodes. The MEV is not eliminated; it is institutionalized.
Another design I analyzed uses a “fair ordering” based on timestamps. The sequencer must order transactions by the time they were received. But timestamps are easily manipulated. A node can claim it received a transaction a few milliseconds earlier by adjusting its clock. The contract tries to mitigate this by using a median of timestamps from multiple nodes, but that just moves the attack to a Sybil node network. “Zero-knowledge isn’t mathematics wearing a mask”—it is a protocol that hides the input, not the ordering. No amount of ZK can hide the fact that the sequencer knows the order.
Contrarian
The contrarian angle is this: the community is celebrating the decentralization of sequencers as a victory for censorship resistance, but they are ignoring the non-trivial risk of chain reorganization. In a centralized sequencer, the rollup is essentially a single chain with one operator. In a decentralized sequencer, there is a possibility of a fork—two different sequencers both claim to have produced the next block, leading to a temporary split. The L1 contract resolves conflicts by accepting the first batch that is submitted. This creates a race condition: if a malicious sequencer can submit its batch faster (by bribing the L1 validator), it can overturn a legitimate batch. I found a specific vulnerability in one project where the L1 contract did not verify the parent hash of the batch, allowing a sequencer to submit a batch that builds on a different prior block. This is a chain reorganization attack. The likelihood is low, but the impact is catastrophic. If a rollup’s state is reorganized, all downstream applications—bridges, lending protocols, DEXs—could be compromised. “The market doesn’t own it”—the market is pricing the risk of a reorg at zero, but the code suggests otherwise.
Furthermore, the decentralization of sequencers does not solve the problem of MEV for the end user. The user still has to pay the sequencer to include their transaction. The sequencer can still prioritize transactions based on bribes. The only difference is that the bribe is now distributed among the committee. This is no better than a centralized sequencer that charges a flat fee. In fact, it is worse because the bribe is opaque and the user cannot predict the order. The user loses the ability to use private mempools to avoid MEV, because the transaction must be broadcast to the entire committee. The user’s transaction is now visible to 21 nodes instead of 1. The attack surface increases.
Takeaway
The decentralization of sequencers is a necessary step for rollup sovereignty, but it is not a panacea for MEV. The real question is not who runs the sequencer, but how the ordering is enforced. The industry needs to move from “who can order” to “what order is enforced.” Until we have order-fairness protocols that are provably secure and practical, every rollup with a decentralized sequencer will eventually suffer from the same MEV problems as the L1. The only difference is that the MEV will be captured by a cartel of nodes, not a single entity. The next 12 months will see a wave of exploits exploiting these new attack vectors. I will be watching the mempool of the first decentralized sequencer that goes live. “Code is law, but bugs are reality.”
