What Caused the Two Base Network Outages on June 25–26, 2025 — and Is a Single Sequencer Safe?

That invalid block triggered a consensus failure: the sequencer produced an invalid block after block 47,806,542, blocking the network from building any further blocks. Node operators could not continue normal synchronization until the issue was addressed.

Timeline of the Two Halts

The second outage on June 26 was described as the same underlying class of block-production failure recurring shortly after the first incident, though the network recovered more quickly the second time.

During both periods, new blocks were frozen or halted, disrupting normal on-chain transaction processing. However, no user funds were reported to be at risk during either incident.

The Deployed Fix

Base’s engineering team applied a patch to the sequencer to ensure the journal state is properly updated during execution after a failed transaction. The fix can be tracked in a public GitHub pull request (#3806).

After the fix, normal operations resumed, but Base advised validator-node operators to restart or resync their nodes to restore sync status. The team noted that both outages originated from the same bug, and that a second, related issue (PR #3805) caused the incident to recur the following day.

In the aftermath, Base delayed the rollout of its planned Beryl mainnet upgrade and B20 token standard activation by one day to stabilize the network.

Single-Sequencer Architecture: A Broader Concern

The back-to-back outages reignited debate about the resilience of Base’s single-sequencer design, which is common among many optimistic rollups but introduces a clear single point of failure.

Key concerns raised by the post-mortem and industry coverage include:

• Single point of failure: A sequencer-level bug in block-building logic could halt Base’s entire block production, freezing new blocks across the network.
• Manual recovery: Recovery required validator-node operators to restart or resync their nodes manually, rather than the network self-healing.
• Reliability risk: The back-to-back failures raised fresh questions about the reliability of the rapidly scaling L2 ecosystem, especially during periods of high activity or scheduled upgrades.
• Planned improvements: Base said it would strengthen its testing with fuzz tests, load tests, monitoring, and better recovery tools to reduce the odds of recurrence.

The incident shows that even the largest Ethereum L2 networks can be knocked offline by a state-management edge case in a single sequencer — and that automated failover and recovery systems are still a work in progress across the rollup ecosystem.