Sequencers and Proposers: Who Builds the Block

A sequencer is the component that decides the order of transactions in a rollup or an appchain. It accepts signed transactions, queues them, executes them, and publishes the resulting state commitment. In most rollups exactly one sequencer runs at a time, and it is operated by the same team that built the chain. That single point of ordering is the entire job, and it is also the entire trust assumption.

Ordering is not a neutral act. Whoever holds it can delay a transaction, drop it, or move it ahead of another, and each choice costs somebody money. What follows is where that power sits and which mechanisms keep a single operator from being a single point of failure.

• A sequencer orders and executes transactions, but on most rollups it does not finalise them; settlement on the base layer does.
• Single-operator sequencing is a liveness and fairness risk, not usually a theft risk, because the operator cannot forge your signature.
• Forced inclusion and escape hatches are the mechanisms that make single-operator sequencing survivable rather than fatal.
• Read the withdrawal path before you deposit, because that path is what you actually rely on when ordering stops working.

What a sequencer actually does

Its job is a loop: accept transactions, put them in an order, execute them against current state, publish the result. On an optimistic rollup the result is a batch plus a new state root; on a validity rollup it is a batch plus a proof. Either way the operator decides sequence.

That makes it a throughput component and an authority at once. It compresses thousands of transactions into one base-layer submission, which is where the fee saving comes from, and it holds a temporary monopoly on inclusion, which is where the trust assumption comes from.

Ordering is separate from proving

A sequencer does not have to be the entity that proves correctness, and usually is not. Optimistic systems attach a challenge window during which anyone can dispute a bad batch. Validity systems require a proof to verify before the state is accepted. In both designs the operator can lie about order but cannot make a false state transition stick.

What gets published, and when

Cadence varies by design: every few minutes, on a size threshold, or on demand. The gap between execution and publication is the window in which your transaction exists only in the operator’s database. If the operator disappears inside that window, your transaction never reached the base layer, and a chain restarting from the last published state may discard it.

Proposers and the split of duties

On a base layer, proposing and sequencing are different jobs. A proposer is the validator selected by protocol rule to propose the next block. Builders assemble candidate blocks and bid for the right to have theirs chosen; the proposer picks one and signs.

On a rollup, the sequencer usually performs all three functions for its own chain and hands the compressed result to the base layer. The guarantees are not the same. Base-layer proposers are selected by a rule with an economic penalty attached. Rollup sequencers are typically selected by a contract, an allowlist, or a multisig, which is an administrative arrangement rather than a protocol one.

What a single sequencer can do to your transaction

Three things, in ascending order of seriousness. It can delay: hold a transaction without including it and without giving a reason. It can reorder: place your swap after another trade so the price has already moved against you. It can exclude: refuse an address entirely, indefinitely, or until the address stops asking.

What it cannot do is sign for you. Your transaction carries your signature; the operator chooses only whether and when to include it, which is why single-operator sequencing is described as a liveness and fairness risk rather than a custody risk. The exception is an operator that also holds upgrade keys over the bridge or rollup contracts, because an upgrade can change the rules rather than merely apply them.

A sequencer that can stop your transaction is annoying. A sequencer that can rewrite the contract your transaction calls is a different category of problem, and the two are often the same organisation.

Forced inclusion

Forced inclusion is the counterweight, and it is the single most important feature to check. A user submits a transaction directly to a base-layer contract, bypassing the operator. After a delay the rollup must include that transaction or enter a state that lets users exit. The delay is the price: a short bypass window would let anyone flood the base layer with cheap forced transactions and erase the fee advantage the rollup exists to provide.

Escape hatches

An escape hatch lets you withdraw without the operator’s cooperation, usually by proving a balance against a state root the base layer has already accepted. It is the stronger mechanism, because it does not depend on the operator processing anything.

Both are slow and adversarial by design. They exist for the day the operator is offline or hostile, not for routine use.

Sequencer arrangements compared

The arrangements differ less in speed than in what happens on the day the operator misbehaves. What matters is who can stop you and what you can do about it.

Rows matter more than columns here. The last one is not hypothetical: early rollups shipped without any bypass and relied on the operator’s good intentions, which worked until it did not.

How to check the ordering assumptions before you deposit

Do this in order, because each step narrows what the earlier ones mean. It takes about twenty minutes with a block explorer and the contract source.

1. Find the deposit contract and identify which address may post batches to it. If the answer is one externally owned account, you are trusting one key.
2. Check whether that address is a plain key, a multisig, or a contract with a timelock. A timelock gives notice before rule changes; a bare key does not.
3. Locate the forced-inclusion function and read its delay parameter. If no such function exists, the chain has no censorship resistance.
4. Check whether withdrawal requires the operator to co-sign or to process a message. If it does, the escape hatch is nominal.
5. Identify the upgrade authority. A proxy admin that can replace the bridge logic overrides every guarantee above, so the admin is the real trust anchor.
6. Complete a full round trip with a small amount before committing a larger balance.
7. Write down the delays you found, because those numbers are what you act on during an incident.