What is B20? Base’s new native token standard explained

On June 25, 2026, Base mainnet activated its second network upgrade, Beryl, and shipped something no Ethereum L2 had shipped before: a token standard that lives inside the node, not inside a contract. It’s called B20, and it’s a full ERC-20 superset — existing wallets, indexers, exchanges, and integrations treat it as a normal token from day one. What changed is what sits underneath, and what a token issuer no longer has to write themselves.

If you build on Base and you’ve been rolling your own ERC-20 for every launch, B20 is the change that will actually affect your work. This article covers what B20 is, how it works, when to use it, and how to deploy one through a Chainstack Base node.

What is B20?

B20 is Base’s native token standard, introduced with the Beryl upgrade and live on Base mainnet since June 25, 2026 (and on Base Sepolia since June 18, 2026). It implements the full ERC-20 specification, so B20 tokens are interoperable with anything that already speaks ERC-20 — wallets, block explorers, DEXes, indexers, custody providers. The difference is where the token logic runs.

An ERC-20 is a smart contract you deploy on top of the chain. A B20 is a precompiled contract written in Rust that runs directly inside the Base node. You don’t deploy bytecode. You call a singleton factory precompile, pass a few parameters, and a token exists. Roles, transfer policies, supply caps, granular pausing, memos, and ERC-2612 permit are built into the standard — the compliance features that stablecoin and RWA issuers currently rebuild from scratch every time.

The short version: same interface as ERC-20, native performance, and a compliance toolkit that ships with the standard.

Why Base built its own token standard instead of using ERC-20

Base has been the busiest Ethereum L2 by daily transactions since 2024. That volume increasingly comes from three kinds of issuers: stablecoin operators, real-world asset (RWA) and equity tokenizers, and long-tail token creators launching everything from memecoins to gaming currencies.

All three kept building the same features into their contracts — allowlists, blocklists, freeze-and-seize, pausable transfers, role-gated minting. Each rebuild costs time, introduces audit risk, and drifts from the last. Regulated issuers were writing the same compliance primitives every time, sometimes subtly wrong.

Beryl’s answer was to move the primitives into the chain. The B20 spec puts roles, transfer policies, and supply controls behind a stable interface that Base and Spearbit audited once, so issuers don’t audit them again. And because B20 runs as a precompile rather than through the EVM, the node can do things a contract can’t — features Base has scheduled for the next upgrade (Cobalt, targeted for September 2026) include paying gas in your own B20 token and native RPC indexing without a third-party indexer.

B20 vs ERC-20: the parts that changed and the parts that didn’t

	ERC-20	B20
Implementation	Smart contract you write and deploy	Native precompile inside the node
Creation	Deploy your own bytecode	One createB20 call to the singleton factory
Compliance features	Build them yourself	Roles, transfer policies, freeze-and-seize, pause, supply cap, and memos all built in
Compatibility	—	Full ERC-20 selector parity: transfer, transferFrom, approve, balanceOf, allowance, standard events
Cost and throughput	Standard EVM execution	Cheaper and higher-throughput (Base has stated ~50% cheaper transfers and roughly 2× TPS as a Cobalt target)

The important line is the compatibility row. Because B20 exposes the full ERC-20 selector set, everything downstream — MetaMask, Etherscan, The Graph, Coinbase, DEX aggregators — sees a B20 token the same way it sees any ERC-20. You do not need to migrate integrations to accept a B20. You need to update integrations only if you want to use the extra surface (memos, policies, burnBlocked, permit via ERC-2612).

In practice this means a B20 token address pasted into Basescan renders as a standard ERC-20 token page — supply, holders, transfers, the full view. Wallets pick it up via “Import token” the same way they’d import any ERC-20. Subgraphs written against the ERC-20 ABI index B20 Transfer events without modification. The Memo event is a separate log that indexers can opt into if they want the payment-tag data, but nothing existing breaks.

Everything that was true about your ERC-20 code still works. What changes is that you no longer need to write the code.

How a B20 token actually gets created

