
Shardeum says its v1.1.0 mainnet upgrade completed on Oct. 13 after Governance Proposal #1 passed, and that block production resumed once sufficient validator voting power came online. The project describes the network as operating normally following the coordinated transition to Cosmos EVM v0.6.3 at block 7,927,860.
The Oct. 13 completion notice replaces the conditional status in Shardeum’s earlier upgrade plan. Its current validator guide also says the upgrade succeeded and operations resumed, and directs operators to use v1.1.0. Those are project-issued statements; exchange and application availability still require service-specific confirmation.
The reported migration has moved beyond its target height
Shardeum reports that the upgrade completed at the height specified in its earlier Oct. 6 announcement. The validator guide now gives operators a current version to use rather than the earlier instruction to remain on the old release until the upgrade.
A read-only check of the project’s published mainnet JSON-RPC endpoint at about 13:18 UTC on Oct. 14 returned a latest block of 7,947,354, above the upgrade target. The endpoint also returned block 7,927,860 and its child, 7,927,861, with the child’s parent hash matching the target block’s hash. This corroborates progression beyond the announced upgrade height at the capture time.
That observation comes from one endpoint. It does not establish that every validator, RPC provider, exchange or application was healthy at the same time, nor does it independently measure the service interruption.
The reported restart clock has a discrepancy
Shardeum places activation and resumption at approximately 06:40 UTC on Oct. 13 and estimates roughly 25 minutes of planned interruption. It supplies no exact halt-start or service-restoration timestamps, so those figures remain attributed estimates rather than independently verified outage timing.
The RPC endpoint returned a timestamp of 06:07:59 UTC on Oct. 13 for the target block and 06:08:04 UTC for its child. The target’s header is about 32 minutes earlier than the project’s approximate 06:40 report. A block-header timestamp has not been established here as the real-world halt or restart clock, and this single endpoint cannot resolve the mismatch.
Users still need exchange and application notices
The completed chain upgrade does not confirm that an individual exchange has reopened SHM deposits or withdrawals. No exchange-specific suspension or restart notice was verified for this update. Users should check their service’s own notice before treating the project’s network-resumption statement as confirmation of customer access.
Application-level availability is likewise unconfirmed. The next useful evidence would be exchange and application status notices, broader corroboration of network operation, and an official clarification of the timing discrepancy. The verified endpoint progress and the project’s completion report resolve the earlier conditional upgrade status while leaving those service and clock boundaries open.
Investment disclaimer: This article is provided for general information only and does not constitute investment, financial, legal or tax advice. Digital assets are volatile, and all investment decisions and their consequences are your own responsibility.