The Ethereum Foundation has confirmed that the upcoming Fusaka hard fork will introduce a protocol-level cap on the amount of gas a single transaction can consume, officially codified as EIP-7825. The cap is set at 2²⁴ of gas, or 16,777,216 units, marking the first time that Ethereum has applied a per-transaction limit separate from the block gas limit. The change is already active on Holesky and Sepolia and will go live on mainnet when Fusaka is activated.
In an article published on October 21, Toni Wahrstätter put the reasoning in blunt terms: “Starting with the upcoming Fusaka hard fork, EIP-7825 introduces a per-transaction gas cap limit of 2²⁴ (≈ 16.78 million gas). » The Foundation’s note emphasizes that while the cap limits individual transactions, it does not modify the limit of the gas block; instead, it is designed to mitigate denial of service vectors where a single oversized call monopolizes an entire block and to improve the predictability of block grouping as 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 approach the full gas block target (sometimes around 45 million), creating timing and planning pathologies for builders and validators.
The new cap requires dividing workloads that would exceed 16.78 million gases into smaller, sequenced calls. The Foundation’s guidance is careful to note that “for most users, nothing changes”, since the statistical distribution of actual transactions is already well below the threshold; the risk surface mainly concerns heavy contracts, deployment scripts and specialized routers.
What this means for Ethereum and users
From a roadmap perspective, the cap is explicitly positioned as a basis for parallel execution. The blog post connects this change to anticipated efforts such as EIP-7928 in the era of “Glamsterdam,” where predictable and limited transactions are a prerequisite for meaningful concurrency in the execution layer. By ensuring that at least several independent transactions can be compressed per block, even under pathological memory pool conditions, the cap reduces worst-case contention and simplifies scheduler design for builders experimenting with parallelizable execution paths.
The specification itself is aftermarket and mechanical. The EIP-7825 summary states the intention to “achieve 16,777,216 (2^24) gas” per transaction, thereby improving resilience against certain DoS vectors and making transaction processing more predictable as block limits increase. This simplicity is part of its appeal in core development channels: a small, well-extended constraint that preserves backwards compatibility with more ambitious scaling work.
The debate over how to code and communicate the cap has been active for months, including discussions about naming and setting on Ethereum Magicians and on AllCoreDevs calls. One thread summarized the main guarantee targeted by several contributors: align block targets to multiples of 2²⁴ so that builders can always include at least n transactions if the memory pool is in eligible years – an argument for predictability rather than raw throughput.
Operationally, the Foundation says all major customers – Geth, Erigon, Reth, Nethermind, and Besu – have implemented the change in Fusaka-ready builds, reducing the risk of customer divergence during activation. The post also highlights that eth_call semantics are not affected and that pre-signed transactions with gas limits exceeding 2²⁴ will need to be re-signed below the cap. The upgrade path for developers is simple: test with Holesky or Sepolia, reorder batch operations that flirt with the limit, and adjust the gas estimation logic and alerts so that they fail quickly when builds exceed the new cap.
The political context deserves to be analyzed. Ethereum’s history has favored minimal and general constraints, deferring complexity to higher layers. EIP-7825 fits this model: it doesn’t comment on what contracts should do, only that they respect an upper bound that protects liveness and prepares the execution layer for a multithreaded future.
It also avoids fee market changes and leaves blob space economics and blocking targets to other EIPs and forks. As the Foundation puts it, the cap “establishes a safer and more predictable basis for higher throughput in future forks,” a phrase that succinctly sums up the tradeoff.
At press time, ETH was trading at $3,835.
Featured image created with DALL.E, chart from TradingView.com
Editorial process as Bitcoinist focuses on providing thoroughly researched, accurate and unbiased content. We follow strict sourcing standards and every page undergoes careful review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance and value of our content to our readers.
