---
title: "Flashblocks"
type: concept
tags: [flashblocks, latency, preconfirmations, sequencer]
updated: 2026-06-19
confidence: high
sources: [raw/llms_txt_doc-flashblocks-overview.md, raw/llms_txt_doc-flashblocks-faq.md]
---

# Flashblocks

**Flashblocks** are **200ms incremental state updates** the Base sequencer streams between full blocks, sharply reducing perceived latency — users see their transaction reflected in ~200ms rather than waiting a full ~1s block.

## Key facts

- **Always on.** Every Base block is built by the Flashblocks builder; Flashblocks are not optional and are always live.
- **Preconfirmation, not finality.** A Flashblock is an early, partial view of the block being built. It gives fast UX feedback; full settlement still follows the normal block → L1 batch → proof path ([chain-architecture](chain-architecture.md), [proof-system](proof-system.md)).
- **Two ways to consume** — a dedicated WebSocket stream of incremental Flashblock updates, and standard RPC methods that surface the latest "pending" Flashblock state (the `newflashblocks` / pending-logs surfaces in [docs-catalog](../summaries/docs-catalog.md)).

## Building against it

Apps wanting the snappiest UX subscribe to the Flashblocks WebSocket and optimistically reflect the preconfirmed state, then reconcile against the confirmed block. Latency-sensitive reads can target the pending Flashblock. This 200ms cadence is one of the concrete [differences from Ethereum](what-is-base.md).