Mentioned in This Article
1. Base Denim upgrade goes live on mainnet
Base, the Ethereum layer-2 network built by Coinbase, activated its Denim upgrade at 18:00 UTC (1 p.m. ET) on Thursday, November 5, cutting the time between blocks from two seconds to 200 milliseconds. The change means the network now produces ten blocks in the span that previously held one, so any logic that counts blocks instead of minutes now elapses ten times sooner. Base's team described the upgrade as live on mainnet about two hours after the switch.
Public RPC data shows the first 200-millisecond block, number 53,556,127, arriving at 18:00:01 UTC, two seconds after the final block of the older cadence. The activation followed the schedule Base had published on its status page in advance, so the timing itself did not come as a surprise. What drew attention afterwards was the list of knock-on effects for developers, node operators and at least one dependent chain.
Base is a layer-2 network, meaning it processes transactions off the main Ethereum chain and posts the results back to it. Block time is one of the most visible parameters of such a network, because it sets how quickly a user's transaction can be included and how often applications see a fresh view of the chain state. Shrinking it by a factor of ten is a large step, and the upgrade's documentation treats it as a change that application developers must plan around rather than simply enjoy.
2. Why do timers measured in blocks now expire faster?
Any smart contract that treats a fixed number of blocks as a length of time now measures a duration one-tenth as long as before. A timelock of 302,400 blocks, which equals one week when blocks arrive every two seconds, would now expire in roughly 16.8 hours. The arithmetic is straightforward, but the consequences can be significant for contracts written years ago under the assumption that block time would stay constant.
Base's specification for the upgrade warns developers about exactly this pattern. It says that code treating a block count as a duration will see that duration shrink to a tenth of its former length. Governance voting periods, token vesting schedules, withdrawal cooldowns and expiry deadlines all fall into the category of logic that should be audited. A voting window that once lasted several days could close within hours, and a vesting cliff could arrive far earlier than its designers intended.
Contracts that read time through the block timestamp are unaffected, because the timestamp continues to track wall-clock seconds. The difficult cases are contracts whose block counts are hard-coded and cannot be upgraded. Those cannot be repaired after the fact, so their owners must work around the new cadence by other means, for example by pausing the affected function or migrating users to a replacement contract where that is possible.
3. What happens to Flashblocks?
Flashblocks, the mechanism Base used from July 2025 until this week, is replaced by the new design. Developed with Flashbots, it released partial results every 200 milliseconds while each two-second block was still filling, and applications could treat those fragments as preconfirmations of the transactions they contained. The fragments were not themselves blocks, and they had no place in the standard progression of block states.
Under Denim, each 200-millisecond slice is a complete, numbered block that moves through the usual stages of unsafe, safe and finalized. That makes the fast confirmations part of the ordinary chain rather than a layer on top of it. Base's overview says that applications relying on Flashblocks must migrate to the canonical block and RPC streams, since the earlier preconfirmation feed is no longer the way to get fast data.
Base published a migration guide that maps the old subscriptions to their standard equivalents. One notable gap is that the pending tag, which developers used to query the most recent in-progress state, has no direct counterpart after Denim. Teams that depended on it will need to rework how their applications read the latest state.
4. Oracles, timestamps and the new BaseTime contract
Price oracles built in the style of Uniswap V3 continue to report correct values, according to the specification, but there is a subtlety in how much history they cover. These oracles store a fixed number of observations, and when blocks come ten times as often, that fixed number can span as little as half the wall-clock history it did before. A protocol that relied on a long averaging window for manipulation resistance may find that the window has become shorter than intended.
Because the block timestamp still counts whole seconds, several consecutive 200-millisecond blocks will share the same timestamp value. To give contracts finer resolution, Base added a contract called BaseTime that lets other contracts read millisecond-level timing. RPC responses also gain optional timestamp fields expressed in milliseconds, so off-chain software can distinguish blocks that would otherwise look simultaneous.
These additions show that the upgrade changed more than a single number. Faster blocks alter the assumptions behind oracles, auctions, games and any application that sorts events by time, and the tooling around them has to expose the extra precision for developers to use it safely.
5. Who must update their software?
Operators of Base nodes are required to run version 1.5.1 or later of the base/base client. Base released version 1.5.1 on October 22 as the minimum release that supports Denim. A later release, version 1.5.3, fixed a separate bug related to the state root, which is the cryptographic summary of the chain's state that nodes must compute identically.
Anyone running an older version after activation would be unable to follow the chain correctly, which is why the required release was published about two weeks ahead of the switch. For application teams the work is different: they must review any logic that assumes the old block cadence and move off the retired preconfirmation feed. The two groups face separate deadlines, but both were told to prepare before the activation date.
6. Early inclusion delays leave many blocks empty
The activation was not entirely smooth. Fourteen minutes after the switch, Base's status page said that Denim had activated successfully, and it added that the team was investigating periodic delays in transaction inclusion that had produced more empty blocks than expected. As of 7:30 p.m. ET, roughly two and a half hours after activation, the page carried no further update.
An analysis of public data found that 146 of the first 300 blocks after activation contained only system transactions, meaning nearly half of them carried no user activity. Hourly samples of 300 blocks taken from 4 p.m. to 7 p.m. ET reportedly showed no such problem, which suggests the issue was concentrated in the opening period. The wording of that finding leaves some ambiguity about whether the later samples were fully clean, and Base has not yet published a cause.
Empty blocks do not by themselves mean funds were at risk. They indicate that user transactions waited longer than they should have to be included. For a network that is promoting speed as the point of the upgrade, however, an early stretch of sluggish inclusion is the kind of issue operators will want to resolve and explain quickly.
7. Horizen's layer 3 cannot follow the change
Horizen, a layer-3 network built on the OP Stack that settles its transactions to Base, said in October that its chain could not follow Denim. Its infrastructure provider reportedly said that no fix was available. Horizen warned that, as a result, its layer 3 would permanently stop including user transactions about 40 minutes after the activation.
Users were given until 13:00 UTC on November 4 to move their assets to Base before the cutoff. The Horizen DAO plans to send remaining ZEN and ETH balances to holders on Base. The episode illustrates that a base-layer change of this size can strand networks that sit on top of it when their own infrastructure cannot be adapted in time.
8. Where Denim sits among Base's 2026 upgrades
Denim is the fourth named upgrade of the year on Base's upgrades page. Azul arrived in May, Beryl in June and Cobalt in September. The next entry on the list, Everest, has no date attached, so the network has not said when its following change will land.
The steady cadence of named releases shows Base treating its protocol as software that ships on a regular schedule, with each release carrying its own requirements for node operators and developers. Denim stands out because it changes a basic unit of the chain, the block, instead of adding a feature around it.
9. What to watch next
The immediate question is whether Base publishes an explanation for the empty blocks and confirms that inclusion has returned to normal. Developers should also expect a period of audits as teams search their contracts for block-count assumptions, and the first reports of affected vesting or governance logic may surface in the coming days.
Users of the network will mostly notice the change as quicker feedback after sending a transaction, while builders face the heavier task of confirming that nothing in their code silently depended on the old two-second rhythm. Auditors typically search for constants such as block-denominated delays, then convert them to timestamp-based values wherever the contract can be upgraded, which is why the specification singles out immutable deployments as the hardest group to fix.
Further out, the next named upgrade, Everest, remains undated. Until a date is announced, the practical work for the ecosystem is migrating applications from the retired preconfirmation feed and confirming that timers across the network still behave as their authors intended at 200 milliseconds per block.