Base 200ms Blocks Make block.number Run 10x Faster For Contracts

Base 200ms blocks are easy to verify, because you can count them. Block numbers show the upgrade happening.

Look at block 53,556,126 on Base. On November 5 it was stamped 17:59:59 UTC. Block 53,556,127 comes next and is stamped 18:00:01. From there, five blocks fit into each second.

That is Denim, the Base upgrade that moved canonical block production from one block every two seconds to one every 200 milliseconds. A node query on November 7 agrees with that. A run of 1,000 blocks, from 54,328,535 to 54,329,535, covers only 200 seconds. The chain had reached block 54,329,535 by 12:58 UTC, roughly 773,000 blocks after the switch. At two seconds apiece that would have taken about 18 days.

Base 200ms blocks and the block.number problem

Base's Denim specification says the upgrade went live on Base Sepolia on October 21 and on mainnet on November 5 at 18:00 UTC. Flashblocks, the earlier system that streamed partial updates inside a single block, are retired. Each new block has its own hash, state root and receipts.

The header timestamp still counts whole seconds. Only block.number speeds up, and it now advances ten times faster in wall-clock terms. Any contract that treats a block count as a duration is therefore running on a clock that shrank to a tenth of its intended length.

Denim's guidance on contracts that count blocks. Source: Base documentation, Denim overview.

Base 200ms blocks: which contract patterns shrink

The documentation lists the affected patterns. A timelock written as the current block minus a start block, compared with N, now elapses in one tenth of the planned time. Vesting or emission schedules counted in blocks finish ten times sooner.

Rate limits that reset whenever the block number changes now reset five times a second instead of once every two seconds. Base's own wording is that this raises the effective per-second limit ten times. Deadlines stored as a block number plus N expire early as well.

Governance gets hit too. Any voting delay or voting period set in blocks shrinks by the same factor, ERC20Votes with its default block-number clock included. Stored checkpoints stay correct, according to the guidance, but the voting window does not.

Oracles mostly escape, though there is one catch. TWAPs in the Uniswap V3 style weigh by seconds, so their values hold. Each pool writes at most one observation per timestamp second. An active pool can now write one per second rather than one per two-second block. A fixed observation cardinality may then cover half as much history, and long lookbacks can fail sooner.

Fixes for Base 200ms blocks

Base tells teams to compare block.timestamp instead of block counts wherever they can redeploy. If a count can be tuned through governance, multiply durations like timelocks and voting periods by ten. Divide per-block caps by ten as well.

Immutable contracts are the hard case, since nobody can retune them. Here the guidance is to measure the damage and plan a migration. Testing is possible on Base Sepolia or on Vibenet, and both already produce 200ms blocks.

Node operators have their own requirement under Base 200ms blocks. Mainnet nodes need the base-reth-node and base-consensus binaries from base/base release v1.5.1 or later. Further releases kept coming, with v1.5.4 published on November 6.

Easy to miss, this one. The chain simply feels faster, and nothing visibly breaks. Base 200ms blocks reward teams that already compare timestamps. Trouble would show up in contracts whose logic quietly assumes a block is two seconds long.