Base Activates Denim, Moves to Producing 5 Standard Blocks per Second
Key Facts
Base activated the Denim upgrade on its mainnet on November 5, making it the network’s fourth upgrade and moving to production of 5 standard blocks per second, according to Base Engineering. The change cuts the interval between blocks from one block every 2 seconds before the upgrade to a new pace of 5 blocks per second. Base announced that Denim “is now live on mainnet” and replaces Flashblocks with full standard blocks. Flashblocks provided successive updates on the status of a pending transaction while a block was being built, before the standard block arrived. The upgrade puts block production timing and how applications handle time at the center of the changes, alongside amendments to the B20 standard.
Before Denim, Base produced one standard block every 2 seconds, while Flashblocks bridged the gap by streaming gradual updates on the pending status of the block under construction, according to the engineering team’s explanation. After the upgrade, standard blocks themselves are produced at a rate of 5 per second. Base said Flashblocks no longer produces a separate stream after being replaced. The change distinguishes between status updates that appeared while a block was being built and the inclusion of a transaction in a completed standard block. The new figure therefore describes the rate of block production and does not, on its own, determine when a transaction becomes final.
Denim added the BaseTime layer, which enables contracts and applications to measure elapsed time and verify deadlines with millisecond precision, according to Base Engineering. The upgrade also expanded RPC responses to include optional millisecond-precision timing fields for blocks, headers, transactions, logs and receipts. These fields, including timestampMs and blockTimestampMs, are derived from attested BaseTime data. Base kept the usual timestamp field in seconds unchanged to preserve backward compatibility. The upgrade thus combines more precise timing for developers with retention of the existing field used by current applications.
Base warned that contracts and systems outside the network that use block counts to measure a period of time will see that period shrink to one-tenth of what was intended after the pace of block production increases. The team recommended reviewing assumptions tied to block counts and using block.timestamp comparisons when a contract can be redeployed or upgraded. This review is important for applications that use the passage of a specified number of blocks to determine when a timeout expires or an action is executed. Base stressed that inclusion of a transaction in a block lasting 200 milliseconds does not in itself make it final. A block becomes safe when its batch is posted to Ethereum, then becomes final when Ethereum finalizes that batch.
Denim also included changes to the B20 standard, adding transfer checks and reusable compliance policies, according to Base Engineering. Base documentation says transfers, minting and reservations to the token’s own address are rejected. The transfer-operator policy requirement also now applies to all transfer paths, and any policy can be inverted using a NOT flag. These rules add controls to the handling of transfers and token-related operations. This part of the upgrade sits alongside changes to block production and timing, without changing Base’s technical description of the update into a commitment to increase network capacity.
In an update at 18:14 UTC on November 5, Base confirmed that Denim had been activated successfully, but said it was investigating periodic delays in transaction inclusion that caused a higher-than-expected rate of empty blocks. The delay marked the first operational issue the network announced after activation, as it moved to the new pace of block production. Base had also asked node operators to upgrade to v1.5.1 before activation, then recommended in a later update that they use v1.5.3 to remove the risk of validator downtime linked to an invalid state root. The network said it had verified the state root was valid and that users were unaffected, adding that operators did not need to resync or take any other action. The status update did not specify when the investigation into inclusion delays would be completed.