Base published a full post-mortem on social media platform X, after two-separate block-production outages on June 25 and 26. The company posted that the engineers found a bug in the sequencer’s block-building logic that let a stable in-memory journal persist after a failed transaction. This journal then caused a valid transaction to be processed on top of an incorrect state, which produced a block that other nodes could not accept. Base fixed the root cause, patched sequencers, and confirmed that no user funds were at risk.
On June 25 and 26, Base mainnet experienced two block production outages, both caused by the same underlying bug in the block builder logic.
We’ve identified and fixed the root cause, and have communicated the post mortem to OP chains as feedback.
All funds were safe… pic.twitter.com/eArnK12AgZ
— Base Build (@buildonbase) June 27, 2026
According to the report, the first incident which started at 11:47 a.m. ET on June 25, block production halted for about 116 minutes. The second event began at 11:28 a.m. ET on June 26 and lasted for almost 20 minutes. Base’s engineers said that both of these outages stemmed from the same underlying bug. A follow-up race condition in the sequencer restart logic slowed mitigation and led to the second outage before the team fully completed recovery work.
During the outages, new L2 blocks stopped being produced. Transactions piling up in the mempool were not included on-chain, which caused the transaction pool to grow and reject additional submissions. Despite the disruption to block production and transaction flow, Base reports that the integrity of on-chain balances and smart-contract state remained intact.
The engineering response included a patch to make sure the journal memory is cleared correctly when a transaction fails. This fix is available for review in Base’s GitHub pull requests. Teams also implemented an additional change to address the engine-reset race condition that interfered with sequencer catch-up after restarts. Base says it will expand fuzz testing and load-testing efforts, improve monitoring, and add graceful recovery in base-consensus so validator and sequencer nodes can resync more quickly if similar problems occur.
Developer Points to Base’s Single Sequencer As Key Weakness
In a social media post, developer and observer Vadim (X username zacodil) posted a very blunt and technical summary on X, reacting to the post-mortem. He highlighted a systemic risk and pointed to Base’s reliance on a single active block producer. He wrote that the sequencer hit an invalid transaction, and failed to wipe the leftover memory state it touched. The next valid transaction then ran on top of that dirty state, miscalculated its gas, and produced a block whose math didn’t check out.”
He added that every other node re-executed the block, got the correct result, and rejected it, the right behavior for validators. But since Base has only one block producer, rejecting the bad block left the network with no alternative producer to create a correct block, turning the honest validator’s action into a network-wide outage. The developer’s point indicates how correct software behaviour at the protocol level can still lead to service disruption when the system design centralizes production.
Background: How the Bug Produced an Invalid Block
The sequencer builds blocks by executing transactions and tracking which accounts and storage slots each transaction touches in a temporary “journal.” If a transaction fails, the journal should be cleared so subsequent transactions start from a clean state. In this case, a failing transaction did not clear the journal due to a software bug.
A valid transaction then executed against the contaminated journal and produced an incorrect receipt root and gas accounting. When validators re-executed the same transactions without the stale journal data, they computed different results and rejected the sequencer’s block. With a single sequencer producing blocks, there was no fallback producer to continue progress and the chain halted until Base patched sequencers and validators restarted to sync.
What to Watch Next
Base said in its report that it will increase protocol fuzz testing and strengthen operational monitoring. The team will also push for a smoother recovery path in consensus code and validate fixes under load. For users and builders, the best part was the fact that funds remained safe and that Base plans to make changes to reduce the chance of similar halting bugs in the future.
