Solana Restarted Mainnet Beta After a Four-and-a-Half-Hour Halt

Solana’s Mainnet Beta stopped producing blocks on June 1, 2022, after validators could not agree on whether to accept a block containing a reprocessed durable-nonce transaction. Validator operators coordinated a cluster restart and restored block production at 21:00 UTC, ending an outage the Solana Foundation later measured at roughly four and a half hours.

The halt mattered beyond a temporary interruption. Solana was presenting itself as a high-throughput base layer for exchanges, wallets, decentralized-finance applications and non-fungible-token markets. For that system, liveness was part of the product: without new blocks, users could not obtain final settlement on-chain. The restart also required human coordination among validators and a software upgrade, making operational resilience—not transaction speed—the immediate test.

What participants knew on June 1

Solana Status reported during the incident that block production had halted and told validator operators to prepare for a restart. Same-day reporting tracked the recovery effort and attributed the fault to the durable-nonce feature. By about 21:00 UTC, validators had restarted the cluster with durable-nonce transactions disabled. Some remote-procedure-call infrastructure and client services were still returning afterward, so resumed block production did not mean every user-facing service recovered at the same instant.

Contemporaneous reports also said several exchanges were experiencing problems with Solana deposits and withdrawals. That is consistent with a chain that was not finalizing blocks, but it does not establish that every venue used durable nonces or that every reported exchange interruption lasted for the full network outage.

Durable nonces served a narrow but institutionally useful purpose. A normal Solana transaction depended on a recent blockhash and therefore expired quickly. A durable nonce allowed a transaction to be signed in advance and submitted later, which could accommodate offline or multi-step custody processes. Disabling the feature helped restore the network, but it temporarily removed that workflow for users relying on it.

How the consensus failure developed

The detailed mechanism was not fully documented on June 1. The Solana Foundation’s June 4 postmortem said the triggering transaction first failed while its blockhash was still recent enough to be handled like a normal transaction. Because it was not treated as a durable-nonce transaction, the on-chain nonce value did not advance. The same failed transaction could then be submitted again.

Validators diverged when the second instance appeared: some accepted the resulting block while others rejected it based on their record of the earlier transaction. The postmortem said more than 33% accepted the block, but fewer than the 66% needed to reconcile the disagreement. Consensus stalled and block production stopped.

The Foundation said normal transactions accounted for more than 99.99% of Solana transactions, underscoring that a low-volume feature could still create a network-wide failure. Releases v1.9.28 and v1.10.23 disabled durable nonces as the immediate mitigation.

What the event established

The narrow conclusion available from June 1 is operational: Solana recovered through a validator-coordinated restart after a consensus bug halted the entire cluster. The event did not, by itself, prove that user funds were lost, nor did the cited incident records quantify failed transactions or economic damage.

Later technical context

A Solana Labs repository issue opened June 5 proposed separating durable-nonce values from ordinary blockhashes, rejecting legacy nonce formats and requiring nonce state to advance so failed transactions could not be replayed. That later engineering record clarifies the remediation path; it should not be read as information available during the first hours of the June 1 outage.