Flashblocks on X Layer: Engineering 200ms Finality with Zero Reorg
How we built the fastest flashblocks implementation with 5X higher throughput, zero reorgs, and the industry's fastest RPC sync
At X Layer, we're building the infrastructure for the next generation of onchain applications. Speed matters — and not just perceived pre-confirmed speed, but real, chainstate finality. In January 2026, we shipped Flashblocks on X Layer mainnet and made X Layer 5X faster, reducing the effective transaction and chainstate finality from 1 second to just 200 milliseconds — while simultaneously achieving the highest flashblocks sequencer throughput among all OP Stack chains. This post is a technical deep dive into the engineering details of Flashblocks. We will provide an in-depth walkthrough of our custom flashblocks builder integration on X Layer sequencers, the zero-reorg protection system that guarantees flashblock finality, and the industry-leading RPC architecture that delivers ultra-low latency chainstate updates to downstream consumers.
Recap on Flashblocks
By default, blocks are produced every 1 second on X Layer. Flashblocks are sub-block units streamed by the sequencer during a single L2 block period. Instead of waiting for the full 1-second block to finalize, the sequencer produces incremental flashblocks every 200ms, each containing newly executed transactions. These flashblocks are streamed in real-time to RPC nodes and downstream subscribers, giving users and applications near-instant transaction confirmations. This is extremely useful for DeFi apps (DEX, wallets), payments, games, and real-time interactions since transaction and chainstate latencies are dropped significantly.
Payments: Instant payment confirmations
DeFi: Swaps and positions that update immediately
Marketplaces: Fast, frictionless checkout flows
Games: Real-time actions with no waiting between moves
Optimizing the Default Flashblocks Architecture on OP Stack
The standard Flashblocks architecture — as designed by Flashbots and deployed on other OP chains — follows a proposer-builder separation (PBS) model. It introduces two key sidecar components alongside the existing sequencer:
Rollup-boost: a proxy that sits between the consensus layer (op-node) and the execution layer, intercepting Engine API calls and managing flashblock payload state.
Op-rbuilder: an out-of-protocol builder running on op-reth that performs the actual incremental flashblock construction and streams payloads to rollup-boost via WebSocket.
However, when integrating flashblocks into our sequencer using this architecture, we found that this failed to meet X Layer sequencer throughput production targets (measured in gas/s). We identified 3 key optimization areas to significantly improve our sequencer throughput:
State mismatch between rollup-boost and the builder
The rollup-boost component (which acts as the proposer) is inherently stateful — it accumulates a pending flashblocks sequence from the builder's websocket stream, and this sequence is treated as the canonical payload. Thus, on payload resolution, this could result in race conditions — rollup-boost resolves its cached sequence, but the builder is still producing new flashblocks, leading to dropped flashblocks (reorg happens) between the committed payload and the actual builder's locally built payload. This causes the subsequent engine_newPayload chainstate sync to cache-miss on the underlying Reth engine, triggering an expensive re-validation of the payload that was built by the same builder. This further wastes precious sequencing time and severely affects the maximum throughput of the sequencer.
Redundant execution across two EL clients
The default architecture maintains both op-rbuilder and the sequencer's default EL (op-geth) as separate execution clients. Both payload builders build the same payload job from their locally shared transaction pool, doubling compute and deployment overhead while requiring state synchronization across all ELs.
State root deferral adds synchronous overhead
The default design optimizes flashblock building time by skipping state root computation on the builder. However, this means that rollup-boost is still required to send an additional engine_ForkchoiceUpdate to the default EL to re-execute the full payload just to calculate the state root again — which adds another synchronous operation and overhead of re-executing the full payload transactions, and a blocking wait for state root calculation during payload resolution. Because of this, the builder commits to its engine state tree the built payload with an empty state root. Similar to the state mismatch issue (point 1), this triggers a full expensive payload re-validation on the builder's chainstate sync, since cache misses of locally built blocks will happen 100% of the time due to block hash mismatch.
X Layer's Custom Builder: Unified Sequencer Architecture
This motivated us to optimize the architecture when integrating flashblocks into X Layer. Our most significant architectural decision was to eliminate rollup-boost entirely and integrate the flashblocks payload builder directly into our custom xlayer-builder. This single change resolved all three bottleneck issues and delivered a >5X improvement in sequencer throughput (measured in gas per second) compared to the default flashblocks architecture. Instead of running op-rbuilder as a separate sidecar and rollup-boost as the payload building proposer, we integrate the flashblocks builder directly into our xlayer-reth node payload builder. We also reduce significant deployment compute overhead by running just a single xlayer-reth execution client (the previous architecture required a default EL, rollup-boost, and the builder EL). The block construction workflow now becomes straightforward:
Every 200ms, the leader sequencer constructs the next flashblock, yields transactions from the txpool, executes them, and gossips the new flashblock to flashblock subscribers via websocket subscriptions.
On payload resolution (engine_getPayload), the flashblocks payload builder gossips the last flashblock, calculates the state root asynchronously on payload resolution, and commits that payload to the local engine state tree.
On chainstate sync (engine_newPayload), the new unsafe payload will always be a cache hit and payload validation is skipped entirely — since no race conditions or state mismatches will happen now. The next block building can start immediately afterwards.
engine_forkchoiceUpdated advances the chain tip. The next block cycle begins.
Why This Is Faster
The performance gains come from eliminating every source of redundant work:
Single source of truth. There is one EL, one payload state. No state mismatch is possible because the builder and the proposer are the same process.
Zero cache misses on payload commits. Every engine_newPayload hits locally built blocks in the engine state tree. We measured 100% cache hit rates under sustained load.
No redundant re-execution. The state root is computed once and asynchronously during payload resolution, by the same EL that built the payload. No external FCU to a secondary EL is needed.
Single EL compute/memory footprint. Deploying one EL client per sequencer instead of two reduces infrastructure costs and eliminates cross-process synchronization overhead.
Zero-Reorg Protection: Guaranteeing Flashblock Finality
In the old architecture, flashblocks reorg occurrences were too high to be truly used safely — for example, there was a 100% probability of flashblocks reorg happening whenever the leader sequencer switched, because the new leader would simply restart block building from scratch, discarding all previously propagated flashblocks. Thus, reducing latency to 200ms is only meaningful if those 200ms confirmations are final. We made significant engineering optimizations in X Layer multi-sequencer deployment to reduce flashblock reorgs by introducing a builder p2p protocol and flashblocks replay protection. We built a comprehensive zero-reorg protection system that guarantees flashblock finality at the application layer across all normal operational scenarios.
Builder P2P: The Foundation
Every sequencer in our high-availability cluster (leader and followers) maintains persistent P2P connections via the op-rbuilder's built-in P2P layer. When the leader sequencer mints a new flashblock, it atomically gossips the flashblock payload to all peer sequencers and handles gossip failures at this layer, before broadcasting to the connected RPC node subscribers. This P2P layer serves two purposes: it ensures all nodes in the cluster have consistent flashblock state, and it provides transport for the replay mechanism described in the next section.
Flashblocks Replay: Surviving Sequencer Switches
The core of our zero-reorg protection is the flashblocks replay feature. Every follower sequencer maintains an in-memory cache of the current pending flashblock sequence, indexed by the payload job's parent hash. This cache is populated as flashblocks arrive from the leader via P2P. When a leader sequencer switch occurs (due to failure, restart, or routine rotation), the newly promoted leader checks its cache: if the payload building job matches the current cached flashblock sequence (accumulated while it was a follower), we will prevent these already-gossiped flashblocks from being dropped or reorged by replaying them instead of rebuilding the payload from scratch. This means that gossiped flashblocks are atomic in nature and every transaction that was already included in a propagated flashblock remains included, in the same order, in the new leader's block. From the perspective of RPC nodes and downstream consumers, the sequencer switch is invisible — no flashblocks are reverted and flashblocks finality is guaranteed on the application layer.
Industry's Fastest Flashblocks RPC
The sequencer can produce flashblocks at 200ms, but users only benefit if RPC node sync is fast enough to serve that chainstate with minimal additional latencies. We made significant optimizations on our X Layer flashblocks RPC implementation by completely revamping the flashblocks RPC layer design from the default OP stack implementation — achieving >4X faster sync validation speed compared to the default design.
Architecture Overview
Every RPC node connects to a flashblock payload stream via websocket — either directly from the sequencer cluster or from another RPC node (forming a relay gossip protocol). When engineering our flashblocks RPC layer, we designed it with the intention of using a hybrid sync approach: consuming both incoming flashblocks and maintaining the default EL/CL block sync. Thus, we designed these 4 key components to allow the flashblocks state accumulation layer to run ahead of the canonical chainstate.
FlashblockStateCache: In-memory data store that overlays the canonical chain, maintaining both the pending state (the most updated chainstate) and a confirmed cache of completed block states that are ahead of the canonical tip. RPC queries against latest resolve from the confirm cache tip; queries against pending resolve from the current pending sequence.
FlashblockSequenceValidator: Executes incoming flashblock transaction sequences by using Reth's highly optimized PayloadProcessor that contains optimized caches (sparse trie cache and execution cache). We also share it with the default Reth engine payload validator.
XLayerEngineValidator: A unified controller wrapping both Reth's BasicEngineValidator and the FlashblockSequenceValidator behind a single mutex, to ensure state consistency of the shared payload processor. The controller ensures consistency in our hybrid sync approach and prevents races between the 2 incoming sources (flashblocks and incoming default full blocks).
FlashblocksRpcService: Top-level service that consumes the websocket stream, manages incoming flashblock deltas, and coordinates with the flashblocks validation execution tasks.
Three-Tiered Cache Design
The performance of our RPC layer comes from a novel three-tiered state caching hierarchy, where each tier serves a distinct role in the state lifecycle — from optimistic pre-confirmation state all the way down to durable on-disk persistence.Tier 1 — Flashblocks state cache (optimistic accumulation). The FlashblockStateCache is the outermost and fastest-moving overlay on the canonical chainstate. It maintains two categories of state that run ahead of the canonical chain tip:
Pending cache: The current in-progress pending block being built on the sequencer. As each flashblock arrives (FB0, FB1, FB2…), the FlashblockSequenceValidator incrementally executes the accumulated sequence. RPC queries using the pending tag read directly from this cache. Note that the sparse trie state is revealed but state root calculation is skipped for intermediate flashblocks to minimize latency and is only computed on full sequences.
Confirm cache: In-memory caching overlay of executed confirmed block states that have been fully executed and state-root-verified, but are still ahead of the canonical chain. RPC queries using the latest tag read from this cache state, allowing the RPC node flashblocks state sync to be decoupled from the Reth engine canonical chainstate.
Tier 2 — Reth engine canonical chainstate (in-memory). This is Reth's standard engine tree state — the in-memory representation of the canonical chain. The flashblocks state cache is also flushed on new canonical updates once the default sync catches up.Tier 3 — Persisted chainstate (on-disk database). This is Reth's underlying database layer (MDBX), managed by Reth's engine persistence handle (no change here from the underlying Reth node). RPC sync flow — (flashblocks ahead, canonical behind)
Flashblock deltas arrive via WebSocket stream → FlashblocksRpcService accumulates raw payloads in the RawFlashblocksCache and enqueues build arguments into the ExecutionTaskQueue.
Incremental execution: The FlashblockSequenceValidator consumes from the task queue. Flashblocks sequences are validated with the Reth payload processor, which includes:
Optimistic parallel pre-warming of account states from incoming delta transactions
Incrementally revealing multiproofs and updating the sparse trie on hashed state updates
Executing delta transactions and updating pending state, without state root calculation
Sequence completion: On sequence end, the validator computes the full state root by resolving the state root task on the sparse trie pipeline, and computing the state root using the highly optimized sparse trie cache. The completed block is promoted from pending to the confirm cache.
Engine cache hit: When the consensus layer sends engine_newPayload, the XlayerEngineValidator checks the flashblock state cache and skips payload re-validation entirely of already validated blocks. The canonical chain advances.
Canonical eviction: handle_canonical_block manages the flashblocks state cache and evicts confirm cache entries once the canonical chainstate reaches that block height.
Persistence flush: The engine tree flushes the newly canonical block state to Tier 3's on-disk database.
What's Next
Flashblocks access list support (EIP 7928): fBAL is already supported on xlayer-builder in development. We intend to further optimize the flashblocks RPC sync to use fBAL for parallel transaction execution validation.
Sparse trie cache support on xlayer-builder: To further optimize the X Layer sequencer overall chain throughput.
Flashblocks on X Layer represent a fundamental step toward making onchain interactions feel instant. By rethinking the default architecture and building purpose-fit infrastructure, we've achieved latencies that unlock entirely new categories of onchain applications — from real-time trading to interactive gaming to instant payments.
© 2025 OKX. Anda boleh memproduksi ulang atau mendistribusikan artikel ini secara keseluruhan atau menggunakan kutipan 100 kata atau kurang untuk tujuan nonkomersial. Setiap reproduksi atau distribusi dari seluruh artikel juga harus disertai pernyataan jelas: “Artikel ini © 2025 OKX dan digunakan dengan izin.“ Petikan yang diizinkan harus mengutip nama artikel dan menyertakan atribusi, misalnya “Nama Artikel, [nama penulis jika ada], © 2025 OKX.“ Beberapa konten mungkin dibuat atau dibantu oleh alat kecerdasan buatan (AI). Tidak ada karya turunan atau penggunaan lain dari artikel ini yang diizinkan.
