Skip to content
BaseHub by Will Binns Updated

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 is now live on both public networks: Sepolia since September 23, 2026 and Mainnet since September 30, 2026. It 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 new way to register TEE prover signers that verifies the Nitro attestation directly onchain.

NetworkStatusDate
Base SepoliaLiveSeptember 23, 2026
Base MainnetLiveSeptember 30, 2026

Upstream moved Cobalt off planning status on 2026-09-15 and named both dates. Both are now pinned in the node source rather than merely announced, and the status page has published scheduled-event notices for both networks. Sepolia activated on September 23 and the maintenance window closed cleanly at 20:00 UTC, so the scope on this page is no longer expected to move.

Mainnet followed one week later. Its window opened at 18:00 UTC on September 30 and the status page marked it complete at 20:00 UTC, again with no incident filed. Upstream switched both the fork page and the upgrades tracker to Live the same evening. A check against Mainnet on 2026-10-01 agrees: at a block from before 1790791200, a B20 Asset token reverted calls to the Cobalt-only uiMultiplier and SEIZE_EXEMPT_POLICY getters, and at the current head both return values.

Both networks now have an exact activation moment compiled into the node. cobalt_timestamp for chain 84532 is 1790186400, which is September 23, 2026 at 18:00 UTC. Chain 8453 is 1790791200, which is September 30, 2026 at 18:00 UTC. The two sit exactly seven days apart, and the Mainnet value landed on 2026-09-21, six days after the dates were first announced.

This corrects guidance this page carried until 2026-09-16. Cobalt does ship the onchain upgrade registry, but that mechanism runs in metrics-only mode at this fork and does not replace the compiled-in schedule yet. Both networks still take their Cobalt activation from the timestamp built into the client, so a node release remains the thing to watch.

  • B20 improvements — 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, groundwork for activation that does not depend on shipping a binary with the timestamps compiled in. Cobalt itself still activates from the compiled-in schedule; the registry runs alongside it in metrics-only mode.
  • TEE registration migration — new TEE prover signers are now admitted by checking their AWS Nitro attestation fully onchain, with checked P-384 hints doing the heavy curve math. This retires the RISC Zero proof and the Boundless marketplace from registration, so the registrar no longer relies on an outside proving service and signers register faster. Enclave key generation, PCR0 image selection, and proof verification stay as they were. Upstream relabelled this item on 2026-09-25; earlier wording described a move of all Base infrastructure into a TEE, which overstated it. See the TEE Prover Registrar and the nitro-validator redesign.

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

FeatureNow shipped byStatus
Canonical 200ms blocks, BaseTime, millisecond RPC timestampsDenimPlanning: Sepolia October 2026, Mainnet November 2026
Native account abstraction (EIP-8130)No scheduled forkGated 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.

Sepolia now has a named minimum: v1.4.0 of github.com/base/base, or anything later. Upstream published that requirement alongside the scheduled-event notice on 2026-09-16, and the tag went out the same evening. It is the first build whose compiled-in schedule contains the Sepolia activation, so it is the floor rather than a recommendation — an older node does not recognise the fork at all.

Mainnet has a published floor too: v1.4.2, named in the status-page notice of 2026-09-23 and released the same evening. v1.4.0 does not qualify. It was tagged before chain 8453 received 1790791200, so it ships Mainnet cobalt_timestamp: None and will not follow the fork on September 30.

v1.4.1 is the trap. It went final on 2026-09-23, and its compiled schedule already contains the Mainnet timestamp (the value first appears at v1.4.1-rc.9). So a v1.4.1 node does activate Cobalt on time. It is still below the floor. v1.4.2 is v1.4.1 plus three commits, and the one that matters is a backport (#5260) of two validity RPC changes:

  • the node registers validity transaction ingress before Cobalt and turns it on from the live upgrade schedule, while keeping the experimental override
  • a regular RPC node proxies validity submissions to the sequencer through SequencerClient, keeping predicates, sequencer headers, and upstream rejection behavior intact

Put simply, v1.4.1 follows the fork, but its validity RPC is not tied to the live schedule and does not forward submissions to the sequencer. If your node takes public RPC traffic and still runs v1.4.1, callers of base_sendRawTransactionValidity hit that gap today.

One packaging note worth repeating, because the September 23 window is the first fork where it bites: the public node images and binaries now come from github.com/base/base. The retired base/node repository stopped receiving them at v1.3.0, so there is no v1.4.0 or v1.4.2 on the old path to pull. Vibenet still carries the Cobalt surface too, and upstream keeps its interactive validity transaction demos there.

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: 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. Paying transaction fees in a B20 token was on Cobalt’s list until 2026-09-29, when upstream took it off the fork page; the node source has no fee-token path either, so it remains a roadmap item rather than a Cobalt feature.

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 account balances, raw storage slots, block numbers, and Flashblock positions. Upstream pulled the balance predicate on 2026-10-01 and restored it on 2026-10-06, and no release ever rejected it. 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.

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.