Under a single active sorter, an invalid block caused Base to suspend block production.

Written by: KarenZ, Foresight News

At midnight on June 26, Beijing time, Base gave the market a quiet lesson on infrastructure.

The timeline of this downtime is clear:

• At 12:03 AM, Base reported an anomaly in the mainnet block production status, and the team was investigating.
• At 12:52 AM, Base identified the problem as originating from a faulty block that was interfering with the construction of subsequent blocks.
• At 1:21 AM, Base had located a consensus issue that caused the invalid block to be sorted. This prevented new blocks from being generated after block 47806542. Internal sorters and nodes had initially recovered.
• At 1:51 AM, the sorting of new blocks had resumed, and internal node synchronization was normal.
• At 1:58 AM, Base confirmed that healthy block construction had resumed, and the ecological infrastructure was able to regain synchronization.
• At 3:22 AM, Base further stated that the sorter and related systems remained stable, blocks were generated normally, and the team had identified the root cause of the downtime, and was validating repair solutions; a complete review report would be released later.

The Base status page indicated that this incident affected the recharge, withdrawal, block production, and client software of the Base mainnet.

Single Active Sorter Makes the Downtime More Conspicuous

Base is a Rollup built on Ethereum. It executes a large number of transactions on L2 and submits the necessary data and state-related information to Ethereum.

What users directly perceive every day is not the architecture diagram, but whether transactions can be included in blocks, whether nodes can synchronize, and whether wallets, transactions, and cross-chain services can operate normally.

Before Flashblocks went live, Base employed a highly available sorter system: among five sorter instances, one instance acted as the leader, responsible for building blocks and disseminating them through P2P, while the remaining four acted as followers synchronizing the chain state; if the current leader stopped producing blocks, the system would switch leadership.

This design illustrates that Base does have redundancy. The issue is that redundancy primarily addresses failover and availability, which does not equate to multiple independent sorters participating in block production simultaneously. Daily block production is still carried by the current leader, and once problems arise in consensus, sorting, or node synchronization, users will first notice that new blocks have halted.

After Flashblocks went live, Base's block construction gained an additional layer with a 200-millisecond pre-confirmation mechanism. Base documentation states that Flashblocks are always active on Base, with all blocks constructed by the Flashblocks builder; applications can choose whether to use pre-confirmation data or continue to wait for the standard 2-second block confirmation through standard RPC. In other words, Flashblocks have already become a part of the underlying infrastructure for current block construction on Base, but are optional for application access for pre-confirmation experiences.

The security status page of Base offers a more specific explanation: a consensus issue caused an invalid block to be sorted, thereby preventing new blocks from being generated after block 47806542. The real reason still needs to wait for the official complete review.

The Last Time Base Went Down Was Due to Inability to Configure a New Sorter Successfully

This is not the first time Base has interrupted block production due to sorter-related issues. On August 5, 2025, the Base mainnet experienced a 33-minute network interruption. An official review afterward stated that the active sorter experienced delays due to on-chain activities, and the Conductor responsible for high availability (HA) cluster management automatically switched leadership to a new sorter; however, the new sorter was still in the configuration process at that time and unable to produce blocks, and as Conductor had not fully enabled on that sorter, the system failed to initiate the next switch. The team subsequently manually paused HA and transferred leadership to a healthy sorter, restoring full functionality afterward.

Looking at the two incidents together requires caution: the August 2025 issue points to the high availability switch process of the sorter, while today's downtime incident is due to a consensus issue that resulted in an invalid block being sorted, preventing new blocks from continuing to be generated after block 47806542.

They both point to a reality: L2 can rely on Ethereum for core issues such as data availability, settlement, security, and finality, but daily availability highly depends on the sorter and related operational maintenance systems. As long as new blocks cannot continue to be generated, what users see is transactions stuck in transit.

This Downtime Coincided with the B20 Launch Window

The timing of the accident is quite delicate. Base was then near the launch window for the Beryl upgrade.

The activation time for the Beryl mainnet was originally scheduled for 2 AM Beijing time on June 26, but it has now been postponed to 2 AM on June 27.

The core elements of Beryl include three points: the introduction of the B20 native token standard, the reduction of the final confirmation period for single proof withdrawals from 7 days to 5 days, and the introduction of Reth V2 for a reduction of up to 50% in disk usage and about a 33% increase in throughput.

The difference with B20 lies in the underlying implementation. Most ERC-20 tokens are deployed in the form of EVM smart contracts, while B20 is implemented by Rust precompile and created through a singleton B20Factory. It also includes built-in role permissions, supply limits, mint/burn, pause, transfer strategies, memos, and ERC-2612 permits. In simpler terms, Base has turned the basic functionalities of tokens that many issuers repeatedly build, audit, and maintain into a chain-level toolbox.

The B20 concept is likely to spark market associations, with some community users even linking it to Base issuing tokens. However, the discussion around B20 concerns "how others can more standardize asset issuance on Base"; the discussion around Base issuing tokens concerns "whether Base will introduce its own network token in the future."

The former has already been written into the Beryl upgrade, while the latter remains a topic of market interest but has not yet been announced by the officials.

This downtime will make the discussion about Base issuing tokens more realistic. In the past, the market asked: Will Base issue tokens, when will they issue, and how will airdrops be distributed? After the incident, a more worthwhile question is: if a network token is indeed introduced in the future, what responsibilities should it correspond to? Is it decentralization of the sorter, governance constraints, security budgets, or the allocation of rights and responsibilities in incident responses?