Flashblocks on Base: 200ms preconfirmations

Enable Flashblocks on Base through Chainstack for 200ms transaction preconfirmations, making your dApp experience up to 10x faster on the network.

Base’s Denim upgrade replaces Flashblocks with canonical 200ms blocks. Denim activated on Base Sepolia on Oct 21, 2026, at 18:00 (UTC), so Flashblocks subscriptions and pending state are no longer available on Base Sepolia. Base Mainnet serves Flashblocks until Denim activates there in November 2026, which is Base’s current target. To move your integration to newHeads, logs, and regular RPC calls, see Base’s migration guide.

Get started with a reliable Base RPC endpoint to use Flashblocks.

Flashblocks is a block builder sidecar for Optimism Stack chains. This sidecar is called Rollup-Boost. It’s designed and built by Flashbots—the same team that originally productized MEV on Ethereum. Co-designed with Uniswap Labs and OP Labs.

The Base team has implemented Flashblocks on the Base chain. Flashblocks went live on the Base Mainnet in July 2025.

The Flashblocks implementation on the Base chain is two-part:

• Sequencer side — The Rollup-Boost sidecar is installed next to the Base sequencer by the Base team.
• Node side — The Flashblocks module is implemented on the Base fork of the Reth node.

This two-side architecture implements the following Flashblocks flow:

• Base sequencer creates regular 2-second blocks and additionally creates sub-blocks called Flashblocks every 200ms.
• Base sequencer streams these Flashblocks every 200ms over WebSocket to the Base Reth nodes that have the Flashblocks module enabled.
• The sequencer-streamed Flashblocks & Flashblock states can then be retrieved by apps over the standard Base RPC endpoints & methods:
  • eth_getBlockByNumber with pending tag
  • eth_getTransactionReceipt
  • eth_getBalance with pending tag
  • eth_getTransactionCount with pending tag
  • eth_getTransactionByHash with pending tag
  • eth_call with pending tag
  • eth_sendRawTransactionSync
• The transaction ordering is done at the Flashblocks level instead of the block level.

Additionally, the following WebSocket subscription methods are available exclusively on Flashblocks-enabled endpoints:

• eth_subscribe newFlashblockTransactions — stream individual transactions as they are pre-confirmed (~200ms each)
• eth_subscribe pendingLogs — stream filtered event logs from pre-confirmed transactions
• eth_subscribe newFlashblocks — stream full Flashblock payload objects from the sequencer

Each 2-second block on the Base chain is formed after 10 different Flashblocks have been processed—each Flashblock with its own transaction ordering.

Quick Flashblock vs. full block data comparison

Let’s call an eth_getBlockByNumber with the pending tag to get the latest block data on a Flashblocks-enabled and non-Flashblocks-enabled node at the same time as block 33228756 was being formed on the Base mainnet.

See the results in the Chainstack Labs base-flashblocks-transaction-latency-test repository:

• eth-get-block-by-number-pending-examples/preconfirmed-flashblock.log — the result of running "method":"eth_getBlockByNumber","params":["pending",true] on a Flashblocks-enabled node as block 33228756 was forming.
• eth-get-block-by-number-pending-examples/confirmed-block.log — the result of running "method":"eth_getBlockByNumber","params":["pending",true] on a non-Flashblocks-enabled node as block 33228756 was formed.

You will see the key differences in the results:

• Transaction count — 52 in the Flashblock vs. 167 in the fully formed block.
• stateRoot — empty in the Flashblock vs. computed in the fully formed block. An empty stateRoot at this point means there’s no final chain state for the block, hence “preconfirmation” in the name.
• blockHash — different in the Flashblock and the fully formed block. The finalized transactions will have the hash of the fully formed block attributed to them.
• receiptsRoot — different in the Flashblock and the fully formed block.

A quick view:

Preconfirmed 200ms Flashblock

"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"receiptsRoot": "0x5f2dd9fbe32e2c22e47d84edbe6a300e75a004495191ff9f6228ce5de8f7c6f8",
"blockHash": "0x61792b40d824cb6e99ad07de112c823e0f86995063c00486e8dd3ef9667b40fc",

Confirmed regular 2s block

"stateRoot": "0x16a1375def73d111a7dcfcd39acbcdbe935acf011e645c8f37af2a05af72af71",
"receiptsRoot": "0x26dc0c64a01f87aecf3e112fa92c06845757dbc72b708bf783c97b425828cdb5",
"blockHash": "0xb09354e0fd87cd9c379c456ab41ea9b4ff1c684bea7705e19bb237f621b588f0",

Transaction latency test tool

See the Chainstack Labs base-flashblocks-transaction-latency-test repository for the latency test tool and the comprehensive README file.

Performance expectations

Flashblocks are produced at 200ms intervals, but actual confirmation times will be higher due to network latency:

• Standard Base endpoint — ~2000ms (2-second block time)
• Flashblocks-enabled endpoint — ~300-500ms (200ms Flashblock interval + network travel time)

The actual confirmation time depends on:

• Network latency to/from the Base node
• Transaction processing time
• Time until next Flashblock (up to 200ms)
• Network travel time for confirmation response

Additional resources

• Chainstack blog: Flashblocks is live on Chainstack: even faster Base RPC
• Base Flashblocks transaction latency test repository
• Base documentation: Flashblocks
• Base blog: We’re making Base 10x faster with Flashblocks
• Flashbots blog: Introducing Rollup-Boost
• Original spec for Rollup-Boost idea: External Block Production

About the author

Ake

Director of Developer Experience @ Chainstack
Talk to me all things Web3
20 years in technology | 8+ years in Web3 full time years experience