AI-ready infrastructure
Refer and earn
Ethereum
Hyperliquid
Solana
Arbitrum
BNB Smart Chain
Base
Polygon
TRON
Sui
Robinhood
Base Denim upgrade: what 200 ms blocks mean for RPC
For years, Ethereum L2 scaling faced a fundamental performance bottleneck where block times capped at whole seconds, which created noticeable latency for high-frequency trading and real-time state updates. Temporary preconfirmation layers like Flashblocks only offered fragmented previews rather than full canonical blocks. To overcome these constraints, Base has introduced the Denim upgrade.
What is the Denim upgrade?
Denim is Base’s fourth independent network upgrade, following Azul, Beryl and Cobalt. It activated on Base Sepolia on October 21, 2026, and on Base Mainnet on November 5, 2026, at 18:00 UTC. The upgrade permanently phases out Flashblocks by shifting native block production from once every two seconds down to 200 milliseconds, or five canonical blocks per second.
Every 200 ms slot delivers a fully realized canonical block with its own block number, hash, state root, receipts and forkchoice lifecycle, backed by a new millisecond-accurate BaseTime metadata deposit.
Architecture and protocol changes
To avoid breaking existing smart contracts and execution clients, Base had to design the change around block times with care.
The standard Ethereum block header timestamp remains in whole seconds to preserve contract compatibility. To achieve sub-second precision without breaking core execution client assumptions, Base requires every canonical block to contain a specialized BaseTime metadata deposit transaction at index tx[1].
This payload encodes the exact sub-second offset, restricted to 0, 200, 400, 600 or 800 milliseconds. RPC nodes parse it to expose the new timestampMs and blockTimestampMs fields.
![Diagram of five consecutive Base blocks sharing one header timestamp, each with a different BaseTime millisecond part, and the block layout with the L1 attributes deposit at tx[0] and the BaseTime deposit at tx[1]](https://chainstack.com/wp-content/uploads/2026/11/base-denim-basetime-five-blocks.png)
Denim also implements breaking updates to the B20 token policy. Policies can now be inverted with a NOT flag, and a transfer, mint or seize that credits the token’s own address reverts. For background on the standard, see What is B20?
The impact on RPC infrastructure
Before Denim, RPC infrastructure operated on a predictable two-second block interval, with nodes handling roughly 43,200 blocks per day. Developers relied on seconds-based timestamps across headers, transactions and logs, while applications tracked real-time activity using HTTP polling or transient Flashblock preview feeds and pending-state endpoints.
Shifting to a five-block-per-second cadence changes how RPC nodes process and serve data. Block production grows from 43,200 blocks per day to 432,000 blocks per day, which increases daily block volume and places a much heavier workload on node indexing databases.
To support millisecond tracking without breaking legacy clients, RPC responses introduce:
- New
timestampMsandblockTimestampMsfields derived from authenticated BaseTime metadata deposits. These are optional millisecond fields. - Standard seconds-based timestamp fields that remain intact for existing applications, for backward compatibility.
- The complete retirement of Flashblock preconfirmation feeds, which requires applications to shift toward continuous ingestion of standard canonical block feeds.
As a result, nodes must handle ten times the indexing load while providing the low-latency transport required for sub-second canonical state updates.
What this means for developers
Because block production accelerates tenfold while EVM header timestamps stay in whole seconds, any contract logic tied directly to block counters experiences a sharp compression in wall-clock time.
Smart contracts that use block.number for temporal measurements will see governance windows, timelocks, staking cooldowns and per-block rate limits execute ten times faster than intended. This can introduce security and economic vulnerabilities if the logic is left unrefactored.
Beyond onchain code, sub-second blocks break traditional client data pipelines. HTTP polling can miss several 200 ms blocks per tick, and Base does not offer a free public WebSocket endpoint for Mainnet or Sepolia (its public endpoints are HTTP only). Production applications should stream canonical blocks over WebSocket (WSS) from a node provider and treat the push feed as the primary source.
| Feature | Pre-Denim (2-second blocks) | Post-Denim (200 ms blocks) |
|---|---|---|
| Block time and production | 2 seconds (~43,200 blocks/day) | 200 milliseconds (~432,000 blocks/day) |
| Data ingestion model | HTTP polling or Flashblock preview feeds | WebSocket (WSS) streams as the primary source, HTTP polling can miss blocks |
| Timestamp resolution | Whole-second EVM block.timestamp | Millisecond precision via BaseTime and optional RPC fields |
| Block-number contract logic | Standard pace for timelocks and vesting schedules | Runs 10x faster in wall-clock time (requires prior refactoring) |
The path forward
The Denim upgrade marks a major leap forward for Base. By moving to 200 ms native blocks, Base positions itself as a premier L2 for high-frequency trading and instant-execution applications, inherently boosting developer usability and end-user experience.
This release establishes sub-second canonical block execution as the new performance benchmark across the Ethereum ecosystem. We’re in very exciting and interesting times when it comes to the evolution of L2 infrastructure. Developers can already test their integrations using Vibenet.
But as with any advancement, sustaining high throughput and sub-second streaming requires enterprise-grade infrastructure. High-performance node infrastructure like Chainstack is essential to ensure uninterrupted sub-second streaming and low latency under heavy production loads.
Moving to Denim on Chainstack
Every Flashblocks call has a canonical replacement on Chainstack Base nodes. The replacements return data from sealed 200 ms blocks, not preconfirmed data.
| Flashblocks call | Use instead |
|---|---|
eth_subscribe("newFlashblocks") | eth_subscribe("newHeads") |
eth_subscribe("newFlashblockTransactions") | eth_subscribe("newHeads"), then fetch the transactions of each block |
eth_subscribe("pendingLogs") | eth_subscribe("logs") |
Any call with the "pending" tag | The same call at "latest" |
Chainstack limits that count blocks now cover one tenth of the time they did before Denim, because one block is 200 ms. A call 127 or more blocks behind the tip is an archive request that costs 2 RUs, which on Base is about 25 seconds. An eth_getLogs range of 10,000 blocks, the cap on the Growth plan and above, covers about 33 minutes, and the Developer plan’s 100-block range covers 20 seconds. To scan a longer period, split the query into consecutive ranges that fit your plan.
On Chainstack nodes. Chainstack documents the Denim changes, including the replacement table and the limits that count blocks, in Base Denim: 200 ms blocks. For tested Python and JavaScript that streams transactions and event logs with
newHeadsandlogs, see Stream real-time transactions on Base.
FAQ
Denim activated on Base Sepolia on October 21, 2026, at 18:00 UTC, and on Base Mainnet on November 5, 2026, at 18:00 UTC.
Base produces a canonical block every 200 ms instead of every 2 seconds, which is five blocks per second. Each block has its own hash, state root and receipts. Block production grows from about 43,200 blocks per day to about 432,000.
Base no longer produces Flashblocks, and their subscriptions stop delivering notifications. The newFlashblocks and newFlashblockTransactions subscriptions move to newHeads, pendingLogs moves to logs, and the "pending" block tag has no direct equivalent, so read at "latest" instead.
The standard timestamp field stays in whole seconds, so about five consecutive blocks share the same value. Millisecond precision comes from the optional timestampMs and blockTimestampMs RPC fields, which are derived from the BaseTime deposit at tx[1] of every block.
They keep working, but any duration written as a block count elapses ten times sooner. Multiply block-count durations by ten to keep their wall-clock length, and divide per-block caps by ten. Logic that measures time with block.timestamp is unaffected.
Yes, in practice. Polling every 250 to 1,000 ms can miss several 200 ms blocks per tick, and Base provides no free public WebSocket endpoint, only HTTP. Stream blocks over WebSocket from a node provider and treat the push feed as the primary source.
Related reading
- How to get a Base RPC endpoint in 2026
- What are Flashblocks? Faster confirmations for L2 rollups
- Base Transaction Lifecycle: Sequencer, Finality, and RPC
- Base Migration: From OP Stack to base/base (2026)
- What is B20? Base’s new native token standard explained
- Best Base RPC providers for onchain applications in 2026
- Base Denim: 200 ms blocks (Chainstack docs)
- Stream real-time transactions on Base (Chainstack docs)
