Ethereum execution client Besu has released version 26.6.0, a recommended update that raises the client’s runtime baseline and introduces stricter RPC parameter handling. The official release notes state that Besu now requires Java 25 or higher to build and run, making the upgrade immediately relevant for operators planning to deploy the new binary.
The impact is not limited to a single Ethereum network setting. The practical upgrade burden falls on Besu node operators, infrastructure providers, RPC service teams and private or Ethereum-compatible network operators whose deployments depend on Besu’s Java runtime environment or expose Besu RPC endpoints to external tooling.
RPC Compatibility Brings Stricter Input Rules
The clearest change is in RPC compatibility. Besu 26.6.0 now requires block number parameters in RPC calls to use hex values, while non-hex decimal block numbers are rejected. The affected methods include eth_estimateGas, eth_getBlockByNumber, eth_feeHistory, eth_getProof, trace_call, debug_traceCall and several other admin, trace, debug and Ethereum RPC endpoints, according to the release notes. That turns a previously tolerated parameter format into a rejected input path.
Hash parameters are also stricter. The release notes say hash values must now be hex values, and hashes without a 0x prefix are rejected with -32602 INVALID_PARAMS. The documented affected methods include debug_getRawTransaction, eth_getTransactionByHash and eth_getTransactionReceipt, making RPC client formatting a direct compatibility concern for wallets, middleware, indexers and monitoring stacks.
The release also documents targeted fixes beyond basic parameter formatting. Besu corrected an off-by-one validation issue in debug_accountAt, adjusted debug_trace* storage output to match the execution APIs specification and Geth behavior, and updated several Engine API error responses. These are specific RPC and API behavior changes, not a blanket claim that every integration will see broader stability gains.
Performance Note Stays Narrow
Besu 26.6.0 includes one clearly labeled performance item: parallelized block body lookups in engine_getPayloadBodiesByHashV1, engine_getPayloadBodiesByHashV2, engine_getPayloadBodiesByRangeV1 and engine_getPayloadBodiesByRangeV2, intended to reduce latency when fetching up to 1024 block bodies from RocksDB. That is the documented performance improvement, separate from routine dependency updates, cleanup work and maintenance fixes.
Other changes are better framed as maintenance or bug fixes. The notes include fixes tied to transaction pool save and restore behavior, high-concurrency address hash handling, payload validation, blob transaction sidecar validation and disk-full shutdown behavior. These items may matter operationally, but the release notes do not justify describing the update as a general stability overhaul without qualification.
For operators, the immediate checklist is straightforward: verify the local Java version before upgrading, review RPC clients for decimal block numbers or hashes without 0x, and test affected debug, trace and Ethereum RPC workflows before production deployment. The release is live through the official Besu GitHub repository, and the safest editorial framing is a Java baseline and RPC compatibility release with selected documented performance work, not a broad performance or stability claim.