Full Report
Starknet is an L1 that utilizes a ZK prover. The blockifier is the creator of the blocks and proofs. I imagine that they have a centralized sequencer, but I'm not sure. Recently, they experienced an outage during which new blocks could not be built. The Blockifier had an issue with a complicated set of contract calls: F1 calls F2 and F2 calls F3, where F2 and F3 are the same contract. F3 changes a variable in storage. After F3 has finished, F2 changes the same variable from step 2. F2 panics. F1 catches the revert and continues execution. In this case, the value of the variable should have been the original value prior to calling F2 at all. In reality, the value from F3 was used! Since this is just block production, the ZK prover still got it right. So, no weird writes after reverts in the execution layer. Even though this led to an outage, it's cool to see the prover to its job. To ensure this doesn't happen again, they have some new initiatives internally. They are re-architecting the prover-compliant execution to run directly after transaction execution. If they don't match, then an auto-halt will occur. Although a crash is bad, it's better than a deep reorg. They will add better fuzzing. In reality, I doubt fuzzing would have found this bug though.
Analysis Summary
# Incident Report: Blockifier Logic Flaw Leading to Starknet Outage
## Executive Summary
On January 5, 2026, Starknet experienced a major service outage caused by a logic bug in the "Blockifier" component, which manages transaction execution. A specific sequence of nested contract calls and reverts led to incorrect state writes, triggering a block production halt and an 18-minute chain reorganization (reorg). No permanent data corruption occurred because the network's ZK-proving layer successfully detected the inconsistency and prevented the incorrect state from reaching L1 finality.
## Incident Details
- **Discovery Date:** January 5, 2026, 09:36 UTC
- **Incident Date:** January 5, 2026
- **Affected Organization:** Starknet
- **Sector:** Blockchain / Web3 Infrastructure
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** January 5, 2026, 09:24 UTC
- **Vector:** Logic Flaw / Edge Case (Non-malicious)
- **Details:** Complex transaction execution involving nested function calls (F1 -> F2 -> F3) triggered a state-writing error. Specifically, a revert in F2 failed to properly roll back state changes made in F3 when both functions belonged to the same contract.
### Lateral Movement
- **N/A:** This was a protocol logic failure, not a breach involving an external actor moving through a network.
### Data Exfiltration/Impact
- **Data Impact:** 18 minutes of transaction activity (09:24 – 09:42 UTC) were dropped/reverted.
- **Operational Impact:** Total network unavailability for approximately 4.5 hours (09:42 – 14:17 UTC).
### Detection & Response
- **09:36 UTC:** System alerts notified the team of execution inconsistencies.
- **09:42 UTC:** Team determined a reorg was necessary; sequencing was intentionally paused to prevent further incorrect state-building.
- **09:42 – 14:17 UTC:** Debugging, root cause analysis, and development of a local fix.
- **14:17 UTC:** Fix deployed; block production and continuous operation restored.
## Attack Methodology
*Note: This was a software bug, not a targeted cyber-attack. The "methodology" refers to the technical failure mechanism.*
- **Initial Access:** Execution of a complex cross-function call sequence.
- **Defense Evasion:** The Blockifier’s Rust-based simulation of Cairo code contained logic gaps that diverged from the "real" Cairo program requirements.
- **Impact:** The Blockifier incorrectly retained a variable value from a reverted sub-call instead of returning to the original pre-call state.
## Impact Assessment
- **Financial:** Unknown; potential loss of gas fees and opportunity costs for users during the 4.5-hour downtime.
- **Data Breach:** None. The ZK-prover acted as a safety backstop, ensuring invalid data was never finalized on L1.
- **Operational:** 18 minutes of blockchain history reverted; 4.5 hours of total network downtime.
- **Reputational:** High; requires transparency regarding sequencer reliability and the centralized nature of current block production.
## Indicators of Compromise
- **Behavioral indicators:** Execution inconsistencies between the Blockifier (sequencer) and the Proving layer; unexpected state transitions in nested contract calls.
## Response Actions
- **Containment:** Intentional halting of the sequencer to prevent the propagation of the "bad" state.
- **Eradication:** Identification and patching of the specific logic bug in the Blockifier's revert handling code.
- **Recovery:** Network restart and performance of an 18-minute reorg to restore the chain to the last known valid state.
## Lessons Learned
- **Architecture Validation:** The ZK-proving layer successfully performed its role as a "source of truth," proving that a dual-execution environment (Rust Blockifier vs. Cairo Prover) provides high security even if one side fails.
- **Testing Gaps:** Standard unit tests failed to capture the specific edge case of nested calls within the same contract combined with specific revert/catch patterns.
## Recommendations
- **Aggressive Fuzz-Testing:** Implement new testing suites that fuzz Blockifier results against the Starknet OS (SNOS) to find logic gaps.
- **Architecture Re-design:** Move prover-compliant execution earlier in the pipeline (directly after transaction execution).
- **Automated Safeguards:** Implement "auto-halt" functionality that triggers immediately if a disparity between the sequencer and prover is detected, minimizing the depth of potential reorgs.
- **Internal Audit:** Conduct a comprehensive review of all nested revert logic within the Blockifier.