Base Cobalt Goes Live With Conditional Trades and Token Seizures

Base Conditional Trades Face a 60-Second Expiry Limit

The new validity transactions attach conditions to an ordinary signed transaction. Base checks whether all conditions match before considering it for inclusion, according to its transaction specification.

Those checks can concern an account balance, a contract’s stored data, a block number or a position within a Flashblock. A transaction can remain pending while a condition is false and become eligible after an earlier transaction changes the relevant state.

For example, an application could prepare a withdrawal that waits for a required balance. Base also identifies conditional swaps as a use case. The conditions decide when a transaction becomes eligible; they do not replace the application’s own execution checks.

The current lifecycle rules impose an important limit: every validity transaction needs a block-number upper bound within 60 seconds of submission. The equivalent number of blocks depends on the network’s block cadence.

That makes the feature different from an indefinitely resting exchange order. An application seeking a longer-lived trading instruction would need to manage its continued submission or replacement rather than assume one transaction can wait without expiry.

Matching conditions also do not reserve block space. A transaction that is never included pays no onchain execution fee; one included onchain pays the usual execution fee even if it fails during execution.

Base’s safety documentation says the conditions cannot simulate a transaction or evaluate arbitrary computed values. They read specified state, and developers still need critical checks in the application call.

The practical change is a way to coordinate short-lived actions with blockchain state. It is not a promise of a completed trade, a guaranteed price or automatic protection from every execution risk.

B20 Adds Scheduled Stock Splits and Opt-In Seizures

Cobalt builds on Base’s earlier Beryl and B20 rollout. Beryl brought an ERC-20-compatible token standard implemented inside node software; Cobalt extends its administration and policy features rather than introducing B20 for the first time.

The multiplier update lets an authorized operator schedule a future adjustment for corporate actions such as stock splits or reinvested dividends. The new naming conforms to ERC-8056, which standardizes scaled amounts displayed to users.

Only one pending multiplier update can be active at a time. It can be canceled, while the earlier immediate adjustment remains available as an administrative failsafe. Existing Beryl functions remain callable, giving integrated applications a migration path.

For holders, a changed displayed balance should therefore be interpreted alongside the issuer’s corporate-action terms. It does not independently show new investment or investment returns, a distinction also relevant to tokenized-stock transfer volume.

The separate seizure function reassigns a balance from one address to another. It replaces the need to destroy a blocked balance as the preferred administrative removal path, although the old function remains callable.

This function applies to B20 Asset and Stablecoin tokens and is opt-in per token. With the exemption policy unconfigured, every seizure attempt fails. An issuer must configure that policy, and the caller must hold the designated role while the seizure function is unpaused.

A successful seizure transfers the balance without changing total supply. Burning the tokens requires a separate action. The upgrade consequently does not establish a network-wide power to seize arbitrary wallet assets.

Cobalt’s composite policies can combine two to four existing allowlists or blocklists. Issuers can require either one condition or several conditions together, using the live source lists instead of maintaining copied membership data.

That can simplify authorization administration. It also means a holder’s ability to move an affected token depends on the issuer’s configured rules, not merely on whether the blockchain is available.

Base Node Upgrades Remain in Metrics-Only Mode

Base’s v1.4.2 release told mainnet operators to upgrade by September 30 at 18:00 UTC. That operational requirement accompanied activation of Cobalt support in the execution and consensus clients.

The release also introduces a dynamic-upgrade mechanism that reads scheduled activation times from an Ethereum smart contract. Its intended benefit is fewer client releases tied solely to hard-coded dates and less coordination around future forks.

Base says this mechanism remains in metrics-only mode on mainnet while it collects validation data. The announcement therefore does not establish that all future upgrades can activate without operators restarting or updating software.

The Cobalt overview also describes moving registration of new trusted execution environment signers to onchain verification of AWS Nitro attestations. Base says the change removes reliance on the external proving service used by the previous registration flow; enclave key generation and proof verification are unchanged.

These infrastructure changes support the applications built above them. They do not quantify additional trading activity, newly issued assets or savings for users.

Alternative.me’s Bitcoin sentiment index stood at 74, in its Greed category, on October 1. It measures wider market sentiment and supplies no direct evidence of demand for Cobalt’s features.

As of October 1 at 13:08 UTC, the cited release and specifications did not disclose feature-specific transaction volumes or a timetable for moving dynamic upgrades beyond metrics-only mode. The next meaningful evidence will be disclosed application integrations, actual use of the new transaction route and a confirmed change to that mainnet operating mode.