Every B20 token is created by a single call to the B20 factory precompile:

createB20(variant, salt, params, initCalls)

• variant — ASSET or STABLECOIN.
• salt — caller-chosen entropy that fixes the token’s deterministic address.
• params — ABI-encoded name, symbol, initial admin, and variant-specific data (decimals for an Asset, a currency code for a Stablecoin).
• initCalls — an optional batch of configuration calls (grant roles, set the supply cap, bind policies) applied atomically at creation.

The factory lives at a fixed, network-wide address on Base mainnet, Base Sepolia, Vibenet, and local base-anvil:

Precompile	Address
B20 factory	0xB20f000000000000000000000000000000000000
Policy registry	0x8453000000000000000000000000000000000002
Activation registry	0x8453000000000000000000000000000000000001

Token addresses are deterministic and encode the variant directly: [10-byte B20 prefix][1-byte variant][9-byte keccak256(deployer, salt)]. Tokens created by the factory start with 0xB200…; the factory itself is 0xB20f…. You can predict a token’s address before creating it with getB20Address(variant, deployer, salt), which matters for issuers who need to publish a token address before deployment.

One more thing to check before you broadcast: token creation is gated by an Activation Registry, which tracks which Base features are live on the network. The deployment tutorial shows the exact preflight call — a false result there means a factory call will revert with FeatureNotActivated.

Two flavors: Asset for everything else, Stablecoin for fiat-backed

B20 ships in two variants, each tuned to a different issuer profile.

Asset is the general-purpose variant. Decimals are configurable between 6 and 18 at deployment and immutable afterward. It adds four features on top of the base B20 surface:

• A WAD-precision rebase multiplier for tokens whose balances scale over time (yield-bearing assets, treasury tokens).
• On-chain announcements — a public disclosure event bracket for sensitive operations like batch mints or multiplier updates. announce(...) emits an Announcement, executes an internal batch of calls, then emits EndAnnouncement.
• Batch minting to multiple recipients in a single call, gated by MINT_ROLE.
• Extra metadata — an issuer-defined key/value store on-chain, useful for legal identifiers, whitepaper hashes, or reserve attestations.

Stablecoin is the focused variant for fiat-backed assets. Decimals are hard-wired to 6 (the industry norm for USDC-style stablecoins). It adds an currency() field with an ISO-style code ("USD", "EUR") that’s set once at creation and never changes. The currency code is self-declared and not verified against any external registry — it’s a metadata contract with the ecosystem, not an oracle.

Which one to pick is usually obvious. If you’re issuing a fiat-backed stablecoin, you want the Stablecoin variant for the fixed decimals and currency semantics. Everything else — RWAs, equities, memecoins, game currencies, governance tokens, yield-bearing tokens — belongs in the Asset variant.

What comes built into the token (the Issuer Toolkit)

The features that stablecoin and RWA teams currently ship as bespoke smart-contract code are all standard in B20. Base calls this the Issuer Toolkit — a fixed set of primitives that replace real code you’d otherwise write, audit, and maintain.

Feature	What it gives you
Role-based access control	A fixed set of roles gates every sensitive operation: DEFAULT_ADMIN_ROLE, MINT_ROLE, BURN_ROLE, BURN_BLOCKED_ROLE, PAUSE_ROLE, UNPAUSE_ROLE, METADATA_ROLE. The Asset variant adds OPERATOR_ROLE. Extends OpenZeppelin’s AccessControl.
Admin-less transition	A dedicated renounceLastAdmin() call permanently transitions a token to admin-less — deliberately separate from renounceRole so no one accidentally bricks the admin surface.
Transfer policies	A singleton Policy Registry precompile stores allowlist and blocklist policies. Each B20 token binds them to four scopes: transfer sender, transfer receiver, transfer executor, and mint receiver.
Freeze-and-seize	burnBlocked burns from a policy-blocked account without its cooperation — the exact path regulated issuers need for court orders and sanctions compliance, now a first-class token operation.
Supply cap	Optional, enforced on every mint. Setting the cap below totalSupply reverts; the sentinel type(uint128).max means “no cap.”
Granular pause	Pause TRANSFER, MINT, and BURN independently, with separate PAUSE_ROLE and UNPAUSE_ROLE gates. Stop new issuance during an incident while keeping transfers live.
Memos	transferWithMemo, transferFromWithMemo, mintWithMemo, and burnWithMemo attach a bytes32 payload and emit an indexed Memo event immediately after the standard Transfer. This is the primitive that makes on-chain payments cleanly reconcilable.
ERC-2612 permit	Signed approvals out of the box — holders approve spenders without a separate transaction.
ERC-7572 contractURI	A standard entry point for off-chain metadata.

