Subblocks on Optimism: 200ms preconfirmations

Use Subblocks (formerly Flashblocks) on Optimism through Chainstack for 200ms transaction preconfirmations via standard JSON-RPC calls with the pending tag.

Get started with a reliable Optimism RPC endpoint to use Subblocks.

Subblocks are partial blocks that the Optimism sequencer streams about every 200 ms while it builds each 2-second block. Chainstack Optimism Mainnet nodes follow this stream and serve the preconfirmed state through standard JSON-RPC methods with the pending block tag.

Subblocks were previously called Flashblocks. Subblocks replaced Flashblocks on Optimism Mainnet on August 31, 2026, which shortened the interval from 250 ms to 200 ms and kept the JSON-RPC interface the same.

OP Labs builds and maintains Subblocks. Flashblocks, the earlier implementation, is built and maintained by Flashbots.

How Subblocks work on Optimism

Subblocks on Optimism have two parts:

• Sequencer side — the Optimism sequencer’s execution client produces a subblock as it builds each block and publishes the subblocks over a WebSocket stream.
• Node side — the Reth-based execution client running on Chainstack follows the stream, executes the transactions in each subblock, and serves the result under the pending block tag.

This two-part architecture implements the following flow:

• The Optimism sequencer creates regular 2-second blocks and, while building each block, publishes a subblock about every 200 ms.
• Each subblock appends transactions to the block in progress. The transaction list only grows until the block is sealed.
• Apps retrieve the preconfirmed state over the standard Optimism RPC endpoints and methods:
  • eth_getBlockByNumber with the pending tag
  • eth_call with the pending tag
  • eth_getBalance with the pending tag
  • eth_getTransactionCount with the pending tag
  • eth_getCode with the pending tag
  • eth_getStorageAt with the pending tag
  • eth_estimateGas with the pending tag
  • eth_getTransactionReceipt — returns the preconfirmed receipt as soon as the transaction is included in a subblock
  • eth_getTransactionByHash — returns the preconfirmed transaction as soon as it is included in a subblock
  • eth_sendRawTransactionSync — submit a signed transaction and receive the preconfirmed receipt in the same response

The 200 ms interval is a target, not a guarantee, so the number of subblocks in a 2-second block varies and is about 10.

Unlike Base, Optimism does not expose preconfirmations as dedicated WebSocket subscriptions like eth_subscribe newFlashblocks. The customer-facing interface on Optimism is the standard JSON-RPC interface with the pending block tag, as defined in the Optimism Subblocks specification.

Compare preconfirmed subblocks with the sealed block

Call eth_getBlockByNumber with the pending tag on an Optimism endpoint while a 2-second canonical block is forming. The response changes with each subblock: the block number stays the same, the transaction list grows, and the block hash changes.

The same canonical block number sampled about 500 ms apart while the block was being built on Chainstack, and then after it was sealed:

Preconfirmed subblock (early)

"number": "0x97806d8",
"hash": "0x8ef10a9d6049c93d205a91a416ea0989988d68b8f236f8e51bce31376334f70c",
"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"transactions": [ /* 2 transactions */ ]

Preconfirmed subblock (later)

"number": "0x97806d8",
"hash": "0x10a6f84ffa45dbbf6bc91aa431162bb002c067e73bddef2e990461cdb3a80b3d",
"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"transactions": [ /* 7 transactions */ ]

Sealed 2-second block

"number": "0x97806d8",
"hash": "0xe1d8b7956db9c4fc0996474306b376157729ed3106d32bd5d1b3438fc1edf3d9",
"stateRoot": "0x7ffd13ffee70dfc77e6da2fa81cf1a00358b438c1e886e55a9c403d2d721849e",
"transactions": [ /* 16 transactions */ ]

The block number stays the same across all three samples. Only the transaction list grows and the preconfirmation hash changes.

In a pending response, stateRoot is all zeros, because the state root is exact only once the block is sealed. The pending hash is not the hash of the sealed block either. Read the final hash and stateRoot from the block after it is sealed, and track transactions by their own hash.

Verify Subblocks on your endpoint

You can verify Subblocks on your Optimism endpoint by polling eth_getBlockByNumber with the pending tag and watching the response change within a single block number. Replace YOUR_OPTIMISM_ENDPOINT with your Chainstack Optimism node HTTPS endpoint:

for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -s "YOUR_OPTIMISM_ENDPOINT" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["pending",false]}' \
    | python3 -c "import sys,json; b=json.load(sys.stdin)['result']; print(int(b['number'],16), b['hash'], len(b['transactions']))"
  sleep 0.2
done

On an endpoint that follows Subblocks, you see multiple distinct hashes and growing transaction counts for the same block number within a 2-second window.

Performance expectations

Subblocks on Optimism are produced about every 200 ms, so a pending read reflects a transaction long before the 2-second block that includes it is sealed. A latest read reflects the transaction only after the block is sealed.

The actual preconfirmation time depends on:

• Network latency to and from the Optimism node.
• Transaction processing time at the sequencer.
• Time until the next subblock (up to about 200 ms).
• Gas available in the next subblock. The sequencer divides a block’s gas capacity across the block-building window, so a transaction with a large gas limit can wait for a later subblock or the next block.
• Network travel time for the confirmation response.

Subblock preconfirmations are not final. A preconfirmed receipt from eth_getTransactionReceipt, eth_sendRawTransactionSync, or a pending-tag call can be revoked if the Optimism sequencer abandons or reorganizes the block in progress. Wait for the transaction to be included in a finalized canonical block before releasing funds or considering a payment settled.

Optimism Subblocks vs. Base Flashblocks at a glance

Aspect	Optimism	Base
Preconfirmation feature	Subblocks	Flashblocks
Interval	200ms	200ms
Canonical block time	2s	2s
Preconfirmations per block	~10	~10
Customer-facing interface	JSON-RPC with pending tag	JSON-RPC with pending tag and dedicated WebSocket subscriptions
eth_subscribe newFlashblocks etc.	Not exposed	Exposed

Additional resources

• Flashblocks on Base — the Base implementation, including dedicated WebSocket subscription methods
• Optimism documentation: Subblocks overview
• Optimism documentation: Integrate Subblocks in your app
• Optimism documentation: Subblocks notice — the move from 250 ms to 200 ms and the zeroed stream fields
• Optimism specification: Subblocks

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