Skip to content
DeFi Reference

Based rollups and preconfirmations

1. TL;DR

Section titled “1. TL;DR”

A based rollup lets the next Ethereum L1 proposer (with its builders and searchers) sequence the rollup’s next block, inheriting L1 liveness and decentralization and sending rollup MEV to L1, at the cost of 12-second latency and no native fast confirmations. Based preconfirmations fix latency by letting opted-in L1 proposers sign slashable promises about rollup transactions ~100 ms ahead of inclusion; native rollups fix execution trust by verifying EVM state transitions with an L1 EXECUTE precompile. Taiko shipped the first based rollup (2024) and whitelisted preconfirmations (August 2025), while Unichain took the opposite route: a single sequencer whose block builder runs in a TEE and streams 200 ms “flashblocks” (live since August 2025).

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

A based rollup is a food truck that does not hire its own cashier: it lets whoever is running the city market’s till that minute ring up its orders too. The truck never goes down when its cashier is sick, and the city gets the tips, but customers wait for the market’s twelve-second till cycle. A preconfirmation is the till operator scheduled for the next cycle handing you a signed receipt now, backed by a deposit they forfeit if your order does not come out as promised. A native rollup is the city agreeing to check the truck’s arithmetic itself, so nobody needs to trust the truck’s own accountant.

ELI5

Section titled “ELI5”

A rollup is a second blockchain that stores its data on Ethereum. Most rollups have one company that decides transaction order (a sequencer). A “based” rollup instead lets the Ethereum validator whose turn is next decide the order, so the rollup can never be paused by a single company and the ordering profit goes to Ethereum. The downside is you wait twelve seconds. To fix that, the validator whose turn is coming can sign a promise about your transaction right away and lose a deposit if they break it; that promise is a “preconfirmation”. A “native” rollup goes further and has Ethereum itself check that the rollup’s computations were right.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

Alice swaps on a based rollup with preconfirmations; the next opted-in preconfer proposes L1 slot n+5n+5 (about 60 s away):

  1. Before: Alice holds 1 ETH on the rollup; the rollup’s last L1-settled state is block BkB_{k}. Preconfer PP has 32 ETH staked plus a restaked preconf collateral of 1 ETH and appears in the lookahead at slot n+5n+5.
  2. Request (t = 0): Alice sends PP a promise request for her swap plus a preconf tip of 0.0005 ETH; PP simulates it on top of its current preconfirmed rollup state and returns a signed execution promise (“your swap executes at position 17 with output ≥ 2,995 USDC”) within ~100 ms.
  3. Interim (slots n+1n+1 to n+4n+4): other L1 proposers may include rollup blocks, but transactions carrying PP‘s promise can be included and executed immediately by any of them; non-preconfirmed transactions queue behind.
  4. Settlement (slot n+5n+5): PP‘s block includes the rollup block with Alice’s swap at position 17 via its inclusion list; Alice’s balance becomes 0 ETH + 2,997 USDC; PP collects the 0.0005 ETH tip.
  5. Faults: if PP misses its slot and Alice’s swap was not already included, a liveness fault slashes the agreed liveness amount (say 0.1 ETH) to Alice; if PP includes a block contradicting the promise, a safety fault slashes the full collateral.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: Based rollups have no sequencer. Reality: the L1 proposer (via builders) is the sequencer; what is removed is a separate sequencer set, its signatures, and its escape hatch.
  • Myth: Based sequencing means first-come-first-served. Reality: Drake lists FCFS as something “unclear with L1 sequencing”; ordering within the rollup block is whatever the L1 builder chooses, which is why MEV flows to L1.
  • Myth: Preconfirmations are finality. Reality: they are slashable promises from one proposer; reorgs on L1 and missed slots break them, which is why designs include liveness-fault penalties and fallback promises from later preconfers.
  • Myth: “Native” and “based” mean the same thing. Reality: “based” is about L1 sequencing, “native” is about L1 execution verification; a rollup can be either, both (“ultra sound”), or neither.
  • Myth: Unichain is a based rollup. Reality: Unichain has a single sequencer; its innovation is a verifiable TEE builder with flashblocks and a validation network, a different answer to the same trust problem.

