Base Halted Block Production Twice in Two Days, Delaying Beryl

Base, an Ethereum layer-2 network, stopped producing blocks twice within two days at the end of June. The first halt began at 16:03 UTC on 25 June and ran for 116 minutes by the network's own postmortem; a second stoppage began at 15:33 UTC on 26 June and lasted 20 minutes on the same count. Both traced to a single defect in the software that assembles blocks, which produced a block validators rejected at height 47,806,542. Base said no user funds were at risk, though deposits and withdrawals were delayed and new transactions were refused while the chain stood still. It was the first halt in 90 days. It also pushed back the Beryl hardfork that had been scheduled for 25 June.

Stale state from a failed transaction

A sequencer is the single program that orders incoming transactions on a layer-2 network and packs them into blocks. As it executes each one, it keeps a journal, a running record of the changes that transaction would make, so the work can be discarded if the transaction turns out to be invalid. Base's postmortem said "a bug in sequencer block-building logic allowed stale journal state to persist after a transaction validation failure". In plain terms, the discarded work of a failed transaction was not fully cleared away. The next legitimate transaction then executed against that corrupted state. It was charged the wrong amount of gas, the fee paid for computation on the network, and the block containing it described a state transition that validators independently recomputed and refused to accept. With no agreed next block, production stopped. Base said the correction shipped as pull request #3806.

A second fault in the restart path

The 26 June outage was not an independent failure but a product of the recovery from the first. Base attributed it to a secondary bug in its engine-reset feature, the mechanism that returns block-building to a known-good starting point, which misfired during the restart and stopped the chain again. How long each outage lasted depends on who measured it. Base put the two at 116 minutes and 20 minutes. Third-party uptime trackers logged roughly one hour and 48 minutes for the first and about 38 minutes for the second — slightly shorter than the official figure in one case and close to twice as long in the other. Neither account confirms the other.

25 June, 16:03 UTC: first halt, 116 minutes officially, about 1 hour 48 minutes per trackers.
26 June, 15:33 UTC: second halt, 20 minutes officially, about 38 minutes per trackers.
Block height 47,806,542: the invalid block validators refused.
Pull request #3806: the fix for the block-building bug.

A full mempool and refused submissions

While block production was stopped, the mempool, the queue of transactions waiting to be included in a block, overflowed. eth_sendRawTransaction, the standard call a wallet or application uses to submit a signed transaction, was rejected. Pending activity sat unconfirmed. New submissions failed outright instead of waiting in line. Deposits and withdrawals were delayed, not lost, and Base repeated in its postmortem that no funds were at risk at any point in either outage. Coinbase shares, which trade as COIN, fell more than 5%.

Beryl slips, and the sequencer question stays

Beryl, the hardfork scheduled for 25 June, first slipped to 26 June and was then delayed further. Its centerpiece is mainnet enablement of the B20 Activation Registry, a new token standard packaged with finality improvements, and Base said the postponement was intended "to ensure a smooth rollout." The open question is structural, not a matter of any one bug. Base runs a single centralized sequencer with no automatic failover, so when that one component builds a block validators reject, there is nothing for the network to switch to and the chain stays down until operators intervene. That design drew renewed criticism after the two halts. It is also what will decide how long the next fault of this kind lasts.