Nethermind 1.36.1 Shows How Upgrade Timelines Turn Real

Nethermind 1.36.1 release was not a broad all-network execution-client refresh. It was a narrow patch tagged on March 6, 2026 for Chiado testnet operators on Gnosis Chain, ten days ahead of the Osaka fork activation scheduled for March 16. That is exactly why it matters: upgrade timelines stop being roadmap talk when they become signed client tags.

Nethermind 1.36.1 release notes

Nethermind 1.36.1 shipped one targeted change, and that is the real signal

The 1.36.1 release artifact is unusually clear about scope. It says the release is “only required for Chiado testnet (Gnosis Chain) node operators” and that “all other networks are unaffected.” The overview says the patch “enables the Osaka hard fork on the Chiado testnet,” with activation set for slot 21,651,456 at timestamp 1773653580, which the release maps to March 16, 2026 at 09:33:00 UTC. The changelog itself contains one substantive item: “Enable Osaka on Chiado.” That is not a generic client refresh; it is a chain-specific activation release.

Nethermind 1.36.1 release notes

That precision is the story. Client teams do not make upgrades real by publishing broad roadmap posts. They do it by pinning fork logic to a release that operators can actually install and test against a live network. Nethermind’s next release makes that pipeline visible. Version 1.36.2, published on March 25, says it is only required for Gnosis Chain node operators and enables the Osaka hard fork on Gnosis mainnet, with activation scheduled for April 14, 2026. Read together, 1.36.1 and 1.36.2 show the operational sequence builders care about: testnet activation first, then mainnet activation in a separate tagged release with explicit timing.

Nethermind 1.36.2 release notes

Upgrade readiness becomes real when client tags front-run network events

The clearest way to understand 1.36.1 is as a release-discipline marker. Nethermind tagged it on March 6 for a March 16 Chiado activation. That lead time is the part operators, RPC providers, and testnet-dependent builders should watch. It gives client users a bounded window to stage binaries, replay test cases, and catch network-specific issues before the fork actually lands. This is also how multi-network execution clients reduce upgrade risk: they move the “are we ready?” question from abstract discussion into a versioned artifact with a date attached.

Nethermind 1.36.1 release notes

Nethermind 1.36.2 release notes

release notes" → https://github.com/NethermindEth/nethermind/releases/tag/1.36.2]

This is not new behavior for Nethermind. The same releases page shows version 1.35.2 as a mandatory upgrade for all node operators ahead of Ethereum Mainnet Fusaka, with the release explicitly tied to a December 3, 2025 activation time. In other words, Nethermind’s release train has already been doing this work across networks: a tag is where chain configuration, fork scheduling, and operator action finally line up. That matters for builders because their own release windows often depend on when a client tag moves from “available” to “required.”

Nethermind 1.35.2 release notes

The broad RPC and correctness hardening lives beside 1.36.1, not inside it

The project brief framed 1.36.1 as a bundle of client functionality and developer-facing fixes. The release artifact does not support that reading. The broad execution, RPC, and operator hardening sits in adjacent versions. Nethermind 1.36.0, published January 13, says it brought “over 416 improvements across 1821 files,” focused on operator ergonomics, RPC and execution correctness hardening, and performance. Its highlights include .NET 10 migration, a safer database-corruption exit path, eth_estimateGas compatibility adjustments, chain ID injection for legacy transactions derived from signatures, better eth_getFilterChanges error messaging, and changes to blob handling and execution-reverted behavior. That is the release where a builder would look for broad execution-client surface changes.

Nethermind 1.36.0 release notes

The same pattern continues on the forward side. The 1.37.0-alpha pre-release drops deprecated eth/66 and eth/67 in favor of eth/69 by default, adds engine_getBlobsV3, adapts engine_getPayloadV4 for Optimism, hardens RPC transaction validation, enforces canonical block retrieval for eth_getBlockByNumber, and improves eth_getLogs performance. Those are concrete signals about where Nethermind is spending execution-client effort. Read in context, 1.36.1 is not the main technical payload. It is the release-management hinge that takes fork logic from codebase to operator action.

Nethermind 1.37.0-alpha release notes

Web3 Builder coverage→ /categories/web3-builder

Builders should treat Nethermind releases as network-specific operational inputs

For node operators on Chiado in early March, the action was straightforward: upgrade to 1.36.1 if you needed to test Osaka fork behavior before Gnosis mainnet activation. For almost everyone else, the important sentence in the release was the one saying no action was required. That distinction matters because multi-network clients can look like one continuous release stream while still carrying sharply different implications by chain. A service team running Nethermind against Ethereum mainnet, Base, or Linea should not read every patch tag as a universal upgrade alarm. A team with Gnosis or Chiado exposure should.

Nethermind 1.36.1 release notes

That reading also fits Nethermind’s own project positioning. The repository README describes Nethermind as a high-performance Ethereum execution client built on .NET, in production since 2017, with support for Ethereum, Gnosis, Optimism, Base, Taiko, World Chain, Linea, and Energy Web. It emphasizes fast sync, high-throughput JSON-RPC, and a plugin system that lets the same core client support multiple networks and custom namespaces. That breadth is useful for operators, but it raises the value of exact release notes. In a multi-network client, the release title alone is not the operational truth; the network applicability line is.

Nethermind repository

execution client upgrade playbook→ /news/execution-client-upgrade-playbook

Release cadence is itself a builder metric, even when 1.36.1 is narrow

Nethermind’s repository page gives a sense of the engineering base behind these targeted releases. At the time of reporting, the repo shows about 1.5 thousand stars, 669 forks, 355 releases, and 10,258 commits. The 1.36.1 tag is shown as a verified signed commit, and 1.36.2 adds explicit OpenPGP package-signing information in the release notes. That does not tell us what percentage of any network actually adopted 1.36.1, and Nethermind does not publish a node-share metric for this specific release. It does tell us that release discipline is part of the client’s operator story, and that small chain-specific tags are backed by a long-running shipping pipeline rather than ad hoc patching.

Nethermind repository

Nethermind 1.36.2 release notes

That is the right way to read 1.36.1. It is not a giant feature release, and pretending otherwise would miss the real builder signal. When a client team can cut a narrow tag for a specific testnet fork, then follow it with a mainnet tag on the same path, upgrade readiness is no longer a slide-deck concept. It is a version number, a binary, and a deadline.

Gnosis infrastructure coverage→ /news/gnosis-chain-infrastructure

The next thing to watch is not whether 1.36.1 was “big enough.” It is whether Nethermind keeps using narrow, explicit release tags to front-run network activations and whether the broader RPC and correctness work in 1.36.0 and 1.37.x continues to land without turning chain-specific upgrades into operator confusion.