Skip to content
Data provided by CoinGecko
Ethereum News

Besu 26.11.0 is a node patch, not a mainnet fork

Comic gold coin mascot beside crystal nodes and a blank server

Besu 26.11.0 is an Ethereum execution-client patch, not a mainnet fork. Hyperledger Besu (now published from the besu-eth/besu GitHub repo) tagged 26.11.0 on 2 November 2026 at 10:46 UTC. The notes change RPC behaviour, bound DiscV5 discovery memory, and upgrade Vert.x from 5.1.6 to 5.2.2. They do not set an Amsterdam or Glamsterdam clock on Ethereum mainnet.

That is the whole claim. If you run Besu, read the breaking RPC list before you roll the binary. If you only watch ether candles, this tag is not a new range break.

Ether is still the tape around the software. Our CoinGecko snapshot at has ETH at $2,423.15, up 6.54% over 24 hours, with Bitcoin at $80,499 (up 4.00%) and Solana at $95.52 (up 2.88%). Global crypto market cap sits near $2.71 trillion, with Bitcoin dominance near 59.56%. A green day does not turn a client tag into a fork.

What happened

The 26.11.0 notes open with three breaking changes. eth_getProof now follows execution-apis rules on leading zeros and error codes. engine_getPayload no longer waits for an in-progress block build when only the empty block has been built, matching execution-apis pull 958, which dropped the one-second getPayload timeout and requires an immediate response. Besu also changes the default of --Xpos-block-finalization-timeout-ms from 800 to 0, and the flag now accepts 0. Set a positive value if you want the old wait. eth_simulateV1 now rejects unknown account overrides.

The security-relevant lines sit lower in the same notes. Discovery no longer buffers unbounded memory for inbound DiscV5 packets: over-sized datagrams are dropped before they are copied for dispatch, and the dispatch queue is bounded. Vert.x moves from 5.1.6 to 5.2.2, which the notes say fixes October 2026 Vert.x advisories, including HTTP/1.x request smuggling through canonicalized headers, unbounded allocation for compressed WebSocket frames, and an incomplete HTTP client SSL context cache key. The notes do not attach a CVE or GHSA id to those Vert.x items. I will not invent one.

Other shipped mechanics matter for operators, not for a price thesis. engine_newPayload replies before it stores a valid block and its trie log. Block import preloads and commits only the state a block changes. --sync-mode=SNAP2 downloads the chain and the state together, with the state following the chain head through block access lists. Native secp256k1 ECDH for RLPx and DiscV5 via besu-native 2.1.0 is billed as cutting about 2 MB of allocation per agreement. QBFT validators can import a committed block without executing it again when they created it or validated it as a proposal. That last line is a permissioned-network path. It is not evidence that Ethereum mainnet block production got faster.

Amsterdam appears once, as genesis support on Ephemery, aligned with Ephemery iteration 165. That is a test network fixture. It is not the Hoodi postponement story, and it is not mainnet.

Context

Ethereum still runs on client diversity. Besu is one execution client among several. A Besu tag does not move Geth, Nethermind, or Reth. It also does not rewrite the Ethereum Foundation note from 22 October 2026 that postponed Glamsterdam on Hoodi. We already treated the Geth side of that delay as a testnet clock, not a mainnet fire, in Geth v1.17.10: Hoodi Amsterdam is off, not mainnet. 26.11.0 sits in a quieter bucket: RPC alignment, discovery bounds, and a dependency bump.

Fees are the usage print I actually watch. DefiLlama Ethereum fee overview, read at , shows about $9,710,385 in fees over the prior 24 hours, down 1.17% versus the previous day, with a 7-day total near $159.9 million. The same Llama chains table at that read puts Ethereum TVL near $45.96 billion. Those numbers describe a live fee market. They do not prove that operators have rolled 26.11.0, and they do not tell you the share of Besu nodes on mainnet. Show me the fee, not the roadmap, and show me the release notes, not a fork rumour.

RPC breaks are where this tag can bite. Indexers, wallets, and layer-2 stacks that call eth_getProof or engine_getPayload against Besu need the new error shapes and the new getPayload timing. A node that still waited 800 ms on an empty payload is now told to answer immediately. That is a spec cleanup. It is also a footgun if your tooling assumed the old pause. Private QBFT operators get a different gift: one less execution on the proposal path. Public Ethereum validators on proof of stake should not read that as a mainnet speed-up.

Price context still belongs on the Ethereum history page and in a market snapshot, not in a client changelog. ETH can rally 6% while operators argue about DiscV5 queues. Those are different clocks. Ethereum news this week has been loud on other names. This one is quieter, and that is the point.

Our read

I read 26.11.0 as a maintain-the-node tag. The honest centre of gravity is Vert.x 5.2.2 plus a bounded DiscV5 inbound path, with RPC behaviour moved onto execution-apis. The Ephemery Amsterdam line is a test genesis switch. The QBFT skip-reexec line is for permissioned validators. Neither is a mainnet fork print.

Falsifiable claim: by 2026-11-19 23:59 UTC, the Besu 26.11.0 GitHub notes or a follow-up official Besu tag will schedule Amsterdam or Glamsterdam on Ethereum mainnet, or the 26.11.0 notes will retract the Vert.x 5.1.6-to-5.2.2 upgrade (#11770) or the DiscV5 inbound memory bound (#11672). If neither happens, this stays an operator and RPC patch, not a mainnet fork clock.

What to watch next

First, Besu operators should confirm 26.11.0 (or a later patch) is the binary on any node that exposes JSON-RPC or WebSocket to a network they do not fully trust, because the Vert.x bump is aimed at request smuggling and WebSocket allocation bugs. Second, watch eth_getProof and engine_getPayload callers for new error codes and faster empty-payload replies after the timeout default went to 0. Third, ignore Ephemery genesis notes unless you actually run Ephemery. Fourth, keep Hoodi and mainnet fork dates on the client that states them, not on this tag.

If a later Besu note names a mainnet timestamp, that is a new story. 26.11.0, as shipped on 2 November 2026 at 10:46 UTC, is not that story.