Gonka published the v0.2.13-devshard-v2 upgrade proposal on June 15, 2026. It is the first devshard-only release: the off-chain inference runtime can now be upgraded on its own, separate from a full chain software upgrade. Once an on-chain proposal approves it, the v2 runtime runs in parallel with the existing v1 runtime rather than replacing it.

Devshard is the off-chain layer that coordinates inference work for a group of nodes, keeping per-request settlement off the main chain. Until now, changing it meant shipping a full chain upgrade. This release decouples the two.

What shipped

• A devshard-only upgrade path driven by an on-chain params proposal. The proposal registers a new entry in DevshardEscrowParams.approved_versions with a name (v2), a binary URL, and a sha256 hash. No mainnet restart or manual host steps are expected.
• Parallel runtimes. The v2 process is served under /devshard/v2; existing traffic stays on /devshard/v1 and /v1/devshard. Hosts run both at once.
• Storage pruning and sealing (PR #1305, PR #1328). Devshard now prunes old epoch storage on epoch changes, seals completed inference stats, and removes payloads so long-running sessions stop holding every served inference in RAM or state.
• Governance-controlled escrow parameters. Session timeouts, fees, validation rates, the vote threshold factor, and grace periods moved into DevshardEscrowParams. Sessions snapshot active fees at escrow creation through new create_devshard_fee and fee_per_nonce fields.
• A six-component observability stack (PR #1284). The deploy module adds Grafana, Jaeger, Prometheus, Loki, Promtail, and cAdvisor, plus dashboards for devshard sessions, chain health, query latency, storage, containers, and node health.

Under the hood

The upgrade mechanism is the core change. When the params proposal executes on-chain, versiond reads the new approved_versions entry, downloads the devshardd binary, verifies its sha256 hash, and starts an additional devshardd process inside the container it already runs. The old v1 process keeps serving its prefixes. Because the chain learns about the new binary only through a params vote, hosts do not coordinate a synchronized restart — each versiond picks up the change when it sees the approved entry.

Two correctness changes sit underneath. Devshard inference sealing moved into a deterministic state machine (PR #1328), so completed stats settle the same way on every host. The settlement proto also renamed its version field to state_root_and_protocol_version, separating the runtime version from the state-root protocol version — the runtime can advance to v2 while the protocol version is stamped independently at build time.

The release also hardens long-running sessions. Stale MsgFinishInference transactions are re-gossiped so the sequencer can pick them up from another host's mempool, and hosts enforce the governance-controlled maximum nonce limit to reject invalid requests before settlement.

Impact

For hosts, devshard upgrades stop requiring a full chain release. A params vote is enough, and the new runtime arrives without a mainnet restart — v1 and v2 serve side by side, so a faulty v2 can be left unapproved without touching live v1 traffic. This was tested on a testnet running v0.2.13: after the governance proposal registered v2, inference requests succeeded on both /devshard/v1 and /devshard/v2.

For node operators, the pruning and sealing work bounds memory and state growth on long sessions, and the observability stack turns devshard internals into traces and metrics instead of guesswork.

The decentralized-api and inference-chain changes in this release are backward compatible and wire-compatible respectively; they do not need to be activated before the next mainnet release. The devshard runtime itself activates only when the on-chain params proposal passes.