If you only remember one thing

Section titled “If you only remember one thing”

Based rollups trade latency and their own MEV for L1 liveness and alignment; preconfirmations and native execution are the two add-ons that try to buy the latency and trust back.

3. How it works

Section titled “3. How it works”

Based sequencing

Section titled “Based sequencing”

Drake’s definition: “a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block.” Advantages: L1 liveness (no escape-hatch timeouts, no mass exits), decentralization (reuses the L1 searcher–builder–proposer pipeline), simplicity (no sequencer signatures, no external consensus, tokenless), zero gas overhead, and L1 economic alignment (rollup MEV strengthens L1 security and, with MEV burn, ETH scarcity). Disadvantages: no MEV income for the rollup, and constrained sequencing: fast preconfirmations and FCFS are hard. The “total anarchy” worry from Buterin’s 2021 rollup guide, that many parties submit competing batches and waste gas, is answered by PBS: builders include at most one rollup block per L1 block, and a zk-rollup’s proof for block nn can ride in block n+kn+k.

In Taiko’s implementation anyone may run a proposer that builds an L2 block and submits it in an L1 transaction; L1 order fixes L2 order, so the L1 builder can capture cross-domain MEV between rollup and L1 in one block (“MEV for Based Rollup”, 2023).

The PGA problem in total-anarchy sequencing

Section titled “The PGA problem in total-anarchy sequencing”

Rezzoli’s analysis of Taiko (Nov 7–22, 2024) shows what happens without coordination: competing proposers race to include the same profitable L2 transactions ahead of the fallback proposer, so the fallback’s blocks land with redundant (already-executed) transactions and must still be proven. Taiko Labs’ proposer netted −83.9 ETH (≈ −$261,096 at $3,112/ETH) over two weeks while the two most aggressive competitors netted +26.0 and +17.5 ETH (as of 2024-12). Profit per proposer is L2 priority fees+(base fee, for Taiko Labs)−(L1 publication+proving)\text{L2 priority fees} + (\text{base fee, for Taiko Labs}) - (\text{L1 publication} + \text{proving}).

Based preconfirmations

Section titled “Based preconfirmations”

Two on-chain pieces: proposer slashing (opt-in additional slashing conditions, assumed via restaking) and proposer forced inclusion (inclusion lists, so a proposer can force transactions into a builder’s block). An L1 proposer that opts in becomes a preconfer; it issues signed promises for tips; precedence among preconfers follows slot order in the lookahead. A promise from the next preconfer can be executed immediately by any earlier proposer; non-preconfirmed transactions are queued behind preconfirmed ones. Faults: liveness (slot missed, transaction not previously included; slashing amount negotiated) and safety (promise contradicted; fully slashable). With a 32-slot lookahead and a fraction qq of validators opted in, the probability that at least one preconfer is available is

1−(1−q)32≈99.92% for q=20%.1 - (1-q)^{32} \approx 99.92\%\ \text{for } q = 20\%.

Promise types range from full post-state-root commitments (a sequential bottleneck) through state-diff and intent-level promises to inclusion-only; point-to-point latency is ~100 ms; tips may be negative when a transaction raises the preconfer’s expected arbitrage. Oshitani’s “strawman” analysis lists six problems: latency races, congestion from arbitrage spam (Solana’s ~58% of validator time on failed arbitrages), tip pricing, fair exchange, liveness, and early auctions.

Native rollups

Section titled “Native rollups”

