Coinbase’s blockchain got faster. Some apps can still connect but get no data

Coinbase’s Base blockchain retired its Flashblocks data feeds in the Nov. 5 Denim upgrade, requiring apps using them to migrate. The old WebSocket endpoints still accept connections but no longer deliver data, according to Base’s migration instructions.

Denim activated on mainnet at 18:00 UTC on Nov. 5. Base’s upgrade overview describes complete canonical blocks every 200 milliseconds, each with its own hash, state root and receipts. These are the chain’s blocks rather than previews of a block still being built.

The compatibility trap is that an open connection no longer establishes that an app is receiving updates. Reconnecting to a retired Flashblocks endpoint leaves the underlying integration problem unresolved.

Replace the Flashblocks data route and review what pending-state requests now return.

Schematic routes, not measured traffic or transaction-inclusion latency. Canonical block inclusion remains separate from Ethereum finality.

Sources and evidence

Sources

1. Base migration guide
2. Base Denim overview
3. Base 200ms block specification
4. Base Denim announcement

Supporting facts

• Base’s retired mainnet and Sepolia Flashblocks WebSocket endpoints still accept connections but no longer stream data. [1]
• Apps using retired Flashblocks WebSocket streams should use newHeads or logs subscriptions through a WebSocket-capable RPC provider or their own node. [1]
• The pending block tag is still accepted on Base but now resolves to the latest canonical block; it no longer exposes Flashblocks preconfirmation state and has no direct equivalent for that old state. [1]
• Denim produces complete canonical blocks at a 200ms cadence, each with its own hash, state root, receipts and unsafe-to-safe-to-finalized lifecycle. [2] [3]
• Base says inclusion in a 200ms block does not make a transaction final: a block becomes safe when its batch is posted to Ethereum and final when Ethereum finalizes that batch. [4]

Method

Schematic data routes, not a traffic measurement or latency scale. Rectangles represent complete canonical blocks; arrows identify the replacement data route, with no implied transaction-inclusion guarantee.

Scope

Schematic routes, not measured traffic or transaction-inclusion latency. Canonical block inclusion remains separate from Ethereum finality.

Infographic by CryptoSlate

What apps need to change

Base directs developers to replace Flashblocks connections with subscriptions through a WebSocket-capable RPC provider or their own node. Its replacement map has three main 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.

Developers must also review what their apps expect from the pending block tag. Base still accepts that tag, but it now resolves to the latest canonical block. It no longer exposes Flashblocks preconfirmation state, and there is no direct equivalent for that former preview.

That change matters for requests reading balances, transaction counts or simulated contract results against pending state. An application retaining the old assumption can mistake an accepted response for a preview even though it is reading canonical state.

Transaction handling changes too. Apps can keep polling eth_getTransactionReceipt, but a receipt becomes available once the transaction enters a canonical 200ms block. Preconfirmed receipts and preconfirmed transaction results are no longer available.

Base recommends inventorying Flashblocks subscriptions, WebSocket connections and pending-tag requests, along with flashblock_index usage and node flags. It advises testing migrated integrations on Base Sepolia or Vibenet.

Base’s Denim upgrade notice, still marked “Verifying” on Nov. 9, carried a Nov. 5 update at 18:14 UTC reporting an investigation into periodic transaction inclusion delays and a higher than expected rate of empty blocks. The notice contained no subsequent resolution update.

A 200ms block cadence describes how often blocks arrive; it does not promise that every submitted transaction enters the next block. Inclusion also remains separate from finality. In its Denim announcement, Base says a block becomes safe when its batch is posted to Ethereum and final when Ethereum finalizes that batch. Apps needing those stronger guarantees still have to distinguish them from the arrival of a canonical block.