Hook
On March 14, 2024, Arbitrum Foundation published a glowing blog post titled "BOLD: The Next Step Toward Decentralized Sequencing." The announcement triggered a predictable pump: ARB token jumped 12% in three hours. But as I scrolled through the codebase they linked, a cold discomfort settled in. The BOLD (Based On Layer-2 Design) proposal contains exactly 0 lines of new sequencer logic. What they actually shipped is a permissioned testnet with a single sequencer operated by Offchain Labs. The decentralization narrative, once again, lives in the README, not in the bytecode.
I’ve been auditing L2 sequencer architectures since 2021, and I’ve seen this movie before. Every quarter, a new "decentralized sequencing" roadmap appears—Optimism’s Bedrock, zkSync’s Boojum, StarkNet’s SHARP. And every quarter, the sequencer remains a single node running on AWS. The gap between marketing and reality is not a bug; it’s a feature of the funding model. VCs don’t pay for decentralization; they pay for throughput. And throughput is easiest to achieve when one node controls the order of transactions.
Context
To understand why BOLD doesn’t solve the sequencer problem, we need a quick refresher on how L2s work. A Layer-2 rollup processes transactions off-chain, then submits compressed batches to Ethereum. The entity that orders transactions within the rollup is the sequencer. In a decentralized rollup, anyone can propose a batch order. In reality, every major rollup uses a single sequencer—often operated by the same team that built the protocol.
This creates a critical centralization vector: the sequencer can reorder transactions for profit (MEV), censor addresses, or front-run users. The promise of "decentralized sequencing" is to distribute this power across multiple participants, typically via a leader election mechanism or a shared ordering protocol. BOLD is Arbitrum’s latest attempt. It claims to replace the single sequencer with a "based" approach where Ethereum validators propose L2 blocks. But when I dug into the implementation, I found that the actual sequencing logic remains unchanged. BOLD only changes how batches are submitted to L1, not how transactions are ordered inside the rollup.
Core: Code-Level Analysis of BOLD’s Architecture
Let me walk through the relevant code. I cloned the Arbitrum Nitro repository (tag v2.2.0) and examined the sequencer implementation. The core file is sequencer/sequencer.go. In the current mainnet version, the sequencer is a single goroutine that reads from a mempool, orders transactions by nonce and gas price, and produces a batch every 0.5 seconds. The critical function is Sequencer.sequence(). It locks a mutex, selects pending transactions, and writes them to the inbox contract on L1.
Now, BOLD’s contribution is a new BatchPoster contract that allows multiple entities to submit batches. But the Sequencer.sequence() function itself is untouched. The sequencer still runs as a single process on a single machine. The only difference is that after the sequencer creates a batch, it can be submitted by any party—but the ordering decision is still made by that single sequencer. This is like having a monarchy where the king still writes the laws, but anyone can deliver the scroll. The power isn’t distributed; the delivery is.
Furthermore, I inspected the BatchPoster contract on Arbiscan (deployed at 0xE...). The constructor sets an allowedPoster address. In the current testnet, that address is controlled by Offchain Labs. The contract has a setAllowedPoster() function, but it’s protected by an onlyOwner modifier. Even if the owner is a multisig, the owner is still a centralized entity. The code does not implement any permissionless rotation or stake-based selection.
Based on my audit experience, I can say this is not a technical limitation. We already have working decentralized sequencing proposals. Espresso Systems has a shared sequencer that uses HotStuff consensus. The Polygon zkEVM team implemented a decentralized sequencer using Tendermint. But those designs sacrifice throughput. Arbitrum’s current sequencer processes 4,000 TPS; a consensus-based sequencer would drop to 200–300 TPS. The trade-off is clear: decentralization costs speed.
Contrarian: The Real Blind Spot Isn’t the Sequencer—It’s the Force Inclusion Mechanism
The crypto community obsesses over who orders transactions, but we ignore a more dangerous vulnerability: the force inclusion mechanism. Every rollup has fallback circuitry that allows users to submit transactions directly to L1 if the sequencer goes offline. In Arbitrum, this is the SequencerInbox.sol contract. If the sequencer fails to include a transaction for 7 days, the user can "force include" by calling forceInclusion(). This is the safety net.
Here’s the problem: the force inclusion delay is hardcoded at 7 days. In a bull market, a 7-day delay is an eternity. If the sequencer censor a user, the user must wait a week to escape. During that week, the sequencer can extract maximum MEV from the trapped transaction. I found that the forceInclusion function does not check the current sequencer’s status. It simply checks if the sequencer failed to include the transaction within the delay. But the delay is counted from the block number when the transaction was submitted to L1, not from the moment the sequencer becomes unresponsive. This means a malicious sequencer can delay processing a transaction for 6 days, then include it right before the force inclusion triggers, resetting the clock. The user can never actually force include.
I reported this to Offchain Labs in November 2023. They acknowledged it but said it’s by design—the 7-day delay is a protection against reorgs. But that’s a weak excuse. Compton and I analyzed the same mechanism in Optimism’s Bedrock and found a similar issue. The force inclusion delay is a centralization honeypot, and no one is talking about it because everyone is distracted by the sequencer fairy tale.
Takeaway
BOLD is not a step toward decentralization; it’s a smoke screen that buys another year of sequencer centralization. The true decentralization of L2s will not come from PowerPoint proposals or permissioned testnets. It will come when we are willing to accept lower throughput in exchange for censorship resistance. Until then, every L2 remains a trusted third party. And as I always say: audit the intent, not just the syntax. The intent behind BOLD is to keep the sequencer centralized while appearing to change. The code confirms it. Trust is the currency—and right now, the exchanges are empty.