Base’s 200ms Upgrade Removes Flashblocks Preconfirmation Data

By Elena Vasquez

Base’s Denim upgrade uses a 200-millisecond block cadence but no longer exposes Flashblocks preconfirmation state, according to the network’s upgrade documentation. That cadence equates to one-fifth of a second, not a guarantee that submitted transactions enter the next block.

Base treats block arrival, transaction inclusion and finality as separate events. The upgrade can therefore leave applications connected while changing the meaning of the data they receive.

The Denim notice remained marked “Verifying” on Nov. 9. Its Nov. 5 update at 18:14 UTC reported an investigation into periodic transaction inclusion delays and a higher-than-expected rate of empty blocks.

Is the upgrade fully resolved?

Base included no subsequent resolution update in the notice. Faster block production does not itself resolve either issue, because the cadence describes only how often blocks arrive.

What must developers replace?

Base directs developers to replace Flashblocks connections with subscriptions through a WebSocket-capable RPC provider or their own node. Its replacement map specifies three subscription changes:

• newFlashblocks becomes newHeads, which follows canonical block headers.
• pendingLogs becomes logs.
• newFlashblockTransactions becomes newHeads, followed by fetching the transactions in each canonical block.

Base still accepts the pending block tag, but it now resolves to the latest canonical block. The network no longer exposes Flashblocks preconfirmation state and provides no direct equivalent for the former preview.

Applications that retain the old assumption may mistake an accepted response for a preview. Requests for balances, transaction counts and simulated contract results can consequently return canonical-state data where they expect pending-state data.

What happens to transaction receipts?

Applications may continue polling eth_getTransactionReceipt, but a receipt becomes available only once the transaction enters a canonical 200-millisecond block. Base has discontinued preconfirmed receipts and preconfirmed transaction results.

That change removes intermediate signals applications previously used to track submission progress. It also requires teams to distinguish canonical confirmations from the preconfirmed results their software may still assume exist.

What should teams test before deployment?

Base recommends inventorying Flashblocks subscriptions, WebSocket connections and pending-tag requests. Teams should also review flashblock_index usage and node flags, then test migrated integrations on Base Sepolia or Vibenet.

The guidance names test environments but sets no migration deadline. That omission matters because an apparently successful connection does not prove that an application has preserved its intended data semantics.

What does finality mean on Base?

In its Denim announcement, Base says a block becomes “safe” when its batch is posted to Ethereum. It becomes “final” when Ethereum finalizes that batch.

Applications requiring those stronger guarantees must distinguish them from the arrival of a canonical block. A 200-millisecond cadence establishes block frequency, not transaction inclusion or finality.

Before production deployment, teams should complete the recommended Base Sepolia or Vibenet migration tests as canonical subscriptions replace Flashblocks preconfirmations. They should also monitor the Denim notice, which remained unresolved on Nov. 9.