0x35c2aa5e35c2…35c2aa61
Osmosis Restores Block Production After Nearly Four-Hour Halt
Osmosis resumed block production at 5:53 a.m. ET Friday after a near four-hour halt. No funds were lost and no blocks were rolled back, but Go 1.23 nodes may remain stuck.

Outputs
Osmosis resumed block production at 5:53 a.m. ET Friday (10:53 UTC) after a halt of nearly four hours.
The network reported no loss of funds and no rollback of blocks.
Nodes built with Go 1.23 may remain stuck at block height 74,955,152, including released Docker images.
Operators were told to use the v32.0.0 binary or rebuild with Go 1.26.10, run osmosisd rollback once, and restart.
Osmosis, the Cosmos-based decentralized exchange, resumed block production at 5:53 a.m. ET Friday (10:53 UTC), ending a network halt that lasted nearly four hours. The protocol reported no loss of user funds and no rollback of blocks during the interruption.
The network described itself as operating normally once production restarted. That claim, notably, addresses the ledger itself rather than every participant's infrastructure. The distinction matters for operators who have not yet verified their node state.
In plain terms: the chain continued from where it stopped, and no transaction history was rewritten. Four hours of downtime is significant for an automated exchange, but the absence of a rollback means settlement integrity held.
Which nodes are still affected?
The recovery advisory centers on node software rather than the chain. Systems built with Go 1.23 may remain stuck at block height 74,955,152. Osmosis included released Docker images built with that Go version among the affected setups.
That means an operator can follow all published guidance and still host a stalled validator or RPC endpoint. The advisory identifies Go 1.23 as the problematic toolchain version and Go 1.26.10 as the recommended replacement for rebuilds.
What is the recovery path?
Osmosis instructed affected operators to take three steps:
- Use the official v32.0.0 binary, or rebuild with Go 1.26.10.
- Run
osmosisd rollbackexactly once. - Restart the node.
The single-run instruction on the rollback command deserves attention. Running it multiple times could rewind state further than intended, though Osmosis did not elaborate on the consequence. The guidance is precise, and precision in recovery instructions usually signals a state mismatch that the rollback command corrects only once.
The affected height, 74,955,152, gives operators a concrete checkpoint. A node reporting that number after the restart window is a candidate for the recovery sequence. Nodes reporting later heights presumably synchronized normally, though Osmosis did not state this explicitly.
What was not said?
Osmosis did not disclose the root cause of the halt. The advisory covers recovery, not diagnosis, and no post-mortem timeline accompanied the Friday update. The correlation with Go 1.23 builds suggests a toolchain-level fault, but the protocol has not confirmed a mechanism.
The network also did not quantify how many nodes remain stuck. The Docker-image reference implies the affected population could include operators relying on official release artifacts rather than custom builds. Until Osmosis publishes a fuller accounting, the operational footprint of the incident remains unknown.
For delegators and liquidity providers, the practical takeaway is limited: funds were not lost, and the chain did not reorganize. For validators and infrastructure operators, the work is not necessarily finished. Any operator still sitting at height 74,955,152 should apply the v32.0.0 or Go 1.26.10 path before assuming full participation. A root-cause post-mortem, when it arrives, will determine whether this was an isolated toolchain fault or a versioning practice that needs broader correction.
via tokenpost.com (Source)
More from Elena Vasquez
Show full bio
Staff writer covering regulation, policy and their impact on crypto and web3 industry at Mempool Brief.
1,076 articles