Last week, a popular rollup team announced they were upgrading their sequencer to handle 10x throughput. The community cheered. But as I dug into the release notes, something caught my eye: a single line buried under 'infrastructure improvements'—'Sequencer failover will now be managed by a multisig of 3 entities.' Three. For a network that boasts $2 billion in TVL.
We rush to celebrate throughput gains. We praise gas optimizations. But we rarely stop to ask: who holds the keys? Under the hood, many of today's L2 rollups are running on training wheels—centralized sequencers, upgradeable contracts, and governance multisigs that could drain the treasury overnight. And in this bull market, where every project is racing to capture mindshare, the uncomfortable truth is that most users don't understand the difference between 'decentralized in theory' and 'decentralized in practice.'
Let's start with the basics. A rollup's security model depends on two pillars: data availability and fraud/validity proofs. The first ensures that anyone can reconstruct the chain's state; the second ensures that invalid transactions are caught. But between those two pillars sits the sequencer—the entity that orders transactions and publishes them to L1. In a mature rollup, the sequencer is a permissionless set of nodes that anyone can join. In reality, almost every major rollup today uses a single sequencer operated by the development team.
I've been auditing rollup architectures since the Optimism Bedrock upgrade in 2023. And I can tell you: the gap between the white paper and the production code is often a canyon. Take the sequencer's ability to reorder transactions. A centralized sequencer could censor addresses, front-run users, or even delay withdrawals for days. Most teams promise decentralization 'in Q3' or 'next year.' But I've seen those promises slip quarter after quarter. Why? Because running a permissionless sequencer set is hard—and expensive. It requires slashing conditions, economic incentives, and rigorous testing. The team is incentivized to ship features, not to decentralize infrastructure that seems to work fine today.
But here's where the narrative breaks down. The bull market has created a 'decentralization theater'—projects claim to be decentralized because they have a DAO or a token, yet the real control remains in a few hands. I recently analyzed the governance proposals of five top rollups. In three of them, the top 10 addresses controlled over 70% of voting power. That's not governance; that's an oligarchy with a nice website. Decentralization isn't a checkbox you tick; it's a continuous commitment to distribute power.
Now, the contrarian angle. You'll hear defenders say: 'Centralization is a temporary trade-off for speed. The market will reward the fastest chain, and decentralization can come later.' This argument has a grain of truth—early-stage projects often need agility. But it ignores a fundamental law of systems: power, once concentrated, rarely disperses willingly. Every additional month that a sequencer remains centralized hardens the status quo. The team builds dependencies. The community grows accustomed to low latency. And when the time comes to decentralize, the cost of change is so high that the proposal gets tabled indefinitely.
I've seen this pattern firsthand. In 2022, I helped a mid-sized rollup design its decentralization roadmap. The team had the best intentions. But every quarter, the engineering lead would say: 'Let's prioritize this after the next upgrade.' Two years later, the sequencer is still a single AWS instance. Bridges aren't built to be permanent; they're built to be upgraded—but upgradeable contracts become permanent vectors of control.
The real risk isn't just technical; it's existential. A centralized sequencer is a single point of failure—not just for censorship, but for social trust. The moment a regulatory body demands that the sequencer freeze an address, the entire premise of 'permissionless' crumbles. We saw this with USDC's blacklist function. But at least Circle admitted it was a centralized system. Rollups that pretend to be decentralized while operating a private sequencer are worse: they mislead users into a false sense of security.
So what can we do? First, demand transparency. Read the deployment scripts. Check whether the sequencer is upgradeable and who holds the admin keys. Look for 'force inclusion' mechanisms that allow users to bypass the sequencer and submit transactions directly to L1. If such a mechanism doesn't exist, you're not using a rollup; you're using a sidechain with fancy marketing.
Second, support projects that are actively working on decentralized sequencing. Optimism's RetroPGF has funded research into 'op-geth' and multi-sequencer models. Arbitrum now has a 'Timeout' mechanism that lets users exit even if the sequencer goes down. These are steps in the right direction, but they're still rare.
Finally, as a community, we need to stop celebrating throughput as the ultimate metric. Trust isn't measured in TPS; it's compiled, verified, and shared. A rollup that processes 10,000 transactions per second but can be shut down by a single individual is not a secure foundation for the future of finance. It's a centralized database with a cryptographic wrapper.
We don't need to abandon L2s. We need to hold them accountable to the values that brought us here. Every time you see a new bridge or a new rollup, ask not just 'How fast?' but 'How decentralized?' The answer might surprise you—and it might save you from the next exploit.
Code is only as strong as the trust it protects. And right now, too much of that trust is sitting in a few multisig wallets.
