Nethermind tagged execution-client 2.0.0 at 2026-09-22T14:58:58Z. It is a production GitHub release, not a release candidate, and it is not an Ethereum hard fork. Ether still trades as the same asset. The CoinGecko snapshot on this site at 2026-09-23T00:06:39+00:00 printed ETH at $2,753.01 (−0.69% over 24 hours) and Bitcoin at $86,222.
The notes are blunt about who this actually hits. Most 1.39.x full nodes upgrade in place with no resync. Archive operators, anyone with old boolean config keys, and plugin authors can fail on start or keep a stale database. Show me the shipped client, not a fork calendar.
What happened
Nethermind 2.0.0 consolidates the 2.0.0-rc and 2.0.0-rc2 trains. The project counts 669 merged pull requests since 1.39.3, from 39 contributors. The headline mechanical change is the default state backend. FlatDb.Enabled now defaults to true for a new node or a resync. An existing patricia database is detected at start and stays patricia. Upgrading a running 1.39.x full node does not migrate that database and does not force a resync.
That split matters more than the major version number. A validator that has been online through 1.39.x is not being asked to rebuild Ethereum history tonight. A fresh disk, or an archive operator who wants the new layout, is.
The fee tape around the tag is quiet, not empty. A DefiLlama Ethereum-chain fees pull at 2026-09-23T00:23Z showed about $12.71 million in 24-hour protocol fees on Ethereum. The same payload’s daily series last printed about $11.00 million for the 2026-09-22 UTC day. A companion chains TVL reading at the same timestamp put Ethereum near $54.43 billion. Those are usage prints, not a reason the client shipped.
Nethermind also published a Sepolia Glamsterdam table in the same notes: epoch 353024, start slot 11296768, Unix 1791294816, which is 2026-10-06T13:53:36Z. Hoodi and mainnet timings are still marked TBD. The tag says you can already point a node at the temporary Plataberget testnet with --config plataberget. That is client readiness, not a mainnet fork date.
Context
Ethereum’s execution layer is the software that stores accounts, runs gas-metered calls, and talks to a consensus client. Nethermind is one of those execution clients. A 2.0.0 tag is an operator event. It is not a protocol vote and it is not a new ethereum history chapter by itself. If you want the fork-shaped test, we already covered Plataberget as a Glamsterdam break test, not as a live L1 halt.
The new archive story is the part that will get oversold. 2.0.0 puts archive-grade history on the flat state database. There is no separate archive database and no new peer protocol. History is built by ordinary syncing. Reads below the retained floor fail closed instead of answering from live state. Nethermind measured a full Ethereum mainnet archive at about 2.1 TB of execution database (about 2.3 TB total node disk) on live nodes around block 25.88 million as of 2026-09-01. A windowed setup that keeps about two months of state and about a year of blocks printed about 0.9 TB of execution database. Those are vendor measurements, dated, and they grow as the chain grows.
Performance claims are dated and bounded. A 12-hour mainnet measurement across six fully synced nodes found the flat layout fastest at chain tip against a 1.39.2 half-path baseline: 1.80× throughput on 8 vCPU machines and 2.55× on 16 vCPU machines, with zero bad blocks in that window. The catch is initial sync. Flat took 192.0 minutes on the standard tier and 128.6 minutes on the premium tier, about 75% longer than the same-tier 1.39.2 half-path baseline. Faster tip, slower first sync.
RPC users get a smaller, checkable delta. Across completed benchmark cells, 2.0.0 answered an internal 497-record eth_call corpus 15–27% faster than 1.39.3, with byte-identical responses on all 497 records.
Then the breaking list, which is why this is not a quiet patch. Db.FlushOnExit is now an enum. Old true/false values fail to start. Negative numeric config is rejected; the old Receipt.TxLookupLimit: -1 sentinel has to become 18446744073709551615. Receipt.MaxBlockDepth defaults to 1000 instead of 10000, so a wide eth_getLogs can start failing unless you raise the cap or enable the log index. Archive configs enable the flat backend with history, but an existing patricia archive keeps working until you resync or import. Plugin authors have to recompile because many IConfig numeric properties moved to unsigned types. JSON-RPC names moved too: trace_simulateV1 renamed stateChanges to stateDiff, and eth_maxPriorityFeePerGas now returns a priority fee instead of a gas price.
Known issues sit on the new flat backend only. A node upgraded in place from 1.39.x keeps patricia and is not exposed to them. On a new flat database, snap sync cannot resume across a restart, copy-style full pruning does not actually prune, and a RocksDB auto-repair of a corrupted flat DB can drop leaves. The notes say if RocksDB reports a repair, resync rather than continue.
Fork-gated work is in the binary and still gated. EIP-7805 (FOCIL) inclusion lists and a sparse blob pool with eth/72 cell-level exchange are implemented and activate with their forks. Amsterdam-gated RPC error behavior is called out as not active on mainnet yet. Optimism chainspecs were refreshed. None of that ships a mainnet schedule.
Our read
I treat 2.0.0 as a client-operations release. The useful claim is smaller than the major version: Nethermind is telling 1.39.x full-node operators they can stop, audit a short config list, and start again on the same disk. It is also telling archive and integrator teams that 2.0 is where silent config and RPC assumptions break. That is the opposite of a fork headline, and it is the opposite of a roadmap blog with no binary.
The fee and TVL prints above are context for why operators should not shrug. Ethereum is still the chain where Lido, Aave, and the rest of DeFi book real fees. A client that changes log-query depth and priority-fee RPC shape will show up in bots and indexers before it shows up in a candle. If you only watch ethereum news for price, you will miss the class of outage that starts with “the node would not start after the config parser changed.”
Falsifiable claim: By 2026-10-15 23:59 UTC, the GitHub 2.0.0 tag is still the latest non-prerelease Nethermind release (or a 2.0.x patch that keeps the same upgrade story), and the published notes still say most 1.39.x full nodes upgrade in place with no resync. If Nethermind yanks 2.0.0, marks it pre-release, or states that ordinary full-node upgrades now require a resync, this read is wrong.
What to watch next
First, watch start-up logs, not social screenshots. The upgrade checklist is stop the node, fix Db.FlushOnExit and any negative numeric keys, rename Blocks.PreWarmStateOnBlockProcessing to Blocks.PreWarming, then confirm 2.0.0 in the log. A crash on a boolean flush key is the release working as documented.
Second, watch archive and indexer behavior. If a shop needs historical eth_getProof, that path is off by default and only claimed for an unwindowed flat archive. Wide eth_getLogs should be tested against the new 1000-block default before someone pages a “chain is down” incident that is really a receipt-depth reject.
Third, watch Sepolia on 2026-10-06T13:53:36Z. If Nethermind or the Ethereum Foundation publishes a delay or a different epoch for that Glamsterdam Sepolia slot, the table in the 2.0.0 notes is stale. Mainnet and Hoodi remaining TBD is the honest part of the post. Do not fill that blank with a date.
Fourth, keep a market snapshot next to the node metrics. Ether at $2,753.01 on 2026-09-23T00:06:39+00:00 is not a verdict on 2.0.0. A client upgrade can be correct while the tape is dull. The tell is whether 1.39.x full nodes actually come back without a resync, and whether the first flat-from-scratch operators hit the documented snap-restart trap.