Base Moves Toward Five Blocks Per Second
Base is preparing a major change to its block production system through the Denim network upgrade, scheduled for November 5, 2026, at 18:00 UTC. The upgrade will reduce the interval between canonical blocks from two seconds to 200 milliseconds, allowing the network to produce five complete blocks every second.
The change replaces the current Flashblocks model, which provides applications with incremental updates before a full block is produced. Under Denim, each 200-millisecond interval will produce a canonical block with its own block number, hash, state root and transaction receipts. This makes the faster update cycle part of the blockchain itself rather than a separate preconfirmation layer.
The activation time is included in the Base node software's v1.5.1 release. Base Sepolia already activated Denim on October 21, giving developers an environment to test the new block structure before the mainnet rollout.
Flashblocks and Pending-State Access Will End
Flashblocks currently provide applications with transaction and state updates roughly every 200 milliseconds within Base's regular two-second block interval. Developers use these updates to display early transaction information and respond to changes before the complete block becomes canonical.
Denim removes the need for that separate system by turning each 200-millisecond interval into a full block. As a result, Flashblocks subscriptions and the pending state associated with them will no longer be available after activation. Applications that depend on these features must migrate to standard canonical block and RPC data.
This is a significant integration change for wallets, decentralized applications, trading systems and blockchain indexers. Software that continues requesting the retired Flashblocks feeds or relying on pending-state responses will no longer receive the same preconfirmation information after the upgrade.
Developers Must Update Their RPC Integrations
Base's migration guidance outlines replacements for several Flashblocks-specific subscriptions. Applications using newFlashblocks should move to the standard newHeads subscription, while integrations relying on pendingLogs should use the regular logs subscription.
Developers consuming newFlashblockTransactions will need to subscribe to newHeads and then retrieve the transactions included in each canonical block. RPC calls that previously used the pending block tag must also be adjusted to read the latest canonical state or request a specific block number.
The changes affect methods such as eth_getBalance, eth_getTransactionCount, eth_call, eth_estimateGas and eth_simulateV1. Queries through eth_getLogs that end at the pending block tag must also be changed to use the latest canonical block or a specified block height. The Base Flashblocks migration documentation provides the relevant subscription and RPC replacements.
The important difference is that canonical block data will replace preconfirmed state. Developers should not assume that the new subscriptions provide an identical pending-state experience; applications may need to adjust how they display transaction progress and process updates.
Block-Based Timers Will Move Faster
The shorter block interval also affects smart contracts that measure time by counting blocks rather than using timestamps. Because Base will produce blocks ten times faster, a duration defined by a fixed number of blocks will take approximately one-tenth as long in real-world time.
For example, a contract delay of 30 blocks currently represents about 60 seconds at a two-second block interval. After Denim, the same 30 blocks will take approximately six seconds. This can affect block-counted timelocks, vesting schedules, governance delays, cooldown periods and other contract logic that uses block numbers to measure duration.
Developers should review contracts and application settings that depend on block.number before the upgrade. By contrast, the EVM's block.timestamp field will continue to use whole-second timestamps, so time-based logic using that field will not automatically become ten times faster.
Base Adds Millisecond Timestamp Support
Although the standard block timestamp remains in seconds, Denim introduces additional infrastructure to represent the sub-second timing of the new blocks. A BaseTime system deposit in each block supplies the millisecond component, allowing applications to obtain more precise timing information.
The upgrade also introduces optional millisecond timestamp fields in relevant RPC responses. These include timestampMs for blocks and headers, and blockTimestampMs for transactions and logs. The additional fields allow developers and indexers to work with the more frequent block production without changing the existing seconds-based timestamp format.
The Denim technical specification describes the BaseTime mechanism and the RPC changes. Applications that require millisecond-level timing will need to use the new metadata or supported RPC fields rather than attempting to derive that precision from the standard block timestamp.
Testing and Preparation Ahead of Mainnet Activation
Base Sepolia's October 21 Denim activation provides developers with an opportunity to test integrations before the mainnet change. The experimental Vibenet environment also supports 200-millisecond native blocks for early testing, although experimental deployments may change.
For production applications, preparation involves identifying every Flashblocks subscription, locating RPC calls that use the pending tag and reviewing contracts that calculate durations using block counts. Indexers should also prepare to process a higher number of canonical blocks as the network moves from one block every two seconds to five blocks per second.
The Base v1.5.1 release notes specify the mainnet Denim activation time and the required node software update for operators. With the November 5 rollout, Base is changing not only how quickly blocks are produced but also how applications receive transaction and state information. Developers and infrastructure providers will need to complete the transition to canonical block data to maintain compatibility with the upgraded network.
