Base Denim goes live, but transfers still face inclusion delays

Base has activated Denim, its upgrade to 200-millisecond blocks, but the launch came with a warning for anyone sending money: transactions can still wait to enter those blocks. In its November 5 update at 18:14 UTC, Base confirmed activation while reporting periodic inclusion delays and more empty blocks than expected. That was 02:14 on November 6 in Hong Kong.

The practical distinction is between a network producing blocks and your transfer appearing in one. A fast cadence alone does not tell a merchant that a payment arrived or a borrower that additional collateral reached a lending contract.

What changed, and what the speed claim means

Base’s engineering announcement, dated November 5, says Denim replaces Flashblocks—previews of transactions in a block still being built—with complete canonical blocks every 200 milliseconds, down from two seconds. Canonical means part of the chain’s current accepted history. Inclusion still does not equal finality: Base says the batch must be posted to Ethereum and finalized there for the stronger settlement guarantee.

For wallet users, this can make an included transfer visible sooner. It does not guarantee that every submitted transfer enters the next block, that a receiving exchange credits deposits immediately, or that a bridge releases funds on the same schedule. Those are separate steps.

The older v1.5.1 release, published October 22, specified November 5 at 18:00 UTC for mainnet activation. The later status notice confirms that activation happened; it does not confirm that the reported delays have been resolved. All linked notices were checked on November 6.

A separate patch is not evidence of lost balances

Base also published a node-software advisory on November 5, updated at 17:52 UTC. It describes a Reth bug that could produce an incorrect state root, the cryptographic summary of account and contract state. Base says it checked the actual chain state, found it correct, and that users were not affected. It patched its block builders and recommended that node operators install v1.5.3 without resynchronizing.

That is Base’s reported finding, not an independent balance audit by Boxmining. The advisory does not establish that this bug caused Denim’s inclusion delays. Treating the two notices as one incident would imply a cause the sources do not demonstrate.

Holder impact: check the transfer before repeating it

For someone paying from a wallet, the immediate risk is making a second payment because the first looks slow. Check the original transaction hash in a Base explorer, its receipt status and the destination address before sending again. A submitted hash is a tracking reference, not proof of success. If it remains pending, use the wallet’s supported transaction-management flow rather than creating an unrelated second transfer.

For a borrower moving collateral, count the top-up only when the lending app records it. Until then, the position may remain exposed to its existing liquidation rules. This is a practical consequence of delayed inclusion, not evidence that liquidations increased during this upgrade.

For a merchant or exchange customer, distinguish successful onchain execution from the recipient’s crediting policy. A receipt cannot promise when a platform makes funds spendable.

Denim’s faster cadence creates opportunities for quicker app updates; it does not by itself raise staking returns or establish a fall in transaction fees. This report makes no claim of an observed price, yield or fee change. The useful check today is whether the specific transaction completed and whether Base has posted a resolution to the inclusion-delay notice.