Drake’s 2025 proposal adds an EXECUTE(pre_state_root, post_state_root, trace, gas_used) precompile that returns true iff the stateless execution of trace from pre_state_root ends at post_state_root consuming exactly gas_used, metered by an EIP-1559-style cumulative gas limit. Initially enforced by re-execution, later by validators optionally verifying SNARKs from multiple zkEL clients (no enshrined verifier). A native rollup wraps EXECUTE in a derivation function for sequencing, bridging, forced inclusion, and governance, and so “rid[s] themselves of security councils” and fraud-proof games; it is EVM-equivalent by construction and gets real-time settlement without real-time proving. Based and native are orthogonal; both together is “whimsically called an ‘ultra sound rollup’”.

Unichain: the verifiable-sequencer alternative

Section titled “Unichain: the verifiable-sequencer alternative”

Unichain (OP Stack) keeps a single sequencer but moves block building into a TEE (Intel TDX) running Flashbots’ Rollup-Boost. The builder streams flashblocks, sub-blocks committed every 200–250 ms (four per 1 s block), enforces priority ordering inside each so applications can levy MEV taxes, and drops reverting transactions. UNI-staked operators in the Unichain Validation Network attest to block hashes each epoch to cut equivocation and invalid-block risk. The TEE builder went live in May 2025 and flashblocks in August 2025. Buterin’s 2026 proposal combines both worlds: sequenced blocks most of the time plus a “slot-ending sequenced block” that permits one based block per L1 slot, giving synchronous composability with L1.

4. Worked numeric example

Section titled “4. Worked numeric example”

Preconfer availability. With q=20%q = 20\% of validators opted in, P(no preconfer in 32 slots)=0.832=7.9×10−4P(\text{no preconfer in 32 slots}) = 0.8^{32} = 7.9\times10^{-4}, so Alice finds one with probability 99.92%. With q=5%q = 5\%, 0.9532=0.1940.95^{32} = 0.194: one request in five would find nobody, and the rollup would need fallback sequencing.

Tip and penalty pricing. Alice pays a tip τ=0.0005\tau = 0.0005 ETH. If PP‘s historical missed-slot rate is m=0.5%m = 0.5\% and Alice’s cost of a broken promise (re-quoting after a price move) is c=0.02c = 0.02 ETH, a liveness penalty ℓ\ell makes her whole in expectation when m ℓ≥m cm\,\ell \ge m\,c, i.e. ℓ≥0.02\ell \ge 0.02 ETH; PP will accept if τ≥m ℓ+opportunity cost\tau \ge m\,\ell + \text{opportunity cost}: 0.0005≥0.005×0.02=0.00010.0005 \ge 0.005 \times 0.02 = 0.0001 plus any expected-MEV reduction from committing early. A negative tip is rational when Alice’s swap increases PP‘s expected arbitrage.

Latency. A point-to-point promise arrives in ~100 ms; the promise may settle up to 32 slots (384 s) later, acceptable only because it is collateralized.

Flashblocks. A 1-second Unichain block split into four 250 ms flashblocks gives a swapper a confirmation in ≤250 ms versus a 12 s L1 slot; Unichain’s “200 ms” figure implies five per second. The cost is trusting Intel TDX and the attestation chain rather than L1 consensus for that early confirmation.

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”
  • Taiko — first live based rollup (Type-1 zkEVM, permissionless proposers and provers); the Taiko Labs fallback proposer lost ~83.9 ETH in two weeks to PGA competition (as of 2024-12); phase-one preconfirmations rolled out 11–13 August 2025 to a whitelist of preconfirmers, cutting confirmation from ~45 s to ~2 s, with decentralized preconfs planned for 2026 (Taiko/press, secondary). taiko.xyz
  • Native rollups — EXECUTE precompile proposal (2025-01); no EIP scheduled (as of 2026-08).
  • Unichain — TEE builder on mainnet (May 2025), 200 ms flashblocks (August 2025), UVN staking; 100% of blocks TEE-built (as of 2025-07, Helius). unichain.org
  • MEV taxes on Unichain/OP Stack — see /mev/order-flow-auctions/ and /exchange/v4-hooks-and-am-amm/.
  • Rollup roadmap context — see /foundations/roadmaps/.

