What are Flashblocks? Faster confirmations for L2 rollups

TL;DR

Ethereum’s rollup-centric roadmap has made enormous strides in throughput and cost reduction. But one problem has proven stubborn: latency. Even on L2s, users wait 2 seconds for a transaction to confirm. That might sound fast compared to Ethereum mainnet’s 12-second block time, but it falls short for the applications blockchain infrastructure is increasingly being asked to support, from high-frequency DeFi to responsive on-chain gaming to real-time payment flows.

Flashblocks gets that as low as 200 milliseconds by streaming partial blocks to nodes every 200ms while keeping the 2-second block structure intact underneath. The expensive parts of block production, state root calculation and consensus, still happen once per full block. Users just stop waiting for them.

Introduction: the L2 latency problem

L2s like Base inherit their block time from the OP Stack sequencer, which produces blocks every 2 seconds. This is already a significant improvement over Ethereum mainnet, but it still creates friction for latency-sensitive applications.

The obvious fix is to reduce the block time. The problem is that doing so naively is not sustainable.

Producing a block requires calculating the state root, a cryptographic commitment to the entire resulting chain state. Doing this every 200ms imposes severe computational overhead on every node in the network, making syncing progressively slower as chain state grows. Sub-second block times also require significant modifications to Geth or Reth that harm EVM equivalence. Maintaining 1:1 compatibility with anything built on Ethereum while minimizing protocol complexity is a core OP Stack design goal, and naively fast blocks put that at risk.  

What are Flashblocks?

Flashblocks are ephemeral sub-blocks streamed every 200ms within a standard 2-second block window. Rather than producing a new full block at each interval, the sequencer produces lightweight partial blocks and streams them to nodes in real time. At the end of the 2-second window, all accumulated Flashblocks are committed into a single finalized block.

The key is deferred computation. State root calculation and consensus happen only once per full block rather than once per Flashblock. Each 200ms interval gives users a transaction preconfirmation, confirming that their transaction has been ordered and executed without waiting for the full block to be sealed.

On Base, each 2-second block is composed of 10 Flashblocks, each with its own transaction ordering. The sequencer streams these over WebSocket to nodes with the Flashblocks module enabled.

The approach draws inspiration from Solana’s shreds and Celestia’s data squares, both mechanisms for streaming partial block data to network participants before finalization, enabling incremental execution rather than batch delivery. Flashblocks applies the same idea while staying within EVM equivalence and the 2-second block structure the OP Stack depends on.

The team behind the infrastructure

Flashblocks is developed by Flashbots, the organization originally known for productizing MEV on Ethereum through MEV-Boost, co-designed with Uniswap Labs and OP Labs. They open-sourced two components that power the system: op-rbuilder, a Rust-based block builder that separates transaction execution from state commitment, and Rollup-Boost, the sequencer sidecar that plugs into an existing OP Stack sequencer without requiring changes to the core protocol.

Architecture: how Flashblocks work

The implementation is two-sided. On the sequencer side, Rollup-Boost runs as a sidecar that continuously builds and streams partial blocks every 200ms over WebSocket. On the node side, the Flashblocks module on Base’s Reth fork receives those streams and updates local state at each interval rather than waiting for a full block.

Flashblock state is surfaced via standard Ethereum JSON-RPC methods using the pending tag. The key distinction from a finalized block is visible in one field: stateRoot is zeroed out, reflecting that the chain state has not yet been committed. Once the full block is sealed, the state root is calculated and the block is finalized.

Because Flashblocks piggybacks on the existing pending tag rather than introducing new methods, existing dApps can support it with minimal code changes.

Example request:

