Base Cobalt Upgrade Adds Conditional Transactions and B20 Controls

Base activated its Cobalt upgrade on mainnet on September 30, 2026, adding conditional transactions, new controls for B20 tokenized assets, groundwork for dynamic upgrades and a new onchain process for registering trusted-execution-environment signers. The network status page marked the scheduled maintenance complete at 20:00 UTC. Readers can follow related infrastructure updates through OrangeX.com News.

Node operators were required to move to software version 1.4.2 or later before the activation. The release replaced version 1.4.1 and included Cobalt support in both the execution node and consensus software.

Conditional transactions move execution rules closer to the protocol

Cobalt introduces validity transactions: signed transactions that become eligible for inclusion only when specified onchain conditions match. The available predicates can examine balances, storage values, block numbers and Flashblock indexes.

That design can support a swap that should execute only after a pool reaches a defined state, or a withdrawal that becomes valid within a particular block window. If the conditions are not satisfied, the transaction is not eligible for inclusion. The feature reduces the need for a separate keeper or custom settlement contract in some workflows, but it does not guarantee execution. Liquidity, gas settings, competing transactions and the deadline can still determine whether an eligible transaction lands.

B20 gains policy composition and corporate-action tools

B20 is Base's native, ERC-20-compatible token standard for fungible assets, including stablecoins and tokenized real-world assets. Cobalt adds scheduled user-interface multiplier updates, a transfer-reassignment function with an onchain memo, and Union and Intersect policy types.

Scheduled multiplier updates are designed for events such as stock splits. They let an issuer change how balances and supply are displayed at a future time without changing the underlying raw units. Composite policies allow an asset to reuse existing rules with OR or AND logic. An issuer could, for example, require a recipient to satisfy both an identity list and an investor-eligibility list.

The reassignment function applies only to assets where the relevant authority and policy have been configured. It lets an authorized administrator move a blocked balance and record the source, destination, amount and memo onchain. That can support recovery or legal-hold procedures, but it also makes issuer governance, role security and disclosure central risks. Broader market context is available on OrangeX.com Markets.

Dynamic upgrades begin in monitoring mode

Cobalt also introduces an Ethereum contract that stores upgrade timestamps for Base nodes. The longer-term goal is for nodes to query the contract and apply network changes without relying solely on timestamps compiled into a new software binary.

The mechanism is running in metrics-only mode on mainnet while the network collects data. Cobalt itself still required operators to install the supporting release before activation. The distinction matters: the upgrade registry is groundwork for a different deployment process, not evidence that future hard forks are already automatic.

TEE signer registration moves verification onchain

The upgrade changes how new trusted-execution-environment signers register. AWS Nitro attestations are now verified onchain using checked P-384 hints, replacing the previous flow that depended on an external proving service. Base says the change makes registration faster while leaving enclave key generation, PCR0 image selection and proof verification unchanged.

This is an infrastructure change rather than a blanket guarantee about every application. Users and developers still need to evaluate the trust assumptions, upgrade authority and failure modes of the services they use. Background explanations of token standards and smart-contract controls are available through OrangeX.com Academy.

What developers and issuers should check

Node operators should confirm that they run version 1.4.2 or later and remove deprecated configuration flags when upgrading from older releases. Application developers should test condition predicates, expiration behavior and failure handling before using validity transactions in production.

B20 issuers and integrators should review role assignments, policy composition and multiplier schedules. Wallets and accounting systems also need to distinguish raw balances from display-adjusted amounts. Existing Beryl integrations are intended to remain compatible, but new functions require explicit integration and testing.

OrangeX.com Analysis

Cobalt's significance comes from moving more transaction and asset-management logic into standard network components. Conditional execution can simplify state-dependent trading flows, while policy composition and scheduled balance-display changes make tokenized assets easier to administer with consistent interfaces.

The tradeoff is that greater protocol support does not remove application or governance risk. A validity transaction can be correctly specified and still miss its opportunity if market conditions change. An issuer-controlled asset can meet compliance requirements while creating additional dependence on administrators and policy registries. Adoption should therefore be judged by audited integrations, transparent role design and reliable production use, rather than by the availability of features alone.