Base Activates B20, the Token Standard Its June Outage Delayed

Base activated B20, its native token standard, on mainnet at 18:00 UTC on July 8, two weeks after the network's Beryl hardfork shipped without it. B20 is a standard built into the node software itself rather than deployed as a smart contract, so the rules that govern a token — who may mint it, how finely it divides, what supply cap applies — are enforced by the clients that run the chain instead of by bytecode an issuer publishes on-chain. The registry that switches the standard on had been pulled out of Beryl in June, after two sequencer outages on consecutive days forced Base to hold it back. As of the July 8 activation, no tokens had been issued under B20.

The Design: Precompiles Inside the Client, Not Contracts on the Chain

An ERC-20 token today is a contract that each issuer deploys, typically copied from a shared library, and every transfer runs that contract's code inside the Ethereum Virtual Machine. B20 moves the same behavior into the node: it is implemented as Rust precompiles compiled into the client software, which means the transfer, mint and permission logic is executed natively by the chain rather than interpreted from a deployed contract. The standard stays ERC-20 compatible, so wallets, explorers and exchanges see the interface they already handle. Role-based access control, transfer policies and supply caps ship as native features rather than as library code an issuer has to include and get right. The trade-off runs the other way as well: a contract standard can be revised by deploying a new contract, while changing a standard that lives inside the client requires a new client release and a network upgrade. Other networks have shipped token standards of their own rather than leaving the shape of a token entirely to application developers.

The Two Types: An Asset Variant and a Six-Decimal Stablecoin

B20 defines two token types. The Asset type supports 6 to 18 decimals — decimals being the number of fractional units a token divides into, and the reason a balance can be expressed to eight or eighteen places. The Stablecoin type is fixed at 6 decimals, the shape USDC and USDT already use, which removes a configuration choice that has produced integration errors elsewhere. Both types inherit the native access control, transfer policies and supply caps, so an issuer configures parameters rather than writing and auditing the logic that enforces them.

The Delay: Two Halts in June Took B20 Out of Beryl

Base stopped producing blocks twice in two days in late June, and the fork's schedule went with it. The first halt began at 16:03 UTC on June 25 and lasted 116 minutes by Base's own account, the second at 15:33 UTC on June 26 for 20 minutes; third-party trackers put the two at roughly one hour 48 minutes and about 38 minutes, and the figures differ. Both traced to the same consensus fault at block height 47,806,542, which Base's postmortem attributed to a bug in sequencer block-building logic that allowed stale journal state to persist after a transaction validation failure, fixed in pull request #3806. Mainnet enablement of the B20 Activation Registry was postponed at the time "to ensure a smooth rollout," leaving Beryl to ship with its other content: a cut in Base withdrawal delays from seven days to five hours, and an upgrade to the Reth V2 Rust execution client.

What Is Unresolved: A Live Standard With Nothing Issued Under It

Activation and adoption are separate events, and on July 8 only the first had happened. Nothing had been minted under either B20 type, so the standard's claims — cheaper issuance, uniform permissions, no per-issuer contract to audit — remain untested against real supply. The stablecoin variant is the clearer target, since its fixed decimal shape is aimed squarely at the dollar tokens that already carry most of the transfer volume on the network. What the activation does settle is that the delayed half of Beryl is now on mainnet, two weeks behind the fork it was meant to arrive with.