Bottom line: Native 200ms blocks are the clearest path to preserve Flashblocks-class UX in the protocol itself, remove a large part of the current Base-specific interaction burden, and satisfy a large share of the execution and scaling work that matters most this year.
This document assumes we are already aligned on the objective: ship native canonical 200ms blocks if the system can support them safely and credibly.
Why this matters, briefly:
Trading and realtime UX: Base wins by becoming the best place to build real-time, programmable, always-on market apps, and that the priority is reliable realtime execution, not generic speed claims.
Simplification: Trading feedback is explicit that Flashblocks is a custom Base-only burden. Native 200ms blocks are the cleanest path toward making fast execution feel more standard and less special-case.
Scaling impact: A 10× cadence reduction (with matching gas/sec discipline) absorbs a large fraction of the throughput, latency, and inclusion-predictability work.
The goal is to make clear:
what must be true to ship direct mainnet 200ms,
what the hard gates are,
what work clears those gates,
and what needs to happen next.
State of the world
We are aligned on pursuing native 200ms blocks.
We are targeting direct mainnet 200ms. Anything slower is a UX regression versus Flashblocks today, so it is not an acceptable default outcome for this plan.
We should treat QMDB as an escalation path, not the default critical path.
The immediate goal of Q2 is de-risking the true blockers listed below.
On the proof side, multiprover proof generation largely runs off the hot path. The near-term concern is that, with reth as the only client, the historical proof-serving path must stay close enough to tip and recover from lag under 200ms cadence.
What success looks like
Success means we can ship direct mainnet 200ms with evidence — not intuition — that the system holds up end-to-end at 200ms across the sequencer path, the validator / base-consensus path, follower distribution, proof serving, and the existing ecosystem.
The detailed bar for each of those is defined in Hard gates below. Anything that misses its gate means direct mainnet 200ms is not ready to ship.
How to read this plan
This plan is organized around the decisions and work that determine whether direct mainnet 200ms is credible.
Hard gates define what must be true to ship.
Dependency view shows the workstreams as an interactive tree — what unblocks what.
Critical path shows what must go right in order.
Q2 plan and Immediate next steps translate that into near-term execution.
Hard gates
These are the gates that decide whether direct mainnet 200ms is credible.
Gate 1 — Shipping contract
A single written definition of what shipping native 200ms means.
It must lock:
block-building SLOs,
recovery / failover SLOs,
acceptable validator lag and proof-serving lag,
empty-block SLO,
supported follower topology,
and required mainnet proof posture.
Gate 2 — Timestamp semantics
Final decision on same-second blocks and the compatibility blast radius across contracts, tooling, and downstream consumers.
Gate 3 — Non-QMDB core viability
Prove the non-QMDB state path can support 200ms under realistic profiles. If it cannot, QMDB becomes a real decision instead of a background option.
Gate 4 — Block building performance
Prove the sequencer hot path consistently fits inside 200ms under realistic mempool conditions, target gas, and named load profiles. This includes transaction execution, state root computation, State DB commit, Engine API latency, mempool interaction, assembly/sealing, and gossip initiation.
Gate 5 — Historical proof-serving viability
Prove the reth historical proof-serving path can live with 200ms blocks. Multiprover proof generation mostly runs off the hot path, but proof serving is still a shipping requirement, and with reth as the only client there is no alternate-client escape hatch if this path falls behind.
Must cover same-gas-per-second benchmarking and catch-up after backlog or downtime.
Gate 6 — Distribution / P2P viability
Prove the supported follower topology can stay close enough to the unsafe head at 200ms. If plain gossip is insufficient, the required launch topology must be explicit.
Gate 7 — HA / failover readiness
Prove the sequencer HA path — including op-conductor — can support 200ms without turning failover into empty-block theater. Must cover leader transfer time, failover empty-block behavior, raft latency, payload-size sensitivity, and sustained stability under load.
Gate 8 — Proof / security posture
Establish explicit mainnet posture for output roots, disputes, and proof generation. Multiprover proof generation can remain off the hot path, but the overall proof/security model still needs formal signoff, and any dependence on the reth proof-serving path must be explicit.
Dependency view
This shows the minimum unblock relationships between workstreams.
Interactive Plan
17-Step Dependency Tree
Click a node to unlock it — its children light up when their prerequisites are met. The critical chain runs Steps 1 → 2 → 3 → 5 → (6, 7, 8) → 9 → 10 → 13 → 15 → 16 → 17.
0/ 17 unlocked0/ 13 critical-path
Hover a node for details
Categories
Gate / Decision
Measurement
Execution Layer
Validator / Consensus
Protocol / Economics
Proof / Security
Flashblocks Migration
Distribution / P2P
HA / Failover
Integration / Validation
Release Decision
How it works
Locked — prerequisites missing
Ready — click to unlock
Unlocked
Critical path
The critical path to direct mainnet 200ms is:
Shipping contract
Baseline measurement
Timestamp semantics
Non-QMDB state-root direction
Sequencer pipeline + Engine API + validator path
Historical proof-serving viability
Integrated devnet
Adversarial soak
Public testnet
Mainnet recommendation
Notes:
Proof / output-root posture remains a hard side-gate that must stay green as the effort advances.
op-conductor HA is treated as a Phase 1 feasibility gate, not just a rollout gate: failover behavior at 200ms can veto the path before integrated devnet, so it runs against the Phase 1 perf prototypes (sequencer pipeline, validator throughput, P2P topology) instead of after integration.
Q2 plan
Q2 is the de-risking quarter for direct mainnet 200ms.
Q2 must-complete outputs
Decisions
Shipping contract + success criteria
Written timestamp decision + compatibility matrix
Measurements
Baseline measurement harness
Base-consensus / validator throughput proof
Historical proof-serving benchmark + catch-up
P2P distribution baseline + topology decision
Initial gas / basefee / deposit policy
Prototypes
Non-QMDB state-root MVP verdict
Engine API fast path / batching
Launch-risk characterization
HA failover SLO draft + risk characterization
Flashblocks consumer inventory and transition direction
Q2 expected output
By the end of Q2, we should know:
whether direct mainnet 200ms is credible this year,
whether the non-QMDB path is viable,
whether the supported follower topology is launchable,
whether the historical proof-serving path can stay close enough to tip and recover from lag,
whether HA / failover needs tuning only or deeper change,
and whether the remaining launch risks are now known and bounded.
QMDB escalation rules
QMDB should become critical-path only if the non-QMDB route fails against shipping SLOs.
Pull QMDB forward only if one or more of the following happen:
the non-QMDB path cannot hit 200ms SLOs under realistic load after focused optimization,
commit or replay behavior is structurally incompatible with the required recovery SLOs,
or the non-QMDB state path is too fragile or complex to ship.
Do not escalate to QMDB just because the historical proof-serving path or its retention defaults need tuning. First prove whether the current non-QMDB state path and the reth proof-serving path can be made to work within the contract.
If those triggers are not hit, QMDB stays a parallel long-term state-commitment track.
Immediate next steps
If we were starting this work this week, the next moves should be:
Freeze the written shipping contract, including empty-block policy, topology, proof-serving lag, and failover SLOs.
Land the baseline measurement harness and define same-gas/sec-at-200ms profiles.
Freeze the timestamp decision + compatibility matrix.
Write the proof / output-root pre-gate questions and red-flag criteria.
Choose and benchmark the first non-QMDB MVP hypothesis.
Single base binary to avoid engine API overhead.
Define the historical proof-serving benchmark and catch-up tests.
Define the P2P / topology and HA / failover experiments, then inventory Flashblocks consumers.