Solana

Section titled “Solana”
  • n/a as rollups — Solana scales a single state machine rather than rollups, so “based” has no direct meaning; Solana Permissioned Environments and network extensions are app-chains, not rollups settling to Solana.
  • Preconfirmation analogue — the leader’s ~400 ms slot and Jito bundle inclusion guarantees (“fast, guaranteed inclusion”) play the role preconfs play on Ethereum; BAM proposes an explicit “Pre-Confirmations” plugin notifying users when a transaction is forwarded to a validator (as of 2025-07). See /mev/solana-mev/.
  • Finality analogue — Alpenglow targets ~150 ms median finality with Votor’s single-round voting at 80% participation (Anza, 2025), which removes the need for a separate preconf layer.

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Taiko PGA losses (November 2024). Total-anarchy sequencing produced a priority-gas-auction among L2 proposers; Taiko Labs lost 83.9 ETH (~$261,096) in 15 days while competitors profited, and redundant blocks consumed blob space (Rezzoli, as of 2024-12).
  • Latency races and colocation. Oshitani warns preconfs recreate the HFT arms race: the searcher closest to the preconfer wins all backruns, driving vertical integration and geographic centralization (as of 2024-05).
  • Spam. Cheap L2 fees invite probabilistic arbitrage spam; Solana’s experience (75.7% reverted transactions in April 2024; ~58% of validator time on failed arbitrages per Jito) is the cautionary example.
  • Preconfer information advantage. A preconfer that is also a builder can withhold preconfirmed transactions until its slot, leaving other builders with stale state for up to 32 slots (kartik1507 in the preconf thread, 2023-11).
  • Fair exchange and rugging. A preconfer can take the tip and withhold the promise; mitigations are public promise streams, relays, or tit-for-tat signature exchange (Drake, 2023-11).
  • Sequencer risks that Unichain targets. Block equivocation and invalid blocks by a single sequencer delay economic finality; the UVN attests to canonical blocks to mitigate both (whitepaper, 2024-10). TEE compromise would undermine flashblock guarantees; see /mev/encrypted-mempools/.

7. Open problems

Section titled “7. Open problems”
  • Who captures rollup MEV? Drake argues based rollups’ lost MEV income may be outweighed by winner-take-most dynamics; domothy and bruno_f counter that rollups need MEV revenue to fund development and that L1 capturing “that much value” is undesirable (2023).
  • Are preconfs still “based”? The-CTra1n argues preconfs move sequencing off-chain and make the L1 path “an elaborate forced inclusion list” (2023-11).
  • Promise granularity. Post-state-root promises serialize issuance; state-diff and intent promises parallelize but weaken guarantees; which the market wants is unsettled.
  • Execution tickets vs proposer preconfs. The ET post notes that execution proposers as preconfirmers remove the restaking/inclusion-list dependency but “closely mirrors the mev-geth regime” of trusted parties; see /mev/mev-burn-tickets-focil-timing/.
  • Native rollup proving. One proof per zkEL client and version fragments the p2p layer and under-incentivizes minority clients (Drake, 2025-01).
  • Can flashblocks and based inclusion coexist? Vitalik’s 2026 hybrid makes the L2 sequencer “play a timing game” around the slot-ending block; its incentives are unanalysed (as of 2026-08).

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Scaling modelrollups settling to L1; based vs sequencedsingle monolithic state machine
Who orders L2 txsbased: L1 proposer/builder; sequenced: operator (Unichain in a TEE)the scheduled leader
Fast confirmationpreconfs (slashable promises, ~100 ms); flashblocks (200 ms, TEE)~400 ms slots; Alpenglow ~150 ms finality target
Forced inclusioninclusion lists / L1 forced-inclusion queuesnone needed; leader rotation every 4 slots
MEV destinationbased: L1 proposer; sequenced: rollup/app (MEV tax)leader + Jito tips; BAM plugins
Live examplesTaiko (based, preconfs Aug 2025); Unichain (TEE, flashblocks Aug 2025)n/a

