The Ethereum Foundation has confirmed that the upcoming Fusaka hard fork will introduce a protocol-level cap on the amount of gas that can be consumed in a single transaction. This is officially codified as EIP-7825. The cap is set at 2²4 gas (16,777,216 units), marking the first time that Ethereum enforces a per-transaction limit that is different from the block gas limit. This change is already in effect on Holesky and Sepolia, and will take effect on mainnet once Fusaka is enabled.
Toni Wahrstätter explained the rationale in direct terms in a post published on October 21st. “Starting with the upcoming Fusaka hard fork, EIP-7825 introduces a per-transaction gas limit cap of 2²⁴ (= 16.78 million gas).” The foundation note emphasizes that this cap restricts individual transactions, but does not change the block gas limit. Instead, it is designed to alleviate the denial-of-service vector of a single oversized call hogging an entire block, and to improve the predictability of block packing as the network prepares for parallel execution.
EIP-7825 draws a clear line between transaction-level complexity and system-level throughput. Previously, very large calls could approach full-block gas targets (sometimes around 45 million calls), creating timing and scheduling issues for builders and validators.
The new cap mandates that workloads exceeding 16.78 million gas be divided into smaller consecutive calls. The Foundation’s guidance notes that “nothing will change for most users” because the statistical distribution of real-world transactions is already well below the threshold. The risk side primarily concerns batch-heavy contracts, deployment scripts, and specialized routers.
What this means for Ethereum and its users
From a roadmap perspective, upper bounds are explicitly positioned as the basis for parallel execution. This blog post connects this change to anticipated efforts such as EIP-7928 from the “Gramsteldam” era. In this day and age, predictable and bounded transactions are a prerequisite for meaningful concurrency in the execution layer. This upper limit reduces worst-case contention and simplifies scheduler design for builders experimenting with parallelizable execution paths by allowing at least multiple independent transactions to be packed per block, even under abnormal memory pool conditions.
The specifications themselves are spare and mechanical. The EIP-7825 summary states the intent of “16,777,216 (2^24) gas” per transaction, which increases resiliency to certain DoS vectors and makes transaction processing more predictable as block limits increase. That simplicity is part of its appeal in core development channels. That is, small, broad-scope constraints that maintain forward compatibility with more ambitious scaling efforts.
Discussions about how to encode and communicate upper bounds have been active for several months, including in discussions about naming and parameterization at Ethereum Magician and during calls at AllCoreDevs. One thread summarizes the core guarantees covered by multiple contributors. By aligning block targets to a multiple of 2²⁴, the builder can always include at least n transactions if there are n eligible transactions in the memory pool. This is an argument for predictability rather than raw throughput.
Operationally, the foundation says all major clients (Geth, Erigon, Reth, Nethermind, and Besu) have implemented changes for Fusaka-enabled releases, reducing the risk of discrepancies between clients during activation. The post also emphasizes that eth_call semantics are unaffected and pre-signed transactions with a gas limit above 2²⁴ must be re-signed below the limit. The upgrade path for developers is easy. Test against Holesky or Sepolia, retool batch operations that ignore limits, and adjust gas estimation logic and alerts to fail immediately when construction exceeds the new limit.
The policy context is worth analyzing. Ethereum’s history has favored minimal general-purpose constraints, leaving complexity to higher layers. EIP-7825 fits that pattern. I’m not giving an opinion on what the contract should do, only that it respects upper bounds that protect uptime and prepare the execution layer for a multi-threaded future.
It also avoids fee market changes and leaves blob space economics and block targets to other EIPs and forks. As the Foundation states, this cap “establishes a more secure and predictable foundation for higher throughput in future forks” and is a succinct summary of the tradeoffs.
At the time of writing, ETH was trading at $3,835.
Featured image created with DALL.E, chart on TradingView.com