```bash
curl -sS -X POST "$YOUR_CHAINSTACK_BASE_RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["pending",false]}'

Calling eth_getBlockByNumber with pending on a Flashblocks-enabled endpoint returns the block as it is being built, not only after final sealing. A zeroed stateRoot indicates preconfirmation.

// Flashblock preconfirmation (~200ms, illustrative)
{
  "stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "receiptsRoot": "0x5f2dd9fbe32e2c22e47d84edbe6a300e75a004495191ff9f6228ce5de8f7c6f8",
  "hash": "0x61792b40d824cb6e99ad07de112c823e0f86995063c00486e8dd3ef9667b40fc"
}
// Finalized 2s block (illustrative)
{
  "stateRoot": "0x16a1375def73d111a7dcfcd39acbcdbe935acf011e645c8f37af2a05af72af71",
  "receiptsRoot": "0x26dc0c64a01f87aecf3e112fa92c06845757dbc72b708bf783c97b425828cdb5",
  "hash": "0xb09354e0fd87cd9c379c456ab41ea9b4ff1c684bea7705e19bb237f621b588f0"
}

📖 For implementation details, see Chainstack documentation: Flashblocks on Base.

Base has also contributed a Flashblocks WebSocket Proxy, a Rust-based service sitting between the sequencer and downstream nodes. It subscribes to the Flashblocks stream and fans out to multiple nodes, protecting the sequencer from direct connection load and implementing rate limiting via Redis with an in-memory fallback.

On OP Mainnet, Optimism runs a similar setup with one additional layer: op-conductor, which manages sequencer orchestration and ensures only the active leader forwards Flashblocks downstream, guarding against split-brain scenarios where multiple builders might emit conflicting streams simultaneously.

Node state propagation: the trust tradeoff

When a node receives a Flashblock, it needs to update its local state. There are three ways to do this, each at a different point on the trust spectrum.

• Re-execution: The node independently re-executes all transactions in the Flashblock to compute the resulting state itself. No new trust assumptions, but more compute on the node side.
  
• Direct state acceptance: The node accepts the resulting state from the sequencer directly, without re-executing. More efficient, but it requires trusting the sequencer to have the state computed correctly.
  
• Verified state acceptance: The node receives the resulting state alongside a proof, either a ZK proof or TEE (Trusted Execution Environment) attestation, verifying the state was reached legitimately. This is the most robust option and where the roadmap points.

The endgame is nodes serving verified early Flashblock execution state via RPC, making Flashblocks indistinguishable from full blocks at the application layer. A user swapping tokens would get a wallet confirmation with updated balances within 200ms. TEE attestations for Flashblock validity are on the roadmap but not yet available in the public rbuilder implementation.

Impact on L2 UX and application design

On a standard Base endpoint, confirmation times average around 2000ms. On a Flashblocks-enabled endpoint, real-world latency drops to roughly 300 to 500ms, accounting for the 200ms Flashblock interval plus network travel time. That gap is small in absolute terms but significant in practice.

For DeFi, the effects show up in market structure. Faster blocks shrink the window during which stale prices can be arbitraged against liquidity providers, lowering adverse selection costs and tightening spreads. Research suggests LPs on L2s with faster block times achieve around 20% higher fee returns and 75% more concentrated liquidity around the midmarket price compared to Ethereum mainnet. Unichain leans into this directly, pairing Flashblocks with verifiable priority ordering to reduce adverse selection costs and make on-chain trading more competitive with centralized exchanges.

The implications extend further though. Responsive payment interfaces and on-chain applications that need to react to user input all become more viable when confirmation is measured in hundreds of milliseconds rather than seconds. Much of what feels native to Web2 but out of reach on-chain today comes down to latency, and Flashblocks chips away at that gap.

Flashblocks vs. alternative approaches

Arbitrum’s Direct Block Approach

Arbitrum achieves fast confirmations by producing full blocks every 250ms. The user-facing speed is comparable, but the method differs. Full blocks at 250ms require a state root calculation at each interval, carrying significant computational overhead and introducing EVM equivalence issues from modifying core execution clients. The sustainability of this approach becomes a concern as chain state grows.

Flashblocks sidesteps that by amortizing the expensive computation across the full 2-second window, achieving similar confirmation speeds with substantially lower overhead per interval.

📖 Learn more: Transaction lifecycle on Arbitrum.

Timeboost

Arbitrum’s Timeboost targets a different problem. Rather than focusing on raw latency for everyone, it addresses MEV and ordering fairness. It is a time-based priority auction where transactions pay a fee to receive a time boost of up to 500ms, moving their effective timestamp earlier in the queue.

The important distinction is that Timeboost does not reduce latency universally. It increases baseline transaction delay by introducing the auction mechanism, then selectively reduces it for users who pay. The system captures MEV value for the protocol and addresses latency-racing in first-come-first-served systems, but it is solving an adjacent problem to the one Flashblocks targets.

📖 Learn more: Timeboost.

Conclusion

Flashblocks is designed to be chain-agnostic within the OP Stack. While the technology is already live on Base (at 200ms) and OP Mainnet (at 250ms), infrastructure availability is rolling out in phases. Chainstack currently provides Flashblocks-enabled endpoints for Base, with Optimism support to follow.

The broader Rollup-Boost roadmap extends further. An encrypted mempool would keep transactions private throughout their entire lifecycle, visible only within secure TEE hardware. TEE validity proofs would use a multi-prover approach to help rollups qualify as Stage 2, where two separate proving systems must agree before the system proceeds, with a fast and cheap TEE prover acting as the second alongside a more expensive ZK prover.

TEE coprocessing goes further still, enabling private computation running alongside the EVM that would let smart contracts interact with Web2 systems and store private state, opening up application categories that are currently out of reach on-chain.

Combined with OP Succinct’s ZK-based fast finality and native Reth support, Flashblocks is one part of a larger push to make the OP Stack competitive across every dimension, balancing speed, security, and developer experience.

Getting started with Flashblocks on Base via Chainstack

1. Create a Base RPC endpoint on Chainstack Flashblocks is currently supported on Base Mainnet and Testnet Sepolia. If you already have a Chainstack Base RPC endpoint on a supported node type, it’s Flashblocks-ready by default. You can create new endpoints in just a few clicks.
2. Connect your app, script, or tool Use your Chainstack RPC URL in your web3 app, wallet, script, or curl requests. All standard Ethereum JSON-RPC methods are supported, including the enhancements Flashblocks introduces.
3. Use Flashblocks features with standard RPC methods There are no new SDKs or complex integrations. You can start using the “pending” tag with methods like eth_getBlockByNumber, eth_getBalance, or eth_getTransactionCount to access real-time blockchain data.

Flashblocks on Chainstack unlocks near-instant confirmations, ideal for anything time-sensitive.

FAQ

Related articles

• Flashblocks on Base: 200ms preconfirmations via Chainstack RPC
• Best Base RPC providers for on-chain applications in 2026
• Ethereum without L2: Charting the impact of rollups on network performance
• zkEVM and zkRollups Explained