Solana’s Mainnet Beta resumed block production on February 26, 2023, after validators coordinated a restart of a network that had stopped processing economic transactions during a prolonged performance failure.
The official Solana status record placed the successful restart at 01:28:55 UTC and moved the cluster from degraded performance to operational monitoring. The incident was marked resolved at 02:09:04 UTC. That made restoration, not the initial slowdown, the defining development for February 26.
The disruption began at 05:46:16 UTC on February 25, when slow root production pushed the network into vote-only mode. In that safety state, leaders continued handling consensus votes but omitted user transactions. Calculated from the status timestamps, the interval from entry into vote-only mode to the restart notice was 19 hours, 42 minutes and 39 seconds. That is a transaction-processing interruption window, not a claim that every validator or ancillary service was continuously offline.
A restart after a failed recovery
Core contributors first tried to stabilize the cluster while it was running. The status record later described a coordinated restart to address significantly slower block finalization during the upgrade from validator software 1.13 to 1.14. Validator instructions were revised as the effort continued. Contemporaneous reporting by The Block said the network came back after two restart attempts.
The community’s 01:28 UTC notice said engineers would keep monitoring performance. The separate 02:09 resolution time matters: block production had resumed roughly 40 minutes before operators closed the incident. Restoration therefore happened in stages, with the protocol restarting before the incident was formally declared over.
The restart also exposed a practical governance reality. Solana was designed as a distributed network, yet recovery from this failure required validator operators to align on restart instructions and a known stable software path. That coordination restored service, but it also made operational resilience and upgrade discipline central institutional questions for applications, traders and infrastructure providers depending on the chain.
What was known on February 26
The verified event-day record established that economic activity stopped in vote-only mode, validators undertook a coordinated restart, block production resumed and monitoring ended with a resolved status. It did not establish a final root cause.
The proximity of the failure to the 1.13-to-1.14 upgrade created an obvious line of inquiry, and the status notice itself connected the restart effort to an issue during that upgrade. But correlation was not proof that the new release alone caused the incident. A defensible February 26 account therefore stops short of assigning a software defect, hostile attack or validator fault.
The later Solana Foundation report said normal finalization times and transaction throughput returned around 01:28 UTC and that no finalized transactions of economic value were rolled back. The February 26 status record did not supply transaction totals, user-loss figures or a comprehensive audit of application-level effects, so those cannot be inferred from the restart notice.
Why the interruption mattered
Availability is part of a blockchain’s core product. Smart-contract applications can keep their code and balances intact while still becoming unusable when the underlying chain cannot finalize ordinary transactions. Nearly 20 hours without economic transaction processing therefore tested more than Solana’s headline throughput: it tested whether the network and its validator community could recover predictably under stress.
No SOL price or percentage-return claim is necessary to establish that significance. Crypto trades continuously across venues, and a token move during the incident would not by itself prove the network failure caused it.
Later technical context
In a root-cause report published on April 18, 2023, the Solana Foundation attributed the degradation to abnormal traffic involving custom block-forwarding services. The report said looping data overwhelmed deduplication logic and congested Turbine, the network’s main block-propagation protocol. It described fixes in validator clients 1.13.7 and 1.14.17. That later diagnosis clarifies the incident but was not available when the cluster returned on February 26.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.