Ethereum’s L2 landscape is a design space precisely because the L1 is slow and rollups can choose where to put trust: in L1 proposers (based), in a company’s sequencer (most rollups), or in attested hardware (Unichain). Solana has no such layer; its ~400 ms slots and coming ~150 ms finality make preconfirmations unnecessary, and its sequencing-trust problem is the leader itself, which BAM addresses with the same TEE tools Unichain uses.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Based rollups—superpowers from L1 sequencing — Justin Drake, 2023-03-10. https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

Summary of the reference

Section titled “Summary of the reference”

The TLDR introduces “based” or “L1-sequenced” rollups whose sequencing “is maximally simple and inherits L1 liveness and decentralisation” and which are “particularly economically aligned with their base L1”. The definition: the next L1 proposer, with L1 searchers and builders, may permissionlessly include the next rollup block in the next L1 block.

Advantages are argued one by one. Liveness: non-based rollups with escape hatches suffer weaker settlement, censorship-based MEV during timeouts, network-effect risk from mass exits (“a sword of Damocles in all known non-based rollup designs”), and gas penalties. Decentralization: the L1 searcher–builder–proposer pipeline is reused and L1 builders are incentivized to include rollup blocks. Simplicity: no sequencer signatures, escape hatch, or external PoS; a historical note explains that Vitalik’s 2021 “total anarchy” concern is resolved by PBS ensuring at most one rollup block per L1 block, and zk proving waste is avoided by proving block nn in block n+kn+k. Cost: zero gas overhead, less code, tokenless. L1 economic alignment: rollup MEV flows to L1 security and, with MEV burn, ETH scarcity, while rollups keep congestion-fee revenue. Sovereignty: based rollups may still have tokens, base fees, and governance.

Disadvantages: no MEV income (counter-argued via winner-take-most dynamics) and constrained sequencing, with fast preconfirmations “an open problem” (EigenLayer, inclusion lists, builder bonds suggested) and FCFS unclear. A naming section acknowledges the collision with Coinbase’s Base and suggests Base “can achieve tokenless decentralisation by becoming based”. The reply thread debates enshrining MEV auctions in the L1 contract (domothy), DoS pricing on the execution layer, and whether PBS alone guarantees one rollup block per L1 block.

Key quotes

Section titled “Key quotes”

“a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block.” (§Definition)

“Based sequencing is maximally simple; significantly simpler than even centralised sequencing.” (§Advantages, simplicity)

“MEV originating from based rollups naturally flows to the base L1.” (§Advantages, L1 economic alignment)

“Fast pre-confirmations with L1 sequencing is an open problem with promising research avenues including EigenLayer, inclusion lists, and builder bonds.” (§Disadvantages)

How to read the original

Section titled “How to read the original”

Background: what a rollup sequencer and escape hatch are, and how PBS/MEV-Boost pipelines work. The post is short; read it all, then the first few replies. The hardest point is the “total anarchy” resolution: the claim that PBS regiments sequencing depends on builders deduplicating competing rollup blocks, which is exactly what did not happen in Taiko’s permissionless proposer market in 2024.

What changed since

Section titled “What changed since”
  • 2023-05: “MEV for Based Rollup” described Taiko’s proposer/prover design.
  • 2023-11: “Based preconfirmations” addressed the latency gap.
  • 2024-05: Taiko mainnet launched as the first based rollup; 2024-12: PGA losses documented.
  • 2025-01: “Native rollups” added L1 execution verification; 2025-02: “Becoming Based” laid out migration paths for existing rollups.
  • 2025-08: Taiko activated whitelisted preconfirmations on mainnet (secondary).
  • 2026-01: Buterin proposed combining sequenced and based blocks for synchronous composability.

Secondary references

