Base Activates B20, the Token Standard Its June Outage Delayed

Base switched on B20, its native token standard, at 18:00 UTC on July 8, two weeks after the network's Beryl hardfork shipped without it. The standard is built into the node software itself, not deployed as a smart contract. Who may mint a token, how finely it divides, what supply cap applies: all of that is enforced by the clients that run the chain, not by bytecode an issuer publishes on-chain. The registry that switches B20 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.

Precompiles in the client, not contracts on the chain

An ERC-20 token today is a contract each issuer deploys, typically copied from a shared library, and every transfer runs that contract's code inside the Ethereum Virtual Machine. B20 puts the same behavior in the node. It is implemented as Rust precompiles compiled into the client software, so the transfer, mint and permission logic executes natively on the chain instead of being interpreted from a deployed contract. The interface stays ERC-20 compatible, and wallets, explorers and exchanges see what they already handle. Role-based access control, transfer policies and supply caps ship as native features, not 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; changing a standard that lives inside the client takes 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.

An asset type and a six-decimal stablecoin

B20 defines two token types. The Asset type supports 6 to 18 decimals; decimals are the number of fractional units a token divides into, and the reason a balance can be written to eight or eighteen places. The Stablecoin type is fixed at 6 decimals, the shape USDC and USDT already use, and that 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 instead of writing and auditing the logic that enforces them.

Two halts in June took B20 out of the fork

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 ran 116 minutes by Base's own account; the second began at 15:33 UTC on June 26 and lasted 20 minutes. Third-party trackers recorded roughly one hour 48 minutes and about 38 minutes for the same two halts, and the figures do not reconcile. Both traced to one consensus fault at block height 47,806,542, which Base's postmortem pinned on a bug in sequencer block-building logic that let stale journal state 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," and Beryl shipped 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.

Live, with nothing issued yet

Activation and adoption are separate events, and on July 8 only the first had happened. B20 had nothing minted under either type. Cheaper issuance, uniform permissions, no per-issuer contract to audit: each of those claims still had to meet 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.