Two of these bite people in production:

Default-open transfer policies. Every policy scope defaults to ALWAYS_ALLOW at creation. An unattended B20 deployment is fully open, so token behavior must be intentionally constrained inside initCalls. If you skip this step, your “regulated” stablecoin has no gate.

Memos are the payments primitive. The memo isn’t there for compliance flavor — it’s the piece that finally makes on-chain payments cleanly reconcilable against off-chain orders. See accepting B20 payments for the flow.

Who B20 is actually for

Base’s official framing is three issuer types, plus a fourth we’d add:

1. Stablecoin issuers. Fixed 6-decimal precision, ISO currency codes, freeze-and-seize, and pause primitives are exactly what a compliant stablecoin issuer needs. B20 removes an entire audit surface.
2. RWA and equity issuers. Configurable decimals, allowlist-gated transfers, extra metadata for legal identifiers, and on-chain announcements for material events (dividends, corporate actions, batch issuance). The Asset variant targets this profile directly.
3. Long-tail token creators. Memecoin and app-token teams that don’t need compliance features still benefit from the cost and throughput improvements, and from not having to write, deploy, or audit a token contract at all.
4. Everyone else building on Base. If your product just needs a token — a points system, an in-game currency, a receipt token for a DeFi position — B20 is the shortest path to a working token that behaves like an ERC-20 anywhere else on the internet.

Deploying a B20 through a Chainstack Base node

Chainstack Base nodes serve the same precompiles as any Base node, so you can create and query B20 tokens through your Chainstack endpoint without any special setup. The full walkthrough is here; the shape of it is:

1. Deploy a Base node on Chainstack (manage your networks) and copy your HTTPS endpoint. Base Sepolia is free for testing; use it before mainnet.
2. Install Base’s Foundry build (base-forge, base-cast) — standard Foundry can’t simulate the B20 precompiles locally.
3. Verify B20 is activated for your target variant via the Activation Registry.
4. Write and run the create script — one createB20 call configures the token with its admin, minter, and supply cap atomically.

The core script from the tutorial:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {Script, console} from "forge-std/Script.sol";

import {B20Constants} from "base-std/lib/B20Constants.sol";
import {B20FactoryLib} from "base-std/lib/B20FactoryLib.sol";
import {IB20Factory} from "base-std/interfaces/IB20Factory.sol";
import {StdPrecompiles} from "base-std/StdPrecompiles.sol";

contract CreateToken is Script {
    function run() external returns (address token) {
        address account = vm.envAddress("ACCOUNT_ADDRESS");
        bytes32 salt = keccak256("my-first-b20");

        // Name, symbol, initial DEFAULT_ADMIN_ROLE holder, decimals (6-18).
        bytes memory params = B20FactoryLib.encodeAssetCreateParams("My Token", "MYT", account, 18);

        // Configuration applied atomically at creation.
        bytes[] memory initCalls = new bytes[](2);
        initCalls[0] = B20FactoryLib.encodeGrantRole(B20Constants.MINT_ROLE, account);
        initCalls[1] = B20FactoryLib.encodeUpdateSupplyCap(1_000_000e18);

        vm.startBroadcast();
        token = StdPrecompiles.B20_FACTORY.createB20(IB20Factory.B20Variant.ASSET, salt, params, initCalls);
        vm.stopBroadcast();

        console.log("B20 token created at:", token);
    }
}

