Injective completes Safeharbor upgrade without publishing source code

Injective completed a coordinated mainnet upgrade to version v1.20.4-safeharbor.5 on November 11, replacing an emergency binary installed two days earlier. The change required the chain to halt at block 191,270,000 while validators installed the new software.

QuickNode marked its associated maintenance complete at 14:00 UTC, two hours after the provider’s scheduled window began. Injective’s release identifies the binary and build label but publishes neither its source code nor a functional changelog, limiting independent assessment of what changed.

Mainnet stopped at a predetermined block

Injective’s operator instructions scheduled the upgrade for approximately 12:30 UTC on November 11, subject to expedited governance proposal 714 passing. Validators were directed to let their nodes stop at block 191,270,000, preserve their configurations and signing state, install the new binary and then restart.

The instructions applied not only to validators but also to sentry and RPC nodes and infrastructure supporting exchanges, custodians, indexers and relayers. Those systems need compatible software because they read, submit or relay transactions against the same consensus network.

QuickNode recorded the maintenance as in progress at 12:00 UTC and complete at 14:00 UTC. That establishes the provider’s maintenance window and service status; it does not measure how quickly every validator, exchange or independent node upgraded. No reviewed source supplied a validator-adoption count or network-wide service assessment for the period after activation.

Release identifies binaries but not code changes

The Injective Foundation’s GitHub release was published at 18:46 UTC on November 10. It identifies v1.20.4-safeharbor.5 for both the `injectived` node and `peggo` bridge software, with the build label `d37e7f0`. The release says the two binaries were compiled on November 10 using Go 1.26.8 and provides downloadable archives for two processor architectures.

The page also states that source code has not been published for releases since September 9. Although the page displays a short build identifier, it does not link that identifier to a publicly inspectable source commit or diff for this version. It provides a checksum for a bundled runtime library, which can help operators verify that they downloaded the expected file, but a matching checksum does not independently establish what the binary does.

Injective describes the operation as an “enhancement upgrade.” The operator guide contains installation, compatibility and recovery procedures but does not enumerate functional changes, corrected defects or security properties. QuickNode’s description refers broadly to infrastructure, validator coordination and operational efficiency; it supplies no tests or measurements supporting those characterizations.

Rollback planning points to the operational risk

Before installing the new version, validators were told to preserve `priv_validator_state.json`, a file that tracks consensus-signing state. Restoring an inconsistent copy can cause a validator to sign conflicting blocks, so the guide treats that backup as a protection against double-signing during recovery.

If the upgrade failed, operators were instructed to restore a pre-upgrade snapshot, return to v1.20.4-bl.3 and continue the earlier chain until further notice. That predecessor was released November 9 and served as the required starting version for the November 11 change.

QuickNode separately recorded a chain-wide upgrade exercise beginning November 9 at 13:52 UTC and marked it resolved November 10 at 02:53 UTC. Its notice warned that block production could pause or slow and endpoints could return stale data, but it did not report the actual duration of any production gap. The record therefore does not support converting that incident window into a downtime measurement.

What remains undisclosed

The available records establish the activation block, binary identity, operator procedure and QuickNode’s completed maintenance window. They do not disclose the release’s source, a code-level change list, an external audit, post-activation performance data or the proportion of voting power running the new binary.

Those omissions do not show that the upgrade malfunctioned. They mean its technical effects and security properties cannot be independently evaluated from the published materials alone. The next useful records would be a public changelog, reproducible source, audit report, validator-adoption measurement or incident disclosure tied specifically to the Safeharbor release.