Base’s Cobalt upgrade is scheduled for mainnet on September 30 after going live on the Sepolia test network a week earlier. Its most practical addition is a new transaction type that lets a sender define onchain conditions for eligibility. That sounds like automated execution, but the distinction between eligibility and guaranteed inclusion matters.
Under Base’s documentation, a validity transaction combines a signed raw transaction with a non-empty list of conditions. The current interface can check balances, storage values, block numbers and Flashblock indexes. Every condition must match before the network considers the transaction eligible.
Conditions do not reserve block space
A condition can make a transaction eligible after an earlier state change. For example, an application could prepare a withdrawal that becomes eligible only after a specified balance or storage value appears. Base also lists conditional swaps and other state-dependent actions as possible uses.
Eligibility is not execution, however. The official specification says the mechanism does not reserve block space or guarantee inclusion. Fees still matter, and the documentation recommends EIP-1559 transactions even though legacy and EIP-2930 formats are supported. A sender can use block-number or Flashblock-index conditions to limit the period in which the transaction may be included.
The privacy boundary is equally specific. Conditions travel separately from the signed transaction and do not appear in the resulting onchain transaction. Base nevertheless warns users not to put secrets in transaction calldata or condition values. The feature changes when a transaction can be considered, not the public nature of data ultimately submitted to the chain.
Dynamic upgrades begin in observation mode
Cobalt also introduces machinery for nodes to read upgrade schedules from an Ethereum smart contract. Base says execution and consensus clients can poll that contract, store activation overrides and apply a scheduled fork without restarting. For Cobalt, though, the feature is being deployed on mainnet in metrics-only mode while the team gathers data. It should not be described as fully operational automated upgrading yet.
That phased rollout addresses a real coordination problem. Hard-coded activation times require node operators to install a new binary before each fork, and a missed release can leave a node outside consensus. Separating schedules from client releases could shorten that coordination window, but Cobalt’s observation period leaves room to test the mechanism before relying on it.
B20 and prover registration also change
The release expands Base’s B20 token controls with scheduled multiplier updates, simpler transfer blocking, and Union and Intersect policy types. It also moves registration of new trusted-execution-environment signers to onchain verification of AWS Nitro attestations using checked P-384 hints. Base says enclave key generation, image selection and proof verification are unchanged.
For developers, the important reading is narrower than “transactions execute automatically.” Cobalt provides a conditional eligibility layer, with ordinary fee competition and inclusion uncertainty still present. The node-upgrade component is also deliberately limited at launch. Those boundaries are central to evaluating the release without assigning capabilities that the documentation does not claim.
Adapted from Base Ships Cobalt Hard Fork With Validity Transactions and B20 Upgrades.