Starknet is down again: the execution layer and the proof layer are fighting, and 18 minutes of activity have been rolled back.

Ethereum L2 network Starknet experienced a mainnet outage this Monday. According to the post-incident analysis report released on January 11, the incident was caused by a state inconsistency between the execution layer (blockifier) and the proof layer. In specific cross-function call and rollback scenarios, the execution layer incorrectly recorded a state that should have been rolled back, leading to transaction execution anomalies. Although the affected transactions did not receive finality confirmation on L1, the event triggered a block reorganization, rolling back approximately 18 minutes of on-chain activity. Notably, this is the second major outage event for Starknet since 2025.

Technical Details: “Desynchronization” Between Execution Layer and Proof Layer

Root Cause of the Incident

The technical cause of this outage is relatively complex. Starknet’s architecture involves two key layers: the execution layer, responsible for processing transaction logic, and the proof layer, responsible for generating zero-knowledge proofs and submitting them to the Ethereum mainnet. During this incident, when specific function calls and rollback operations occurred in combination, the (blockifier) incorrectly recorded a state that should have been rolled back, causing a conflict between the two layers’ states.

The good news is that the proof layer correctly identified this error and rejected the problematic transaction, preventing it from being committed to the ledger. This “self-correcting” mechanism prevented the erroneous state from being permanently recorded on the Ethereum mainnet.

Why Reorganization Was Necessary

Due to the inconsistency between the execution layer and the proof layer, the network was forced to perform a block reorganization to restore normal state. This reorganization rolled back about 18 minutes of network activity, requiring users to resubmit transactions. For non-time-sensitive transactions, the impact was minimal, but for frequent traders or operations requiring quick execution (such as emergency liquidations), it could cause actual losses.

Historical Comparison: Increasing Frequency of Issues

Although this rollback was shorter (18 minutes vs. 1 hour), the increasing frequency is becoming evident. Between September and January, Starknet experienced two major disruptions within less than half a year, with different fault types, indicating potential risks at multiple system layers.

Team Response and Commitments

Immediate Actions

Following the release of the post-incident report, the Starknet team made several commitments:

• Strengthen code testing processes, especially for boundary conditions and complex scenarios
• Enhance code auditing mechanisms to prevent similar state inconsistency issues
• Plan to release version v0.14.1, which includes hash function upgrades and block production optimizations

These measures demonstrate proactive efforts to improve system stability, but whether they can effectively prevent future failures remains to be seen.

Impact on the Ecosystem

User Level

The actual impact on users was relatively limited because:

• The rollback duration was short (18 minutes), affecting a relatively small number of transactions
• The affected transactions did not achieve finality on L1, so no funds were truly lost
• Users mainly needed to resubmit transactions rather than face asset loss

Ecosystem Level

However, from a broader perspective, frequent outages pose challenges to Starknet’s ecosystem development:

• Reduce user confidence in network stability
• Potentially hinder deployment of DeFi applications
• Place Starknet at a disadvantage in competition with other L2 projects (such as Arbitrum, Optimism)

It is worth noting that Starknet is actively expanding its application scenarios, such as partnering with Noon to launch Bitcoin Vaults and collaborating with projects like AlchemyPay. Whether these ecosystem developments can offset the negative impact of stability issues remains a key point to observe.

Summary

The Starknet outage reflects the technical challenges faced by L2 networks in complex scenarios. Rather than a severe security vulnerability, it highlights shortcomings in handling boundary conditions. The proof layer’s “self-correcting” mechanism effectively prevented fund loss, but frequent disruptions cannot be ignored.

The key question is whether Starknet’s improvement measures will prove effective. Strengthening testing and auditing is necessary, but whether they can fundamentally resolve such issues depends on subsequent versions’ performance. For ecosystem participants, trusting Starknet also involves monitoring its progress in improving stability.