Skip to content
Data provided by CoinGecko
Crypto News

Lighthouse v8.3.2: Hoodi Gloas is off, not mainnet

Comic illustration of a mittened coin mascot in a crystal beacon city with one dim tower.

Lighthouse v8.3.2 turns Hoodi Gloas off. It is not an Ethereum mainnet fork, and Sigma Prime says mainnet users do not need this tag. The consensus client shipped at 00:41:38 UTC on October 23, 2026. The notes tell every Hoodi operator to be on v8.3.2 before the old clock, 26 October 2026 at 17:42:48 UTC (epoch 132352).

We are updating the view from Lighthouse v8.3.1. That release was a certificate-store patch. It still pointed Hoodi stakers at the Monday fork. This tag supersedes those Hoodi instructions. The Ethereum Foundation already said the testnet upgrade is postponed. The binary now has to match the blog post, or Hoodi splits.

Ether is not the story. The desk snapshot at 2026-10-23T04:05:54+00:00 showed Ethereum (ETH) at $2,406.08, down 1.53% over 24 hours, with Bitcoin (BTC) at $81,750. Coinbase BTC-USD last was $81,696.20 in a session from $80,789.61 to $82,921.93 when we pulled venue stats on 2026-10-23 around 04:11 UTC. The range is intact. The client configs are not.

What happened

Sigma Prime published Lighthouse v8.3.2 (“Rhett Caan”) on GitHub. The summary is short. This release disables the scheduled Gloas fork on Hoodi. All Hoodi users must upgrade to v8.3.2 before 26 October 2026 at 17:42:48 UTC, the previously scheduled activation time (epoch 132352). Staking users must update their beacon node, validator client, and execution client. The notes say this supersedes the Hoodi fork instructions in the v8.3.0 and v8.3.1 release notes. Mainnet users do not need to upgrade. Operators coming from v8.2.x still need the v8.3.0 database-migration notes.

The update-priority table is the tell. For staking users on Hoodi, both the beacon node and the validator client are High. Non-staking Hoodi beacon nodes are also High. Staking and non-staking users on mainnet and other networks are marked Not required. That is the opposite of v8.3.1, which marked every network High because of the eMudhra certificate problem.

The Foundation side landed a day earlier. On October 22, 2026, the Protocol Cluster posted Glamsterdam on Hoodi Postponed. Glamsterdam on Hoodi, previously scheduled for October 26, 2026 at 17:42:48 UTC (epoch 132,352), has been postponed. A new activation date has not been set. Core developers decided on ACDE #248 to delay the upgrade so they can keep looking at how EIP-8037 interacts with mainnet smart contracts. The delay removes the scheduled Amsterdam execution-layer activation and the Gloas consensus-layer activation. It also removes the gas-limit schedule that would have raised Hoodi’s gas limit to 200 million at the same epoch. The post says this rolls back the configuration for a future upgrade. It does not revert Hoodi’s chain history. Mainnet users and ETH holders do not need to do anything because of this update.

When we fetched that Foundation page, the client table already listed Nethermind 2.2.1, Besu 26.10.1, and Lodestar v1.50.1. The Lighthouse and go-ethereum version cells were still blank. That lag is why a Lighthouse tag at 00:41 UTC on October 23 still matters. The blog asked operators not to treat the earlier Hoodi announcement’s version table as proof that those builds include the postponement.

Context

Hoodi is Ethereum’s long-lived staking testnet. Gloas is the consensus-layer half of Glamsterdam. Amsterdam is the execution-layer half. The pair was supposed to light on Hoodi on Monday. We already said that clock was a testnet clock, not a mainnet date. The new fact is simpler: the clock is unplugged in some clients and still armed in others.

Nethermind’s execution client is in the “unplugged” column. Nethermind 2.2.1, tagged at 19:41:22 UTC on October 22, 2026, is a patch on 2.2.0 that removes the Glamsterdam (Amsterdam) fork from Hoodi. The notes warn that a Hoodi node still on 2.2.0 will activate Glamsterdam at Monday 26 Oct 2026, 17:42:48 UTC (timestamp 1793036568) and fork off the network. The consensus client must also be on a release that removes the fork. Hoodi stays on BPO2 with fork hash 0x23aa1351 and no next fork announced. No other network is affected. There are no database-format changes.

