The real focus is on "controllable": permissions, black/white lists, freezing, and memos.

Written by: KarenZ, Foresight News

This article was first published on June 30

Original title: "Base's new token issuance gateway B20, what assets does it intend to support?"

Original text:

On June 25 and 26, the Base mainnet experienced a block production halt for two consecutive days. Base later reviewed and stated that both interruptions stemmed from the same underlying issue: a bug in the sequencer block construction logic.

According to Base's review, the vulnerability caused outdated log states to persist after transaction verification failures, affecting the Gas calculations for subsequent valid transactions, thereby generating invalid state transition blocks, which caused the entire L2 network to cease block production. After the first halt, the official patched the issue and resumed block production. Additionally, there was a race condition in the sequencer cluster during the restart process, which hindered the recovery sync and became an indirect cause for a short halt on the following day.

During the same time window, the activation of the B20 mainnet that Base originally intended to push forward was also put on hold.

On June 26, Base stated, "Due to recent network stability issues, the activation of the B20 Activation Registry on the mainnet will be delayed to ensure a smooth launch process."

This step may seem conservative, but it actually indicates the significant role of B20. It is not just an update to a fringe application, but rather Base's intention to serve as a chain-level entry point for stablecoins, RWAs, and more asset issuance. The closer the entry is to the underlying layer, the more it cannot merely focus on whether the functionality is complete; it also needs to assess whether network stability, upgrade cadence, and permission design can withstand together.

B20: Base's Native Token Issuance Interface

B20 is part of the Base network upgrade, Beryl. The three core changes in Beryl are: introducing B20, shortening the final confirmation period for common single proof withdrawals from 7 days to 5 days, and improving node storage and throughput performance through Reth V2.

B20 can initially be understood in the simplest way: it is an ERC-20 version for Base, but many logics that would originally be written, audited, and maintained by the project party are incorporated into Base's native components.

Ordinary ERC-20 tokens are typically deployed by the project party via a smart contract to handle balances, authorization, transfers, minting, burning, and other logics. The difference with B20 is that the token still has an on-chain address and can be called by wallets, browsers, and DeFi protocols in an ERC-20 manner; but B20 is implemented using Rust precompiled programs rather than EVM smart contracts, thus offering faster speeds and lower costs.

In other words, external integrators see an ERC-20 compatible token interface, while issuers are accessing Base's built-in token issuance infrastructure.

This is also why B20 is known as Base's native token standard. Base's official documentation states that B20 is the ERC-20 version of the Base ecosystem, supporting standard ERC-20 calls and events such as transfers, authorizing third-party transfers, approval amounts, balance queries, allowances; while also adding capabilities such as memos, minting/burning, strategy gating, granular pauses, and ERC-2612 permits (signature authorization).

Here, it is necessary to explain ERC-2612 permit, which is the signature authorization capability. In a regular ERC-20, when a user wants a contract to spend their tokens, they usually have to send an approve transaction first, which incurs Gas costs. ERC-2612 permit allows users to complete the authorization using an offline signature from their wallet, which is then submitted by the project party or application on-chain. Users do not need to send separate approve transactions, reducing one on-chain approve operation.

If we use a more relatable analogy, traditional ERC-20 is like each issuer building a house with their own set of standard blueprints, where the construction quality depends on their individual development and audit. B20 is more like Base providing a set of standardized prefabricated structures: the entry, interfaces, and key functionalities are standardized, while the issuer still decides the asset parameters and management rules, but the underlying capabilities come from the same set of chain-level components.

From the deployment method perspective, B20 does not allow project parties to casually copy a token contract. All B20 tokens are created through a singleton B20 Factory precompile, choosing between Asset or Stablecoin variants during creation, and passing in parameters such as name, symbol, initial administrator, supply cap, and initialization call.

Therefore, the focus of B20 is not to turn token issuance into a more attractive front-end button, but to advance the task of token issuance from "each project writing their own contract" to "Base providing a unified issuance interface and built-in strategy capabilities." It reduces the repetitive construction costs of standard functionalities while deeply integrating asset issuance into Base's own underlying upgrades.

The Real Focus is on "Controllable": Permissions, Black/White Lists, Freezing, and Memos

The toolkit for issuers listed by Base includes: ERC-20 compatibility, ERC-2612 permit, role-based access control, mint/burn, optional supply cap, transfer policies, destruction of balances from policy-frozen addresses, and transfer memos.

These functionalities may seem technical, but in the actual work of issuers, they mainly correspond to three types of issues: who has the authority to manage the tokens, which addresses can participate in circulation, and how on-chain operations leave traceable records.

First, management permissions can be layered. Who can mint, burn, pause transfers, resume transfers, and modify metadata does not need to be mixed within the same administrative permissions. The B20 documentation lists default administrator roles for minting, burning, pausing, resuming, and metadata management. This way, issuers can assign different operations to different roles, reducing the risk of a single private key or administrator having excessive authority.

Second, the scope of token circulation can be constrained by policies. The B20 Policy Registry supports whitelists and blacklists. Issuers can constrain the sending addresses of transfers, the receiving addresses of transfers, and the call initiators for transferFrom scenarios; in minting scenarios, they can also constrain the receiving addresses for newly minted tokens. Simply put, B20 can control "who sends out, who receives, and who initiates transfers on behalf of others," and can also control "who receives new tokens." Such capabilities are especially important for stablecoins, RWAs, and regulated assets, as these assets often require KYC addresses, limited recipients, freezing, and subsequent disposal pathways.

Third, on-chain operations can leave business indexes. B20 supports memos, which are bytes32 remark fields attached to token operations. It will not replace the complete off-chain ledger, but can serve as a connection point between on-chain transactions and off-chain records. For example, an on-chain payment corresponds to an order number, a redemption corresponds to a back-end settlement, and an issuance corresponds to a batch distribution record, and memos can help issuers, wallets, custodians, or indexing services reconcile this information.

Conclusion

However, to be clear, B20 merely places tools in front of issuers and will not automatically ensure compliance. Each policy scope defaults to ALWAYS_ALLOW at the token creation stage, meaning all are permitted by default. If the issuer does not actively set whitelists, blacklists, or other restrictions, this B20 token will circulate freely like a regular open token.

In other words, B20 provides issuers with the ability to "set rules," but whether to set rules and how to set them remains the responsibility of the issuer.

This also explains why B20 primarily targets stablecoin issuers, RWA, and other asset token creators. Stablecoins need permission and freezing capabilities, RWAs require transfer restrictions and off-chain record mappings, while other assets need lower standardized issuance costs. These three demands may seem different, but they all point to the same underlying issue: whether an L2 can provide a sufficiently unified and controllable environment that can be smoothly integrated into the existing ERC-20 ecosystem.