0x019527710195…01952774
Base's Cobalt upgrade adds configurable balance seizure to B20 tokens
Base will activate its Cobalt upgrade on mainnet at 18:00 UTC on September 30, adding a seizeWithMemo function to B20 tokens that lets issuers reassign holder balances while preserving total supply.

Outputs
Cobalt mainnet activation scheduled for September 30 at 18:00 UTC
Sepolia has carried Cobalt since September 23
Maintenance window runs from 18:00 to 20:00 UTC
v1.4.2 client release requires node operators to upgrade by September 30 at 18:00 UTC
The new seizeWithMemo function preserves total supply and bypasses ordinary transfer policies and holder allowances
Base's Cobalt upgrade will activate on mainnet at 18:00 UTC on September 30, adding a configurable administrative seizure function to the chain's B20 token standard and separating that authority from ordinary transfer restrictions.
Per Base's upgrade documentation, the change introduces an operation called seizeWithMemo that moves a specified amount from one holder to another address while preserving total supply. The function bypasses ordinary transfer policies and holder allowances, giving issuers an enforcement channel distinct from the existing transfer-restriction framework.
B20 is Base's native ERC-20-compatible token standard, available in Asset and Stablecoin variants. It already lets administrators configure roles and policies governing balance movements. Cobalt sharpens that boundary: role assignments identify who can exercise a particular power, while policy settings determine which accounts an operation can affect.
What does the upgrade change?
The new function requires a sequence of checks before it can move tokens:
- The caller holds
SEIZE_ROLE - The seizure function is not paused
- The destination is on the permitted recipient list
- The target holder is not exempt under
SEIZE_EXEMPT_POLICY - The source account holds a sufficient balance
Leaving SEIZE_EXEMPT_POLICY unset exempts every account, the changelog states. A separate recipient policy determines where seized tokens may land, and leaving it unset allows any otherwise valid destination. A holder's ability to make an ordinary transfer is independent of either seizure policy.
Issuers must configure which accounts lose their exemption before the function can take their tokens. Configuring eligibility alone is insufficient; execution requires SEIZE_ROLE, an unpaused function, a permitted recipient and sufficient balance, according to the upgrade overview.
How does seizure differ from burning?
B20 already includes a burnBlocked function that lets an authorized caller destroy tokens held by accounts denied by the transfer-sender policy. Cobalt marks burnBlocked deprecated but keeps it callable at its existing behavior, the Base documentation says.
The two paths diverge in their effects on supply, per the Cobalt changelog:
seizeWithMemo: reassigns tokens to a designated address and leaves total supply intactburnBlocked: destroys tokens held by blocked accounts and reduces supply
Seizure and burning carry separate administrative roles and independent pause controls. An issuer that reassigns tokens must perform a subsequent burn if it wants the destroyed supply taken out of circulation.
What does the rollout cover?
Sepolia has carried Cobalt since September 23. The v1.4.2 client release adds Cobalt mainnet support and instructs node operators to upgrade by September 30 at 18:00 UTC. Base's status page lists maintenance from 18:00 to 20:00 UTC for the mainnet cutover.
The change gives stablecoin issuers and asset tokenizers a separate administrative lever for sanctioned addresses, lost keys and compliance escalations, decoupled from the transfer rules governing ordinary commerce. Each issuer decides which controls to activate, and on which contracts.
Cobalt's mainnet activation at 18:00 UTC on September 30 will mark the first time the B20 seizure function becomes available to issuers on the production network. Issuers that rely on the deprecated burnBlocked path will need to migrate or accept the longer reassignment workflow.
via docs.base.org (Original)