go-ethereum is still in the “armed” column unless a newer tag appears. Geth v1.17.9, published 15:08:46 UTC on October 21, 2026, enables the Amsterdam fork on Hoodi at the same timestamp 1793036568. That release was the right build when the fork was still scheduled. It is the wrong build if you leave it running through Monday without a follow-up that strips the timestamp. We are not treating a Geth GitHub page as a third github.com link here. The split is the point: Lighthouse and Nethermind have shipped the disable. Geth v1.17.9, as written, has not.

Fee prints do not argue for rushing a mainnet binary. DefiLlama’s Ethereum fee overview showed about $16.00 million in the last 24 hours as of 2026-10-23T04:12:09Z, up 60.4% versus the prior day and down 4.2% versus a week earlier. Ethereum chain TVL on DefiLlama’s chain list was about $49.70 billion at the same pull. Show me the fee, not the roadmap. The fee is fine. The roadmap on Hoodi is the thing that just moved.

If you are mapping this onto Ethereum’s longer history, keep the line straight. Testnet postponements are how Glamsterdam is supposed to work. They are not a hidden mainnet trigger, and they are not a reason to ignore gas fees on the live chain. For the tape next to the client notes, how to read a crypto market snapshot is the same checklist we use on quiet ETH days. More Hoodi and client notes sit in Ethereum News.

Our read

Treat v8.3.2 as a Hoodi config patch. Do not treat it as a mainnet security event, and do not treat the missing Lighthouse row on the Foundation table as proof that Sigma Prime was late. The Foundation asked teams to ship notes that explicitly confirm the October 26 activation is gone. This tag does that. Updating our view from v8.3.1: the certificate chore and the Hoodi chore are no longer stacked on the same Monday clock. Mainnet Lighthouse users can stay on v8.3.1 for this fork question. Hoodi users cannot.

The risk is a client split, not a price split. If a Hoodi beacon node keeps the old epoch, and its execution client still has timestamp 1793036568, that pair will try to fork at 17:42:48 UTC on October 26 while the postponed config stays on BPO2. That is an operator-inflicted testnet fork. It does not move ETH on mainnet. It does wreck anyone using that node as a dress rehearsal.

I would rather see an extra Lighthouse tag than a blog post that operators only half-apply. v8.4.0-rc.0, tagged October 22, is an experimental builder-bid-streaming build. Do not run it with mainnet validators. Do not confuse it with v8.3.2.

Falsifiable claim: by 17:45 UTC on October 26, 2026, Hoodi will not activate Gloas at epoch 132352 on Lighthouse v8.3.2 beacon nodes, and Sigma Prime will not have amended the v8.3.2 notes to put that epoch back. If v8.3.2 still forks Hoodi at 17:42:48 UTC, or if Sigma Prime republishes the tag as keeping epoch 132352 live, this read is wrong.

What to watch next

First, the Foundation client table. Lighthouse should get a version cell that names v8.3.2. go-ethereum should get a Hoodi tag that removes timestamp 1793036568. Until that Geth cell fills, treat v1.17.9 as the last scheduled-fork build, not the postponement build.

Second, your own Hoodi pair. Beacon node, validator client, and execution client all have to agree. Nethermind 2.2.1 plus Lighthouse v8.3.2 is a matched postpone pair on paper. Nethermind 2.2.0 plus any Lighthouse that still carries epoch 132352 is how you fork yourself.

Third, a replacement Hoodi date. The Foundation said it will announce the reschedule later. There is no new epoch in the updated configuration. Anyone selling a mainnet Glamsterdam date off the old Monday clock is skipping the document.

Fourth, the tape only if it actually breaks. Bitcoin is still inside the Coinbase session band near $80.8k–$82.9k. ETH around $2,406 is not a reason to delay a Hoodi binary. It is also not a reason to “upgrade mainnet just in case.”