Flashblocks are 200-millisecond pre-confirmations on Base. Instead of waiting the full two seconds for a block, your app learns that a transaction will be included in about a tenth of that time, then updates the interface before the block is sealed.
This is a timing change, not a protocol change. Your contracts, your transactions, and Base’s two-second blocks all stay the same. What changes is how early your backend can see a result and act on it. The practical payoff is a user experience closer to a Web2 app: click, confirmed, done.
Base turned this on for mainnet on July 17, 2025, after running it on the Base Sepolia testnet since early that year (The Block). Below is what the feature is, who it helps, and the exact methods you use to read and stream pre-confirmed data.
What are Base’s 200ms pre-confirmations?
A pre-confirmation is an early, reliable signal that a transaction will land in the next block, sent before that block is finished. On Base, the chain streams a new partial block every 200ms, and each one carries the transactions committed so far. Base calls these partial blocks Flashblocks.
The feature was built by Flashbots and runs through rollup-boost, which Flashbots describes as “a lightweight sidecar designed to upgrade existing sequencers” (Flashbots). The sidecar sits next to Base’s sequencer, assembles transactions into these 200ms increments, and streams them out as they are built.
The Base team framed the goal in plain terms: a transaction should go “from click to confirmed in the time it takes to think.” On Base Sepolia, the team measured up to a tenfold drop in transaction inclusion time (Base).
Why faster confirmations matter for your app
Two seconds does not sound like much until a user is staring at a spinner. On a trading screen or a checkout flow, that gap is where people tab away, double-click, or assume something broke. Pre-confirmations close most of it.
The benefit is strongest anywhere the interface reacts to a transaction. A swap can show “filled” almost immediately. A payment page can release a digital good without a two-second pause. A wallet can update a balance the moment the transfer is pre-confirmed instead of polling and waiting.
There is a second, quieter benefit for backends. Systems that need to read state right after writing it, such as a bot checking a nonce or a service confirming a deposit, get an answer sooner and spend less time polling for the same result.
How Base’s sub-blocks work under the hood
Each 200ms update is incremental. It contains the new transactions since the last one, not a fresh copy of the whole block, and the series rebuilds into a normal two-second block at the end (Base docs).
Gas capacity ramps up across the series rather than being available all at once. The builder lets each successive sub-block use a larger cumulative share of the block’s gas limit, so the first increment already has roughly 40 million gas of room, which is more than enough for any single valid transaction to fit.
Ordering still works the way it does on standard Base blocks: transactions are ordered by fee. The only real difference is when you find out. One edge case to know about is that a late-arriving, higher-fee transaction can land after a lower-fee one that was already committed to an earlier sub-block, so the sequence is not always a clean fee ranking.
How many sub-blocks make up a single Base block?
Ten, in the normal case. A two-second Base block is built from a series of up to ten 200ms increments, indexed 0 through 10 (Base docs). Index 0 holds only system transactions and uses no gas; indices 1 through 10 carry the pending transactions pulled from the mempool.
Do not hard-code that count, though. Indices above 10 can appear when the sequencer runs slightly long, and fewer than ten are normal when the previous block took extra time to build. The index resets to 0 whenever a new block starts.
Is a pre-confirmation final, or can it be reverted?
A pre-confirmation is a strong signal, not settlement. In rare cases a sub-block can be streamed and then not make it into the sealed block, which counts as a reorg. Base targets a reorg rate below 0.1%, and rollup-boost includes changes that prevent the last sub-block in a series from being dropped (Base docs).
For most interface updates, that risk is low enough to treat a pre-confirmation as done. For anything irreversible, such as shipping a physical order or crediting an account, wait for standard confirmation. The cleanest signal that a block is actually complete is a change in its payloadId or a confirmation through a normal RPC call. In extreme conditions the sequencer can disable pre-confirmations network-wide and fall back to plain two-second blocks, so your code should handle that path too.
Who actually needs 200ms confirmations?
Not every app does. A governance dashboard or an analytics tool that reads historical data gains little from faster inclusion. The feature pays off when a human or a bot is waiting on a fresh transaction.
The clearest fits:
- Decentralized exchanges and perps venues, where a trader wants instant feedback that an order was accepted.
- Payment and checkout flows, where a two-second hold reads as friction at the worst moment.
- Wallets, which can confirm sends and refresh balances without a visible lag.
- On-chain games and social apps, where actions need to feel immediate.
- Trading bots and backend services, which can confirm state and move to the next step faster.
If your app never makes a user wait on a transaction, pre-confirmations are a nice-to-have. If it does, they change how the product feels.
How to consume pre-confirmations in your app
There are two ways to get pre-confirmed data, and most apps use both. You poll the pending tag over HTTPS for simple reads, and you subscribe over WebSocket when you need updates pushed to you the instant they happen.
| Approach | How it works | Best for |
|---|---|---|
Poll the pending tag (HTTPS) | Your app calls standard methods with "pending" on an interval | Status checks, read-after-write, simple integrations |
| Subscribe (WebSocket) | eth_subscribe pushes each update as it streams | Live UIs, trading, anything that reacts the moment a transaction is pre-confirmed |
Reading pre-confirmed state with the pending tag
The simplest integration needs no new endpoints. You call familiar JSON-RPC methods and pass "pending" as the block tag, and the response reflects the sub-block currently in progress instead of the last sealed block.
| Method | What "pending" returns |
|---|---|
eth_getBlockByNumber | The sub-block currently being built |
eth_getBalance | Balance including pre-confirmed transactions |
eth_getTransactionCount | Nonce including pre-confirmed transactions |
eth_getTransactionReceipt | A pre-confirmed receipt before the block seals |
eth_getLogs | Logs up to the pre-confirmed tip, as toBlock |
eth_estimateGas / eth_simulateV1 | Estimates and simulations against pre-confirmed state |
One catch is worth planning around. When you run eth_call with "pending", the call executes on top of a recent base block, so values like block.number, block.timestamp, and block.basefee can be up to five blocks behind the chain tip. Nodes keep up to five historical blocks of pre-confirmed state for this reason. If your contract logic depends on an exact current block number, account for that lag.
Streaming sub-blocks over WebSocket
Polling works, but it wastes requests and adds latency between updates. For a live view, subscribe instead. Over a WebSocket connection you can use eth_subscribe with a few Base-specific subscriptions:
newFlashblocksstreams the full pre-confirmed payload as each sub-block is built.newFlashblockTransactionspushes individual pre-confirmed transactions.pendingLogsdelivers filtered logs from pre-confirmed transactions, which is useful for watching a specific contract.
There is also base_transactionStatus, which tells you whether the mempool has received a given transaction yet.
One rule from the Base docs matters here: do not point your app at the raw Flashblocks WebSocket feed directly. That feed is meant for infrastructure syncing between nodes, and its payloads are RLP-encoded rather than app-friendly. Consume pre-confirmations through the pending methods or eth_subscribe on a provider or your own node instead (Base docs).
Limitations and edge cases to plan for
A short checklist of things that trip people up:
- Public endpoints are HTTP only and rate limited. Base’s free public endpoints do not support WebSocket, so streaming needs a WebSocket-capable endpoint. They are fine for a prototype, not for production traffic.
- Pre-confirmation is not finality. Handle the sub-0.1% reorg case for any action you cannot undo.
- Do not trust the index count. Treat the number of sub-blocks as variable, and use a
payloadIdchange to detect a completed block. - Watch the N-5 block context. Contract calls against
"pending"may see a slightly stale block number and timestamp. - Expect out-of-order fees. The dynamic mempool means a later, higher-fee transaction can appear after an earlier, lower-fee one.
None of these are blockers. They are the difference between a demo that looks fast and a production app that stays correct when the network is under load.
Connecting to Base without running your own node
To use pre-confirmations in production, your app needs an endpoint that exposes the pending methods and, for streaming, supports WebSocket. Since Base’s public endpoints are HTTP only and rate limited, that leaves two routes: operate your own Flashblocks-aware Base node, or connect through a provider that already runs one.
Running your own means syncing Base, keeping it current, and scaling it under traffic, which is a standing operational cost. A managed provider removes that work and hands you an endpoint and an API key. NOWNodes, for example, offers Base mainnet access over both HTTPS and WebSocket (base.nownodes.io/wss) as part of its 120+ supported networks, so you connect to the chain instead of maintaining a server for it.
If your app leans on pre-confirmed state, two things are worth checking. Confirm that the endpoint exposes the pending behavior your code relies on, and size your plan for the extra request volume that frequent polling creates. Shared access suits development and moderate load; a dedicated node, with one machine per network and no predefined request-per-second limit, fits an app that polls the pending tag hard or streams continuously, with real throughput bounded by the allocated hardware.
The takeaway
Flashblocks make Base feel fast without asking you to change your contracts or your transaction flow. You opt in on the read side: poll the pending tag for simple checks, subscribe over WebSocket for live updates, and keep treating standard confirmation as the real settlement signal for anything you cannot reverse.
Start on Base Sepolia, wire up a single pending call or a newFlashblocks subscription, and compare it against a normal block read. The difference is obvious on screen, and from there it is mostly a question of which endpoint you point at and how you handle the handful of edge cases above.
FAQ
Do I need to rewrite my smart contracts to use pre-confirmations on Base?
No. Flashblocks change how quickly your app reads results, not how contracts execute. You only adjust the client side, by passing the "pending" tag or subscribing over WebSocket.
Are Flashblocks available on Base’s testnet?
Yes. They ran on the Base Sepolia testnet from early 2025 before the mainnet launch in July 2025, and Base Sepolia is the recommended place to test an integration.
Do Flashblocks make Base transactions cheaper?
No. They affect timing, not cost. Gas pricing and fee-based ordering work the same as on standard two-second blocks.
Can I use Flashblocks with viem or ethers?
Yes. Because the feature works through the standard "pending" block tag and normal JSON-RPC methods, common libraries handle it without special tooling, and viem and wagmi ship a preconfigured Base Sepolia chain for testing.
