Base deploys Cobalt upgrade with validity transactions

Base has deployed its third mainnet upgrade, Cobalt, adding conditional transactions that can execute only when user-defined requirements are met. The feature gives traders a way to submit onchain swaps tied to a price threshold and expiry block, creating a protocol-level alternative to strategies that have often required externally operated monitoring tools.

Called “Validity Transactions,” the mechanism allows a transaction to remain ineligible for inclusion until its stated conditions are satisfied. Base said users can set both the conditions and the time window governing execution, while keeping a submitted transaction private until it is included onchain.

A trader, for example, could submit a swap that becomes valid only when the price in a liquidity pool reaches a chosen USDC level before a specified block. If the pool never meets that threshold before the deadline, the transaction would not be included. The design resembles a conditional or limit-order instruction, though execution would depend on the transaction’s stated rules and the relevant pool reaching the target price during its validity window.

Conditional execution moves into the transaction layer

The Cobalt upgrade puts transaction logic closer to Base’s protocol rather than leaving users to rely entirely on bots or applications that monitor market conditions offchain. That could simplify certain automated trading and treasury-management workflows, particularly for users who want execution parameters encoded into the transaction itself.

Privacy is another component of the design. Base said Validity Transactions can remain private until execution, potentially reducing the visibility of pending conditional orders before they become eligible for block inclusion. Public mempools have long exposed pending transaction details to searchers and other market participants, especially around large swaps and arbitrage opportunities.

The feature does not guarantee a specific trade outcome or price. A transaction must still be included during the eligible period, and the final execution conditions can be affected by liquidity, price movement and network activity. Its primary function is to establish whether a transaction is valid for inclusion, based on conditions selected in advance.

Cobalt arrives as Base expands its tools for token issuers as well as onchain traders. The Coinbase-incubated Ethereum Layer 2 introduced its B20 token standard through the Beryl upgrade in June, and the latest release adds policy controls, scheduled balance-display adjustments and administrative recovery functions.

B20 gains reusable compliance rules

One of the larger B20 additions is “Composite Policies,” which allows token issuers to combine allowlists and blocklists through AND and OR logic. The feature is designed for assets whose transfer rules depend on more than one eligibility requirement.

A fund issuing tokenized shares, for instance, could require a recipient to appear on both a know-your-customer allowlist and a separate accreditation list. Under an AND rule, a transfer would fail if the recipient were removed from either list.

Base said the system can reuse existing live policies, including KYC allowlists and sanctions blocklists, without requiring issuers to replicate their membership data or continuously synchronize lists through offchain infrastructure. That approach could reduce operational complexity for issuers that use several overlapping compliance frameworks.

The feature also gives issuers more precise ways to define who can receive an asset. An OR rule could allow transfers to holders meeting either of two approved criteria, while an AND rule imposes cumulative checks. Such controls are particularly relevant for permissioned stablecoins, tokenized funds and other assets where transferability may be restricted by jurisdiction, holder status or internal policy.

Scheduled multipliers and seizure controls

Cobalt also introduces “Schedule Multiplier Updates,” aligning the B20 Asset multiplier with ERC-8056. The function allows issuers to schedule changes to the way an asset balance is displayed, including adjustments comparable to stock splits.

A stock-split-style adjustment changes the displayed number of units held without necessarily changing the holder’s proportional economic claim. For token issuers, the feature could support planned denomination changes without requiring holders to move assets or replace contracts.

Existing integrations built for the earlier Beryl release are expected to continue working, according to Base. New integrations can move to the updated standard over time, reducing the chance that the upgrade forces an immediate rebuild for applications already using B20.

The upgrade also adds a seizeWithMemo function for B20 assets and stablecoins where seizure has been enabled. The tool permits an authorized administrator to reassign a holder’s balance and record the source address, destination, amount and an accompanying memo onchain.

Base’s example involves moving shares from a frozen account to a recovery wallet. Such controls may provide issuers with a route to respond to compromised accounts, court-directed actions or other recovery events. They also place substantial authority in the hands of the party granted seizure permissions, making the governance and disclosure rules around a given asset central to how holders assess its risk.

Faster blocks and native smart accounts on roadmap

Base’s roadmap for the coming months includes a plan to reduce block times from two seconds to 200 milliseconds. A tenfold reduction in block intervals could make onchain interactions feel more responsive, though Base has not presented the timeline in the upgrade details as an immediate Cobalt change.

The network also plans to make smart accounts native at the protocol level. The proposed features include gas sponsorship, which would allow an application or another party to cover transaction fees, and transaction batching, which can combine several actions into one user operation.

Base additionally listed support for a subset of Ethereum Virtual Machine changes associated with Ethereum’s planned Glamsterdam upgrade. Together with Cobalt’s conditional transactions, the roadmap points toward a chain designed to handle more automated, policy-aware and application-managed activity without pushing every operational task into external services.