Reth v2.11.0 Caps Unbounded RPC Calls, Hardens Node Against Overload

Paradigm's engineering team shipped reth v2.11.0 on November 11, 2026, a release the project's own changelog describes as a hardening and performance update that caps or makes cancellable a set of RPC calls capable of unbounded work, including eth_callMany, trace_callMany, debug_traceCallMany, eth_getProof, mev_simBundle, and eth_simulateV1.

What changed inside Reth's RPC layer

Reth is the Rust-based Ethereum execution client built by Paradigm, one of several clients node operators run alongside Geth, Nethermind, and Besu to process transactions, execute smart contracts, and maintain state for the Ethereum network. These clients sit at the base of the network's infrastructure, so correctness and resource-handling bugs in them carry outsized consequences for validators and RPC providers running public endpoints.

According to the v2.11.0 release notes published on GitHub, the update addresses RPC methods that previously had no bound on how much computational work a single request could trigger. Calls like eth_callMany and trace_callMany allow a client to batch many simulated contract executions into one request; without a cap, a single malformed or adversarial request could consume disproportionate node resources. The release notes state these methods are now capped or cancellable, alongside eth_getProof, mev_simBundle, and eth_simulateV1. The same release also ships what the changelog calls "a broad set of transaction pool, P2P and storage correctness fixes," parallelizes EIP-7702 authorization recovery, and changes peer-to-peer behavior so the node no longer decodes responses to requests it never issued. The notes additionally describe cheaper overlay provider setup, a storage-layer optimization.

Separately, the Optimism-maintained fork of the client, op-reth v2.8.2, shipped on November 10, 2026 — one day before the upstream reth release. Its release notes direct "all op-reth operators" to upgrade, describing a fix to a metrics gauge in the interop transaction pool: the optimism_transaction_pool.interop.endpoint.up gauge had been dropping to zero during normal operation whenever an interop filter answered with an out-of-scope response code, even though that response is expected behavior for a healthy filter processing messages newer than what it had ingested or cross-validated. The op-reth notes frame this as a monitoring fix rather than a functional defect in transaction processing itself.

Why node-level hardening matters beyond this release

Neither release notes a specific incident that prompted the RPC caps, and the reth changelog does not attribute the change to an observed outage or exploit attempt. The hardening is presented as a proactive measure rather than a response to a named event. For operators running public RPC endpoints or validator infrastructure, the practical takeaway from the release notes themselves is straightforward: upgrading closes a class of resource-exhaustion risk tied to specific named methods, and Optimism's guidance is explicit that op-reth operators should move to v2.8.2 for the metrics fix regardless of whether they have observed the gauge issue locally. CoinsCipher will note any disclosed incident tied to these RPC methods if one surfaces in either project's future advisories.