Tezos X: Is sequencer centralization really the new reality?

Philosophy and Economics
1

image
image827×590 112 KB

(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.

5 Likes
2

Is sequencer blindness required for decentralizaton?

2 Likes
3

yes.

2 Likes
4

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

5

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

6

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.

7

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.

2 Likes
8

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.

4 Likes
9

Im the kind of operator who wants to run everything—L1 nodes, Smart Rollup nodes, observer modes, auxiliary services, even the small maintenance bots. Thats the appeal: full participation, full sovereignty, full decentralization.

So its frustrating to hit a hard boundary, with etherlink, where I can run nearly every component… except the one that actually controls execution—the sequencer.

Right now, the sequencer isnt just another service. It controls transaction ordering, inclusion, and effectively defines liveness at the L2 layer. That makes it fundamentally different from Smart Rollup nodes, indexers, or other infrastructure—those are participatory; the sequencer is authoritative.

If I cant: run a sequencer, compete as one, or meaningfully replicate its role

Then this doesnt feel like a decentralized rollup. It feels like: a centrally coordinated execution layer with decentralized settlement.

And while the delayed inbox is presented as a fallback, its not a viable alternative under normal conditions. It introduces friction (extra L1 transaction + cost), long delays (hours before forced inclusion), and a fundamentally different UX. Its a safety valve for failure—not a substitute for open participation in execution.

5 Likes
10

I’m starting to be strongly in favor of based sequencing. It’s too much of a security risk to decentralize and there’s too much MEV risk in staying centralized. The current direction has both options putting funds at risk, at least from the user perspective.

11

I’m honestly dumb-founded as far as where Tezos X sequencer goes from here, i.e. instant 50ms confirmations, to become properly decentralized long term in some meaningful way.

We’re in quite a precarious situation right now in terms of roadmap. Not just for sequencing but for post-quantum tech as well.

The core devs are holding their cards so close to their chest, it’s leaving an indentation :laughing:

3 Likes
12

held close for good reasons i imagine. as i was saying. there are deeper issues than uptime with that sequencer. just get rid of it.

2 Likes
13

Hmmmm… yea. Either based sequencing, or a very clear covenant around L2 liveness/forced inclusion, or we’re just recreating the usual rollup trust gap with Tezos branding.

1 Like
14

Nah, we can’t use purely based with the kinds of ambitions we have.

The cleanest model is to rotate the sequencer through the L1 baker set: 50ms preconfirmations on the fast path, then committee certification and L1 settlement behind it. If the active sequencer dies or censors, the transaction gets forced through L1 and the next baker takes over within the same 12–30 second liveness covenant we already trust.

The speed is optimistic, the escape hatch is decentralized and doesn’t feel like an outage.

Using the bakers for this is good, it’s definitely part of their overall intended function. Giving bakers some additional income is good as well.

Someone tell me why this model is stupid or what a better one would be, given our ambitions.

1 Like
15

if there’s a way to slash preconfs(?) MEV is not slashable so this becomes an issue again without a blind sequencer. this will break 50ms or force everyone into ap-northeast-1 anyway

draw 50ms * speed of light circle on a map. realize anything needing consensus has to be smaller and that 50ms blocks != 50 ms latency

based is the way to go for something being marketed as general purpose. it will upset the market makers (who’s among us will stan for wintermute? make your case) but for what is intended as the canonical community rollup… i don’t see another option near term (next 2 years).

speed is an optimization problem. decentralization is more fundamental and has to come first. at some point this was understood

2 Likes
16

Yeah, this is the distinction I was reaching for. I don’t need the 50ms path to carry full L1 finality; I need the failure path to inherit L1’s liveness covenant.

There are already plenty of slightly more centralized L1s and L2s with deeper pockets and better business development that will eat our lunch if we try to compete with them purely on speed.

We are not going to out-centralize the chains built for centralization. Tezos’ defensible edge is credible decentralization.

50ms should be the fast path, not the trust model beneath it. Based first.

17

i think the issue is a slow path that actually works will stall the fast path. so l2 fee > l1 fee. you can see this in the current forced inclusion path. one that constrains the sequencer beyond what is needed to making regarb plausible would cost more

better line of inquiry imo is what guarantees can be realistically provided at 50ms and to who. to satisfy everyone requires clairvoyance, which is how Tezos X is being presented and it sounds like quackery