The Ethereum Foundation has confirmed that the upcoming Fusaka hard fork will introduce a protocol-level cap (officially coded as EIP-7825) on the amount of gas a single transaction can consume. The limit is set at 2²⁴ gas (16,777,216 units), marking the first time Ethereum has implemented a per-transaction limit separate from the block gas limit. The changes are already live on Holesky and Seplia and will be live on mainnet once Fusaka goes live.
Toni Wahrstätter provided direct evidence in a post published on October 21: “Starting with the upcoming Fusaka hard fork, EIP-7825 introduces a per-transaction gas cap limit of 2²⁴ (approximately 16.78 million gas).” The foundation’s note emphasizes that the limit limits individual transactions but does not change the block gas limit. Instead, it is designed to mitigate the denial-of-service vector where a single large call monopolizes an entire block, and to improve block packing predictability when the network prepares for parallel execution.
EIP-7825 draws a clear line between transaction-level complexity and system-level throughput. Previously, exceptionally large calls could reach full block gas targets (sometimes around 45 million), causing timing and scheduling pathologies for builders and validators.
The new limit mandates that workloads exceeding 16.78 million gas be split into smaller sequences of calls. The foundation’s guidelines are careful to note that “for most users, this will make no difference” because the statistical distribution of real transactions is already well below the threshold. The risk surface primarily relates to high-deployment contracts, deployment scripts, and special routers.
What this means for Ethereum and its users
From a roadmap perspective, this cap is explicitly placed as a basis for parallel execution. The blog post links the changes to anticipated efforts like EIP-7928 in the “Glamsterdam” era, where predictable and bounded transactions were a prerequisite for meaningful concurrency in the execution layer. By ensuring that at least multiple independent transactions can be packed per block even under pathological mempool conditions, this limit reduces worst-case contention and simplifies scheduler design for builders experimenting with parallel execution paths.
The specs themselves are leisurely and mechanical. The summary of EIP-7825 states the intent is “16,777,216 (2^24) gas” per transaction, which improves resiliency against certain DoS vectors and makes transaction processing more predictable as block limits increase. This simplicity was part of the appeal of the core development channel. That is, small, broad constraints that maintain compatibility with more ambitious extensions.
Discussions about naming and parameterization for Ethereum Magicians and how to encode and communicate ceilings have been active for several months during AllCoreDevs calls. One thread summarized the core guarantees that several contributors were targeting. This means that the block targets are ordered in multiples of 2²⁴ so that if there are n eligible transactions in the mempool, the builder will always include at least n transactions. This is an argument for predictability rather than raw throughput.
Operationally, the Foundation stated that all major clients – Geth, Erigon, Reth, Nethermind, and Besu – have implemented the changes in the Fusaka support release, reducing the risk of branching between clients upon activation. The post also highlights that eth_call semantics are not affected and that pre-signed transactions with a gas limit above 2²⁴ will need to be re-signed below the limit. The upgrade path for developers is simple. Test against Holesky or Sepalia, re-tool batch jobs that hit limits, and adjust gas estimation logic and alerts to ensure construction fails quickly when it exceeds new limits.
The policy context is worth analyzing. Ethereum’s history has been to defer complexity to higher layers in favor of minimal, general-purpose constraints. EIP-7825 fits this pattern. We do not opine on what the contract should do, only that it respects upper bounds that protect liveness 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 puts it, the cap “builds a more secure and predictable foundation for higher throughput in future forks.” This is a line that succinctly summarizes the trade-off.
At press time, ETH was trading at $3,835.
Featured image created with DALL.E, chart from TradingView.com
editing process for focuses on providing thoroughly researched, accurate, and unbiased content. We adhere to strict sourcing standards and each page undergoes diligent review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance, and value of the content for readers.
