The team behind Starknet, an Ethereum layer‑2 (L2) scaling network, released a post-mortem report outlining the root cause of the temporary mainnet downtime on Monday.
The root cause of the mainnet downtime was a discrepancy in the network state between the blockifier execution layer and the proving layer that checks that the execution layer is processing transactions correctly, according to the report. The Starknet team explained:
“In one specific combination of cross-function calls, variable writes, reverts, and catching them, the blockifier remembered a state-writing that happened within a function that was reverted, causing an incorrect transaction execution.
This incorrect execution never saw L1 finality thanks to Starknet’s proving layer,” the StarkNet team said, highlighting how the proving layer functioned properly by flagging the error and not committing the faulty transactions to the ledger.
The incident forced a block reorganization, and 18 minutes of network activity to be reverted. StarkNet is back to normal functionality, the team said.
The incident prompted the team to commit to testing and code audits to prevent similar issues in the future. Monday’s StarkNet disruption also highlights the challenge of coding for the latest generation of blockchain networks, which include multi-layered technology stacks.
Related: Iran is cut off from the internet: Here’s how crypto could still work
StarkNet experienced several disruptions in 2025, with the most serious outage occurring in September following a major protocol upgrade called Grinta.
The outage lasted over five hours and was caused by a sequencer bug, according to a post-mortem report from the Starknet team. Sequencers are the systems used to order transactions on a blockchain network.
During the outage, block production halted, and two chain reorganizations were executed to restore the network to a functional state.
The reorganization forced about 1 hour of network activity to be reverted or rolled back, meaning users had to resubmit the transactions.
From a user perspective, having to resubmit a transaction is a minor pain if the transaction was not time-sensitive, but it could prove catastrophic for a frequent trader or an investor who needs to exit a position or post a transaction within a short timeframe.
