On January 5, 2026, Starknet experienced an outage during which block production was halted. Eighteen minutes of activity were reverted.
We recognise the impact this had on our users and partners, and we are committed to providing full transparency into what happened, how it was resolved, and what steps we are taking to prevent recurrence.
Since the incident ended on January 5 at 14:17 UTC, Starknet has been fully operational.
Summary
The activity that happened on Starknet between 09:24 and 09:42 UTC on January 5th was dropped, and between 09:42 and 14:17 UTC, Starknet was unavailable. Sequencing was intentionally paused for safety while we investigated and executed recovery.After receiving an alert at 09:36, the team concluded that a reorg is required to restore normal operation, and halted immediate block production to avoid a larger remediation.
Between 09:42 and 14:17, the team debugged the incident, found the bug, deployed a fix (including several tests), and restored continuous operation.
The core issue: a blockifier bug (explained in detail in the “root cause” section), caused the blockifier to process a transaction incorrectly. Specifically, 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 . But this incorrect execution never saw L1 finality thanks to Starknet’s proving layer.
Starknet’s proving layer served as the safeguard that prevented these inconsistencies from compromising the blockchain’s integrity. This design reflects a core principle of Starknet: to preserve correctness and security regardless of any undesired sequencer behaviour, whether caused by software bugs or by malicious activity.
Root Cause
To understand the bug, you need to understand how Starknet achieves both speed and security.
The blockifier is the component inside the Starknet sequencer that executes all the transactions. But it is not running the Cairo program, which the Starknet prover then proves the execution of, because it must sustain great throughput, and needs to be as efficient as possible.
Therefore, the blockifier works with a different flavour of the SN core Cairo program that is written in Rust. Whenever a contract performs a syscall, the blockifier version will simulate the “real behaviour”. For example, reading a variable is a simple DB access for the blockifier, but will involve Merkle-hash-checks that the variable read is “really what the state should have” when executing the “real Starknet Cairo code”
The Concrete issue with the blockifier execution
The bug that happened between three functions F1, F2 and F3, such that:
- F1 calls F2, F2 calls F3
- F2 and F3 are within the same contract (F1 may be in another contract)
- F3 changes some variable X
- After the call to F3, F2 changes the same Variable X
- F2 panics, and F1 catches the revert and continues the execution.
In this case, the blockifier reverted X to its value from after the call to F3, instead of the correct reversion (to its value before calling to F2)
As Starknet receives more and more usage and adoption, and its dapp’s code-base grows more complex, this inconsistency surfaced and was quickly mitigated.
Key Learnings and Prevention Measures
In addition to detecting, analyzing, and rapidly fixing the bugs that caused this failure we are also implementing a set of measures designed to further minimize the likelihood of similar issues in the future:
- Aggressive Fuzz-Testing: We’re implementing new testing suites that fuzz the Blockifier’s results against the SNOS to catch these “edge-case” logic gaps.
- Internal Audit: We’re doing a deep dive into the Blockifier’s revert logic to ensure no other nested scenarios could trigger a similar issue.
- Faster detection: We’re re-architecting so that the prover-compatible execution runs asap after the transaction execution. If they don’t match, the network will auto-halt instantly, minimizing the size of any potential reorg.
Closing
Starknet is back online and fully operational, and the fix applied has already increased network resilience. By identifying and addressing the bug immediately upon detection, and with the proving layer serving as a backstop, Starknet emerges more robust.
We’re committed to pushing the boundaries of throughput and decentralisation, but never at the expense of correctness.
Thank you, Starknet community, for your understanding and support as we worked through this issue.
