Tezos X: Is sequencer centralization really the new reality?

(Source: Tezos X: From Roadmap to Reality | Tezos Spotlight)

The thing that made Tezos special was never just the tech stack. It was the belief that protocol evolution could happen in public, on-chain, with bakers and users actually having a say. Governance was not a marketing line. It was the product.

So when Tezos X starts from “we need extreme speed now, and we can decentralize the centralized parts later,” I cannot just nod along.

That sounds like the same kind of shortcut Tezos was supposed to help crypto outgrow.

If the plan depends on a centralized sequencer, or some other single point of failure, then the burden is on the people proposing it to explain the full path back to decentralization before it ships. Not later. Not after market fit. Not after the press release.

Because “we’ll decentralize it later” is what every centralized system says when it wants decentralization’s branding without paying decentralization’s cost.

And I do not think the tradeoff even gets us what people hope it gets us.

The NYSE is not going to settle on Tezos because we shaved latency by compromising the one thing Tezos can still credibly claim better than almost anyone else. If institutions want a fast centralized rail with one obvious choke point, they already have choices with more liquidity, more BD, more integrations, and more institutional comfort.

If Tezos competes as a centralized product, it competes against better centralized products.

That is a brutal place to stand.

The place Tezos can still stand is harder, weirder, and more valuable. Decentralization by design. Governance that actually matters. Bakers who are more than yield endpoints. Users who can see the tradeoffs before the decision is already wrapped in narrative.

Bring this into the open.

Let the community wrestle with it while the design is still alive. Let bakers ask hard questions. Let builders propose alternatives. Let the people who stayed here for the original Tezos promise help protect the part that made it worth staying for.

I am not saying Tezos should ignore performance. I am saying performance cannot become the excuse for forgetting why Tezos mattered in the first place.

More cypherpunk, less corporate.

Remember where you are.

2 Likes

Is sequencer blindness required for decentralizaton?

1 Like

yes.

1 Like

A blind sequencer removes the incentive for some attack vectors but a sequencer can still be decentralized without being blind.

If you’re worried about censorship via sequencer then transactions can always be forced directly on the L1 using the delayed inbox.

The delayed inbox proves users are not permanently censored, but it also proves the normal path has a sequencer dependency. If the sequencer fails or censors, users can choose the delayed inbox, but that means accepting degraded UX and delayed execution. That is still an outage of the normal system. We are not avoiding the outage; we are choosing the failure mode.

Assume Tezlink succeeds. It is now handling 3,000 TPS and important apps depend on it.

Then, for legal or political reasons, the current sequencer operator is forced offline. Maybe it is sanctions, a court order, regulatory pressure, infrastructure seizure, whatever. The reason does not matter. The normal Tezlink/Etherlink path is now down because the docs say only one account can operate the sequencer.

Users still have the delayed inbox. That means censorship is not permanent. But it is not a replacement for the sequencer.

Every transaction now has to go through Tezos L1 into the delayed bridge contract, sit in the delayed inbox, and only become force-includable after the delay. Per the docs, that delay is 12 hours or 1600 L1 blocks, whichever is longer. At 6s blocks, 1600 blocks is ~2h40m, so the effective delay is 12 hours.

So during the outage, Tezos has not avoided the outage. It has chosen the outage mode.

Option A: elect a new sequencer through sequencer governance. That process is not instant. Docs list Proposal, Promotion, and Cooldown periods: ~4.5 days + ~4.5 days + ~1 day, assuming ideal block timing.

Option B: use fast kernel governance to change emergency behavior. Even fast governance is roughly 8h proposal + 8h promotion + 1 day cooldown, plus activation uncertainty.

Meanwhile, 3,000 TPS equals about 259 million transactions per day.
Those cannot realistically be shoved through an L1 delayed inbox designed as a censorship escape hatch, not the normal execution rail.

So the issue is not “can a user eventually force a transaction?”

The issue is: if the sequencer disappears under real load, the backup path preserves theoretical liveness but not practical continuity.

And let me just lay out the other prong of my argument (in addition to above response).

Tezos spent 7 years teaching one lesson: optimize from decentralization, not toward it.

L1 started slow: 60s blocks. Then it got faster the Tezos way: methodically, publicly, without tossing bakers and governance into the trunk.

Tezos X risks flipping that lesson on its head.

Start with sub-second UX. Start with centralized sequencing on the normal path. Promise decentralization later.

The problem is later.

Once apps, liquidity, market makers, and users build around that speed, the speed becomes the product. Every serious decentralization proposal then gets filtered through one question: does this make the fast thing worse?

If it adds latency, lowers throughput, hurts UX, or scares liquidity away, it becomes politically expensive.

Yes, L1 bakers govern Etherlink kernel upgrades and sequencer operators. That matters. It means the decentralization core still has a hand on the wheel. But it also means the pressure moves upward into L1 governance. The more value migrates to the faster rail, the harder bakers will be pushed to protect the faster rail. And it’s not going to be bakers introducing the decentralized solution as a proposal later. Bakers do not participate in the development of Tezos L1/L2 due to existing economic conditions and prior social convention.

That is the Solana-shaped trap.

Tezos was supposed to be the opposite lesson.