---
title: "Flashblocks Overview"
description: "Flashblocks deliver 200ms preconfirmed sub-blocks on Base, streaming state updates 10x faster than the standard 2-second block cadence."
source: https://basehub.org/flashblocks/overview/
---
import { Aside } from '@astrojs/starlight/components';

Flashblocks are 200ms preconfirmed sub-blocks streamed by the Base sequencer, giving applications fee-ordered state updates ten times per standard 2-second block.

## What are Flashblocks

Flashblocks add **200ms** incremental state updates to Base, cutting perceived latency for end users.

The mechanism, built with [Flashbots](https://www.flashbots.net/), streams sub-blocks inside the regular 2-second block interval. Apps see preconfirmations from the sequencer well before the full block is gossiped to the network.

<Aside>
Flashblocks are always live on Base — every block is built by the Flashblocks builder. Apps choose whether to consume preconfirmations or wait for the standard 2-second finality.
</Aside>

<Aside type="caution" title="Denim will retire Flashblocks">
Upstream plans to deprecate Flashblocks in the [Denim](/specifications/denim-200ms-blocks/) hardfork, which turns each 200ms interval into a canonical block and ends Flashblocks production. Upstream briefly filed this retirement under Cobalt in early September 2026 and has since moved it back to Denim. Sepolia is now scheduled: the node activates Denim there on October 21, 2026 at 18:00 UTC, starting with `v1.5.0-rc.4`, which is when Sepolia Flashblocks are due to stop. Mainnet has no timestamp and still targets November 2026. Canonical 200ms blocks are live on Vibenet, so you can test the new behaviour early. [Migrate to 200ms Blocks](/flashblocks/migrate-to-200ms-blocks/) lists the application changes each integration eventually needs. Everything else on this page describes how Base works today.
</Aside>

### Key concepts

| Term | Definition |
|------|------------|
| **Flashblock** | A 200ms sub-block carrying part of the full block's transactions. |
| **Preconfirmation** | An ultra-fast signal that a transaction will be included, before the full block is sealed. |
| **Full Block** | A sequence of 10 Flashblocks combined into the complete 2-second block. |

Each block contains **10 Flashblocks** (indexes 1-10), arriving every 200ms. Index 0 exists but only carries system transactions. See [Gas and transaction sizing](/flashblocks/app-integration/#gas--transaction-sizing) for how the gas budget evolves across the window.

## Architecture

For details on the sequencer system and the Flashblocks infrastructure components (rollup-boost, base-builder, websocket-proxy, and base), see the [Architecture](/flashblocks/architecture/) page.

## Transaction lifecycle

When a transaction is sent to Base, this is the path it takes:

### 1. Submission

```
User → DNS (mainnet.base.org) → Load Balancer → Proxyd → Mempool
```

The transaction lands in the private mempool and is added to the txpool as pending.

### 2. Distribution

The mempool keeps P2P connections open with execution layers (base-reth-node, base-builder), keeping all pending transactions in sync for block building.

### 3. Block building

In each 200ms loop, base-builder selects transactions using:

1. **Transaction fee** — transactions are ordered fee-first (highest first).
2. **Gas limit and remaining capacity** — Flashblock `j` may use up to `j/10` of the total block gas limit.

<Aside>
**Dynamic mempool.** The builder runs against a dynamic mempool that keeps accepting new transactions while it builds. This minimizes inclusion latency, but a late-arriving high-fee transaction can land after a previously-committed lower-fee transaction inside the same Flashblock. This is expected — transactions are ordered by fee *at the moment they are selected*.
</Aside>

### 4. Block building algorithm

For each 2-second block, the builder runs:

```
FOR each flashblock j FROM 0 TO 10:
    1. Wait until next 200ms window
    2. Calculate available gas: (j / 10) × total_block_gas_limit
    3. Sort pending transactions by fee (descending)
    4. Select top transactions that fit within available gas
    5. Execute transactions and update state
    6. Stream flashblock to websocket-proxy
```

<Aside>
**Index 0** carries only system transactions and uses no gas budget. **Indexes 1-10** are the actual Flashblocks that consume from the txpool.
</Aside>

### 5. Preconfirmation delivery

Once a transaction is included in a Flashblock, the builder streams it to the websocket-proxy. RPC nodes subscribe to that stream, so a Flashblocks-aware RPC method (such as `eth_getTransactionReceipt`) can return preconfirmed data straight from the node's cache.

<Aside>
The full infrastructure stream schema lives in the [Flashblocks API overview](/api-reference/flashblocks/flashblocks-api-overview/), including the [Flashblock](/api-reference/flashblocks/flashblocks-api-overview/#flashblock-object), [Diff](/api-reference/flashblocks/flashblocks-api-overview/#diff-object), [Metadata](/api-reference/flashblocks/flashblocks-api-overview/#metadata-object), and [Receipt](/api-reference/flashblocks/flashblocks-api-overview/#receipt-object) objects.
</Aside>

## Further reading

- [FAQ](/flashblocks/faq/) — common questions about Flashblocks.
- [Block Building](/network/block-building/) — detailed block ordering configuration.
- [Flashblocks deep dive](https://blog.base.dev/flashblocks-deep-dive) — engineering blog post with implementation details.