Starknet Post-Mortem Details Execution Bug Behind Brief Mainnet Outage

• A blockifier state bug caused a mismatch with the proving layer, leading to a halt and rollback of recent Starknet activity.
• Safety systems stopped faulty execution before Ethereum finality, though users still faced downtime and transaction reversals.
• Around 18 minutes of network activity was reverted, forcing users to resubmit transactions after service resumed.
• Starknet plans stronger testing and faster detection as complex layer-2 systems continue to face reliability risks.

Starknet has released a post-mortem report explaining the cause of a brief mainnet outage on Monday. The incident led to a short network halt and a rollback of recent blocks. 

However, it did not affect the final settlement on Ethereum. According to the team, built-in safety systems worked as intended, even though users experienced downtime and transaction reversions.

Starknet Downtime Traced to Blockifier State Handling Bug

As contained in the report, the outage stemmed from a mismatch in network state between Starknet’s execution layer, known as the blockifier, and its proving layer. The blockifier is responsible for executing transactions. Meanwhile, the proving layer verifies that those executions are correct before they are finalized on Ethereum.

A software bug inside the blockifier caused an incorrect transaction result under a very specific set of conditions. These included cross-function calls, state changes, transaction reverts, and logic that catches those reverts. 

Image Source: Starknet

In that edge case, the blockifier mistakenly kept a state change that should have been discarded after a function reverted. As a result, the transaction outcome differed from what the proving layer expected.

Due to the inconsistency, the faulty execution never reached Ethereum finality. Instead, the network halted and rolled back recent activity to restore a consistent state. Starknet’s team said this behavior reflects a core design principle focused on maintaining correctness even when execution software behaves unexpectedly.

A block reorganization followed the incident, wiping out about 18 minutes of network activity. During that time, confirmed transactions were reverted and had to be resubmitted once the network returned to normal. Starknet said full functionality has since been restored.

Repeated Outages Put Spotlight on Layer-2 Network Complexity

In 2025, Starknet users witnessed a more disruptive outage than Monday’s incident. In September, a major protocol upgrade called Grinta triggered a sequencer bug that halted the network for over five hours. 

Image Source: Starknet

During that period, transactions could not be processed, forcing users to wait or resubmit activity. Two chain reorganizations were required to restore normal operation, and about one hour of network activity was rolled back.

Users affected by that event also had to resubmit transactions, creating friction for active market participants. These incidents point to ongoing challenges faced by advanced layer-2 networks.

Starknet runs on several closely linked systems, including execution engines, zero-knowledge proving layers, sequencers, and settlement on Ethereum. Each layer improves security or scalability, but also increases complexity. 

As more layers interact, rare software bugs can surface in unexpected ways, even when core safety mechanisms remain intact.

Starknet Incident Highlights User Costs of Layer-2 Rollbacks

The latest outage illustrates how small execution errors can still trigger visible disruptions, even when safety systems perform correctly. Starknet’s proving layer served as a safeguard, catching the inconsistency before final settlement. However, that protection does not remove the user-facing cost of downtime and reorgs.

Small execution errors can still cause noticeable network disruptions, even when built-in safety systems work as intended. In Starknet’s case, the proving layer detected the faulty transaction before it reached final settlement on Ethereum, preventing lasting damage to the network.

Even with user funds protected, downtime and chain reorganizations still disrupted normal activity. Traders and applications that depend on fast and predictable transaction execution were most affected, as reverted blocks forced users to resend transactions and manage unexpected delays.

Starknet Tightens Testing Around Blockifier and Proving System

Ongoing engineering reviews are underway at Starknet following the recent mainnet disruption, with a focus particularly on reducing the risk of similar incidents. New fuzz-testing suites are being introduced to compare blockifier execution results directly against the proving system. 

An internal audit of the blockifier’s revert logic is also in progress to identify other scenarios that could lead to incorrect state handling. In addition, the team plans to shorten the time between transaction execution and prover-compatible execution.

Faster comparison would allow mismatches to be detected sooner, limiting how much network activity would need to be rolled back.

Starknet framed the incident as proof that its safety model worked as designed, as faulty execution never reached Ethereum finality. At the same time, the team acknowledged that improving stability remains a priority as layer-2 technology continues to mature.