Base Denim Upgrade: Native 200ms Blocks Replace Flashblocks

Base has scheduled the activation of the Denim network upgrade for November 5 at 18:00 UTC on its mainnet. The upgrade introduces native blocks at a 200-millisecond cadence, replacing the previous Flashblocks mechanism with a new canonical block structure.

The network’s status notice indicates that mainnet is expected to remain operational throughout the maintenance window. Node operators are instructed to install the required software release before the activation time to ensure compatibility with the new block cadence.

Shift to Canonical Block Streams

Denim moves the network from one canonical block every two seconds to five complete blocks each second. This change replaces Flashblocks, meaning applications that currently rely on that stream must migrate to canonical block and RPC streams.

Software that reads blocks, receipts, and timestamps must adapt to the higher frequency. Block identifiers are used to organize receipts, update balances, or determine when to refresh trading screens. With the increased block frequency, exchanges may need to process more updates between two user interactions, and indexers will encounter more block records and more frequent state changes.

The primary technical challenge for developers is maintaining application responsiveness. A faster chain can create a backlog within an application’s own infrastructure if the backend is not optimized to handle the increased volume of data points.

Finality and Time Handling

A shorter block interval improves the time to observe execution but does not automatically establish finality rules for bridges, exchanges, or financial applications. These services maintain additional rules governing when a result can be relied upon or a balance released. A wallet that receives a faster network update but waits on a slow backend may show little improvement in user experience.

Denim also introduces millisecond-aware time information while preserving existing seconds-based fields. This creates a compatibility issue for systems that assume a new block always brings a new whole-second timestamp. Under the new system, multiple blocks can fall into the same second. Applications that group events solely by stored timestamps might merge unrelated records or process them in the wrong order if they mistake the shared value for a unique ordering key.

Post-activation success will be evidenced by stable block production, correctly indexed activity, and normal handling of deposits, withdrawals, and contract interactions. The upgrade is currently scheduled infrastructure work and has not yet occurred.