Cobalt Upgrade Overview

Cobalt is the Base hardfork that follows Beryl. Its scope settled in mid-September 2026 after two rounds of reshuffling, and it now carries four things: a batch of B20 additions, conditional transactions that only become eligible when chain state matches, a first step toward lifting fork timestamps out of the node binary, and a move of Base infrastructure into a trusted execution environment.

Status

Network	Status	Target
Base Sepolia	Planning	September 2026
Base Mainnet	Planning	September 2026

Caution

September is a target under a planning status, not a booked activation. Cobalt has no activation timestamp on Mainnet or Sepolia, and the node source matches that: cobalt_timestamp is unset on every canonical network. The fork’s contents have also moved more than once. Treat both the date and the scope as provisional until timestamps appear.

What Cobalt ships

• B20 improvements — fees payable in B20, scheduled multiplier updates, a first-class seize operation that supersedes burnBlocked, and two new composite policy types. The call-level detail is in the B20 precompile reference.
• Validity transactions — a signed transaction paired with conditions on chain state, which Base holds back until every condition matches. See Validity Transactions.
• Dynamic upgrades — an L1 contract holds the fork schedule, so activation no longer depends on shipping a binary with the timestamps compiled in.
• TEE migration — Base infrastructure moves inside a trusted execution environment. Upstream has not published the specification yet.

What moved out of Cobalt

Two features carried the Cobalt label at some point and no longer do. Material written earlier says otherwise, so it is worth stating plainly:

Feature	Now shipped by	Status
Canonical 200ms blocks, BaseTime, millisecond RPC timestamps	Denim	Planning, targeting October 2026
Native account abstraction (EIP-8130)	No scheduled fork	Gated behind zenith, which is unset everywhere

The 200ms work was briefly filed under Cobalt in early September 2026 and has since moved back to Denim. The node source never followed it across: block-timing paths have gated on is_denim_active_at_timestamp throughout, so the reassignment restores agreement between the docs and the implementation.

Account abstraction is the murkier of the two. It has no fork of its own now. Its runtime gate is zenith, which sits off the execution fork ladder and is hardcoded to None for every canonical network, with a source comment stating the gate exists for genesis-level testing and must not reach a canonical schedule. Devnets opt in through their own genesis config. The model itself is documented in Native Account Abstraction; what is missing is a date and a fork to carry it.

Required software

Node requirements get published once Cobalt has real activation timestamps, so there is nothing for operators to install ahead of time. To follow the work as it lands, point a client at vibenet instead.

B20 improvements

Cobalt widens the B20 surface rather than changing it. Every Beryl selector, event topic, and error keeps its 4-byte identity, so existing integrations keep compiling and keep working.

The additions worth knowing about: transaction fees payable in a B20 token, multiplier updates that can be scheduled ahead of time instead of landing instantly, a seizeWithMemo call that reassigns a holder’s balance in one admin step, and Union and Intersect policy types that compose existing policies.

Caution

One Cobalt rename does break an ABI. The policy scope consulted by seizeWithMemo was SEIZE_HOLDER_POLICY (0xb279d311) and is now SEIZE_EXEMPT_POLICY (0xfeb346ec). The selector and the keccak256 scope constant both change with it. Code that hardcodes either value needs updating. The behaviour is unchanged: an account authorized by this scope is exempt from seizure, and a token whose issuer never configures the slot has no seize capability at all.

Validity transactions

A validity transaction is an ordinary signed transaction submitted alongside a list of predicates over chain state. Base holds it out of the block until every predicate matches, then lets it compete for inclusion on normal fee rules. This makes conditional swaps, conditional withdrawals, and similar state-dependent actions expressible without a keeper watching the chain and racing to submit.

The predicates read balances, raw storage slots, block numbers, and Flashblock positions. They are submitted out of band and never appear onchain. The Validity Transactions reference covers the request format, the predicate types, and the safety rules that go with reading storage directly.

Dynamic upgrades

Every fork so far has needed a fresh node release carrying the activation timestamps in its source. That couples two things that do not have to be coupled: agreeing on when a fork happens, and shipping the code that implements it. An operator who misses the release risks dropping out of consensus for no reason other than a version number.

Cobalt separates them. An Ethereum contract stores the upgrade schedule, and both the execution and consensus clients run a poller that reads it over an L1 RPC endpoint, writes the result into the client’s activation overrides, and applies it everywhere the schedule is consulted. A fork can then activate at its scheduled moment with no restart.

Note

At Cobalt this runs in metrics-only mode on Mainnet while Base gathers evidence that the mechanism behaves. It arrives inside the Cobalt node release, so operators have nothing to configure.