Base now aims for five blocks a second. What does the Denim upgrade break for apps?
Base's Denim upgrade was set to switch mainnet from one block every 2 seconds to one every 200 milliseconds on November 5. Anything that counts blocks to measure time now runs 10 times faster.
Key points
- Base scheduled its Denim upgrade for mainnet at 1 p.m. ET (18:00 UTC) on November 5, 2026, after a testnet launch on October 21.
- Denim moves Base from one block every two seconds to five full blocks per second, each 200 milliseconds after the last, and replaces Flashblocks.
- On November 6, the BaseScan explorer showed 25 straight mainnet blocks inside about five seconds, consistent with 200 ms blocks.
What changed
Base, the layer 2 network (a chain that runs on top of Ethereum), has changed how fast it makes blocks. Its Denim overview says the chain goes from making one block every two seconds to five full blocks every second.
Each of those 200-millisecond blocks is a full block. It has its own number, hash and receipts, and it goes through the normal unsafe, safe and finalized stages, Base's technical spec says.
Base's upgrades page set mainnet activation for November 5, 2026, at 1 p.m. ET (18:00 UTC). The Base Sepolia test network switched on October 21 at 2 p.m. ET. When we checked on November 6, the docs still listed mainnet as pending, so the block data below is our best check that the switch happened.
What the chain shows
On November 6, BaseScan's block list showed blocks 53,723,335 to 53,723,359, a run of 25 blocks, with timestamps inside about five seconds. At two seconds per block that run would have taken about 48 seconds. The explorer shows time only to the second, so this is an estimate, but it matches the 200 ms design.
Blocks per minute on Base
blocks
Source: Base docs, Denim overview.
Flashblocks are gone
Until now Base offered Flashblocks, quick partial previews of a block for apps that wanted faster confirmations. Denim replaces them. "Flashblocks streams stop when Denim activates," the spec says. Apps that used them must switch to normal block streams, such as the standard newHeads subscription.
What breaks for apps
The main risk is code that uses block numbers as a clock. With 10 times more blocks per second, a timelock, cooldown, vesting schedule, deadline or voting period set in blocks now ends 10 times sooner in real time. Per-block limits allow 10 times more per second.
Base's advice: where values can be changed, multiply block-count durations by 10 and divide per-block caps by 10. Code that cannot be changed needs a migration plan. Logic based on block.timestamp is not affected, and that value stays in whole seconds.
Two smaller changes come with it. A new BaseTime contract gives apps the millisecond part of each block's time, and RPC responses gain optional timestampMs fields. Price oracles in the Uniswap V3 style may hit an "OLD" error sooner on long lookbacks, because the same number of saved readings now covers less time.
LC Insight analysis
This section is our reading of the facts above, not a statement of fact.
- We think 200 ms blocks matter most for trading and payments apps, where users feel every extra second of waiting for a confirmation.
- The bigger short-term risk is not the chain but older contracts that count blocks. Teams that did not adjust may find timers ending early.
- Moving from Flashblocks to full blocks simplifies things for developers, who now get one kind of fast confirmation instead of two.
What's next
- Any reports from Base of apps hit by block-count timers
- Base status notices on stability after the switch
- Whether other layer 2 networks follow with sub-second blocks
Disclaimer. This article is based on public information and the sources listed below as of the update time shown. It is for information only and is not investment, legal or tax advice. Figures may change as companies and authorities publish new data.