Section titled “Secondary references”
  1. “Based preconfirmations” (Drake, 2023) — read next for the latency solution.
  2. “Understanding Based Rollups: PGA Challenges, Total Anarchy, and Potential Solutions” (Rezzoli, 2024) — read for the empirical failure of uncoordinated sequencing.
  3. “Native rollups—superpowers from L1 execution” (Drake, 2025) — read for the execution side.
  4. “Strawmanning Based Preconfirmations” (Oshitani, 2024) — read for the six open problems.
  5. Unichain whitepaper (2024) — read for the sequenced-with-TEE alternative.

The reference

Section titled “The reference”

Based preconfirmations — Justin Drake (with Dan Robinson, Mike Neuder, Brecht Devos), 2023-11-08. https://ethresear.ch/t/based-preconfirmations/17353

Summary of the reference

Section titled “Summary of the reference”

The TLDR promises preconfs “with latencies on the order of 100ms” for based rollups and validiums. Construction: two on-chain requirements, proposer slashing (assumed via EigenLayer-style restaking) and proposer forced inclusion (assumed via inclusion lists). Opted-in proposers become preconfers who sign promises for tips, with precedence by slot order; a promise from the next preconfer can be included immediately by earlier proposers, and an execution queue defers non-preconfirmed transactions. Two slashable faults: liveness (slot missed, transaction not included; amount negotiated) and safety (contradiction; fully slashable). Promise acquisition is left to off-chain design, with considerations: endpoints vs gossip, ~100 ms latency, bootstrapping (1−(1−20%)32≈99.92%1-(1-20\%)^{32} \approx 99.92\%), liveness fallback via parallel promises, parallelization via weaker promise types, replay protection by tying validity to the preconf condition, SSLE compatibility via zero-knowledge proofs of preconfer status, delegated preconfing with fronted collateral, the fair-exchange problem and its mitigations, tip pricing (fixed gas price for most; larger tips when preconfs reduce expected MEV), and negative tips. The thread raises whether preconfs are still “based” (The-CTra1n), reorg risk vs finality-based sequencers (Espresso), builder information asymmetry (kartik1507), and why restaking is needed at all (bruno_f).

Key quotes

Section titled “Key quotes”

“Based preconfs offer a competitive user experience for based sequencing, with latencies on the order of 100ms.” (TLDR)

“Safety faults are fully slashable since honest preconfers should never trigger safety faults.” (§construction)

“if 20% of validators are preconfers there will be a preconfer with probability at least 1 - (1 - 20%)^32 ≈ 99.92%.” (§promise acquisition, bootstrapping)

“Negative tips may be accepted by preconfers, e.g. for DEX transactions that move the onchain price away from the offchain price” (§promise acquisition)

How to read the original

Section titled “How to read the original”

Background: the L1 proposer lookahead, restaking, and inclusion lists. Read construction first, then skim the bulleted considerations. The hardest part is the execution queue: non-preconfirmed transactions included by non-preconfers do not execute until the next non-missed preconfer slot, so the rollup’s state is defined by the preconfer chain, not by L1 inclusion order alone.

What changed since

Section titled “What changed since”
  • 2024-04: “Towards an implementation of based preconfirmations leveraging restaking” (ethresear.ch/19211).
  • 2024-05/06: Strawman critique (latency races, congestion, fair exchange); liveness-penalty analysis (19884); user-defined penalties (19545).
  • 2024-07: Leaderless vs leader-based preconfs compared (19971).
  • 2025-08: Taiko phase-one preconfirmations on mainnet, whitelisted (secondary).

Secondary references

Section titled “Secondary references”
  1. “Strawmanning Based Preconfirmations” (Oshitani, 2024) — read for the problem list.
  2. “Execution Tickets” (Drake & Neuder, 2023) — read for who else could issue preconfs.
  3. “Combining preconfirmations with based rollups for synchronous composability” (Buterin, 2026) — read for the hybrid design.

10. Sources

Section titled “10. Sources”