For issuers deploying to production, Chainstack Dedicated Nodes give you a Base node with an SLA rather than a shared endpoint, and Flashblocks on Base provides 200ms preconfirmations for user-facing flows where the standard 2-second block feels slow. Both apply to B20 tokens the same way they apply to any other Base workload.

Accepting B20 payments

The most immediate application of B20’s memo primitive is on-chain payments that tie cleanly to off-chain orders. transferWithMemo(to, amount, memo) sends tokens and attaches a bytes32 reference (an order ID, an invoice number, a settlement tag) that emits as an indexed Memo event.

On the merchant side, reconciliation reduces to reading Memo events on the token contract through your Chainstack endpoint:

base-cast logs --address $TOKEN "Memo(address,bytes32)" \
  --from-block <FROM_BLOCK> --rpc-url $RPC_URL

Two things to know before you build this into production. First, B20 decimals range from 6 to 18 — read decimals() rather than assuming 18. Second, a B20 transfer can revert where a plain ERC-20 would not: PolicyForbids if a transfer policy denies the sender or recipient, ContractPaused if the issuer paused transfers. Simulate before sending so a failed payment is visible, not silent. The B20 payments walkthrough has the full flow with both base-cast and viem.

What’s next: gas in B20, virtual addresses, and native indexing

Beryl shipped the first version of B20. The next Base network upgrade, Cobalt (targeted for September 2026), extends what B20 can do because the standard runs in the node instead of the EVM:

• Pay transaction fees in your own token. No ETH required — the sequencer accepts B20 as gas.
• Virtual addresses — unique deposit addresses that forward to a shared account, useful for exchange deposit flows and payment routing.
• Indexed data via Base Node RPCs — aggregated balances, transfer history, and token metadata queryable directly from the node, no external indexer required.
• Lower fees and higher throughput — Base has stated a ~50% reduction on transfer costs and roughly 2× TPS.

Native gas payment and native indexing are the two that most change the shape of what you can build. A stablecoin issuer whose users never touch ETH is a real product now, not a workaround.

Conclusion

B20 doesn’t ask you to relearn what a token is. It removes the parts of issuing one that were never really the point — writing the boilerplate, auditing the same code everyone else already audited, rebuilding compliance features from primitives. The interface is still ERC-20. The precompile handles everything you used to write. The Issuer Toolkit gives regulated teams the exact primitives they need without a custom contract.

The practical decision for anything you ship on Base after June 25, 2026:

• Pick B20 when your token’s behavior fits the standard surface — transfers, mints, burns, roles, policies, memos, pause. This covers ~90% of what people actually launch: stablecoins, RWAs, memecoins, gaming currencies, points, receipt tokens, governance tokens.
• Stick with a custom ERC-20 when your token needs behavior the precompile can’t express — custom transfer hooks (fee-on-transfer, rebasing beyond the multiplier, snapshotting), non-standard events, or bonded accounting the standard doesn’t cover.
• Wrap a B20 when you need one custom feature on top of an otherwise standard token. Let B20 handle the base surface, add your logic in a thin contract around it. You still get audited compliance primitives underneath and skip the boilerplate.

To try it end-to-end: deploy a Base node on Chainstack, follow the B20 deploy tutorial, and check the resulting token in a wallet — it’ll show up as a normal ERC-20, because that’s what it is.

FAQ

Additional resources

Base official

• B20 native token standard specification
• Introducing Base Beryl
• base-std — Solidity interfaces and helpers for B20

Chainstack docs

• Base B20 token standard
• Base: deploy a B20 token
• Base: accept B20 payments

Base infrastructure on Chainstack

• Build better with Base
• Flashblocks on Base via Chainstack RPC
• Chainstack Dedicated Nodes

Related Chainstack articles

• Base transaction lifecycle: sequencer, finality, and RPC
• Base migration: from OP Stack to base/base
• Best Base RPC providers in 2026
• How to get a Base RPC endpoint (2026 guide)