# EIP-7825: Transaction Gas Limit Cap Source: https://www.eipsfordesigners.com/standards/EIP-7825 Agent brief: https://www.eipsfordesigners.com/standards/EIP-7825/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-7825 Last reviewed: 2026-09-18 Last updated: 2026-09-18 | Field | Value | | --- | --- | | Status | Final | | Chain | ethereum | | Category | Transaction Friction | | Journey stages | Executing Transactions, Gas & Fees, Status & Confirmation | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/eip-7825 | | Discussion search | https://ethereum-magicians.org/search?q=EIP-7825 | ## UX Impact EIP-7825 caps an Ethereum transaction's gas limit at 16,777,216 gas (2^24) on networks that activate it. Ethereum included the cap in Fusaka, which activated on mainnet on December 3, 2025. Large batch and deployment flows need a network-aware preflight and a recovery path that splits or redesigns oversized operations; eth_call is not subject to this transaction cap. ## Summary EIP-7825 caps an Ethereum transaction's gas limit at 16,777,216 gas (2^24) on networks that activate it. Ethereum included the cap in Fusaka, which activated on mainnet on December 3, 2025. Large batch and deployment flows need a network-aware preflight and a recovery path that splits or redesigns oversized operations; eth_call is not subject to this transaction cap. ## What does not work everywhere yet The cap is active on Ethereum mainnet after Fusaka and was shipped in client releases for the fork. Do not import 16,777,216 into Monad or another EVM network without that network's fork configuration and client evidence; read the selected chain's current transaction and block parameters. ## For Designers - Show the selected network and the maximum transaction gas limit before a large batch or deployment is signed. - Distinguish gas estimation, simulation, transaction gas limit, and block gas limit; the cap applies to a transaction gas limit, not the whole block. - When the cap blocks an operation, explain which work can be split and preserve a reviewable multi-transaction plan. ## Applicability ### When to Use - A product builds large batches, contract deployments, routers, or other transactions that may approach the selected network's cap. - A wallet or SDK surfaces gas-limit estimates and needs to explain a preflight rejection. - The product can simulate the actual operation on the activated fork and offer a safe split or retry. ### When to Avoid - The selected network has no verified EIP-7825 activation or uses a different cap. - The operation is a read-only eth_call and the UI would apply a transaction-only rule to it. - Splitting the operation would change its atomicity or user-visible outcome without an explicit product decision. ## Problems It Solves ### A split operation hides partial completion Impact: critical Old way: Present a series of transactions as one atomic action and report only the last error. New way: Preview chunks and show per-transaction status and recovery. ### Large transactions fail late after a user has prepared a complex batch Impact: high Old way: Estimate against block capacity, sign one oversized transaction, and receive a generic rejection. New way: Preflight the per-transaction cap and explain a supported split or redesign before signing. ### Users cannot tell transaction and block capacity apart Impact: high Old way: Show one gas-limit number that appears to describe both. New way: Label transaction cap, gas used, and block gas limit separately. ## Spec Constraints Quotes retain their source section and scope. Normative requirements, rationale, compatibility changes, and security recommendations are not interchangeable. Design implications are editorial guidance. ### Transactions above the active gas-limit cap need a different operation plan, such as smaller transactions. Applies to: application Source classification: backwards-compatibility > Transactions with such high limits will need to be split into smaller operations. Source: [Backwards Compatibility](https://eips.ethereum.org/EIPS/eip-7825#backwards-compatibility) Design implication (editorial): Preflight the selected network's transaction gas cap before signing. If a split is safe, preview its ordering, dependencies, and partial-result behavior instead of presenting it as an equivalent retry. ### Highly complex transactions, including large deployments, may need to be redesigned to fit the cap. Applies to: application Source classification: security-considerations > Certain highly complex transactions, such as large contract deployments, may require re-architecting to fit within the 16,777,216 gas cap. Source: [Security Considerations](https://eips.ethereum.org/EIPS/eip-7825#security-considerations) Design implication (editorial): Treat an over-cap deployment or batch as a product-plan decision. Explain which work must be redesigned or split and do not imply that a lower gas estimate alone makes the original transaction valid. ## Anti-Patterns (editorial) ### Applying Ethereum's 16,777,216 cap to every EVM network Severity: critical The rule is activated by a network fork and client configuration. Instead: Read the selected network's current cap and state the source. ### Auto-splitting a batch with no atomicity warning Severity: critical A sequence of transactions can leave partial state when one chunk fails. Instead: Preview ordering, dependencies, and partial-result behavior before signing. ### Comparing only estimated gas used with the cap Severity: high The protocol rejects a transaction whose gasLimit exceeds the cap even if execution might use less. Instead: Validate the transaction gas limit and show estimated gas used separately. ### Treating eth_call as a signed transaction Severity: medium The cap applies to transactions and does not impose the same limit on eth_call. Instead: Label simulations separately and validate the eventual transaction path. ## Design Decisions ### What number should the UI show? Recommendation: Show requested gas limit, estimated gas used, active per-transaction cap, and block gas limit as separate rows. Rationale: Conflating these values creates false confidence near the protocol boundary. ### Should the product split automatically? Recommendation: Offer a preview and require user review when splitting changes atomicity, ordering, or partial-failure behavior. Rationale: A smaller transaction is not an equivalent operation if contracts depend on one atomic call. ### How should the cap be communicated across networks? Recommendation: Read the selected chain's active fork/configuration and state the source and timestamp of the cap. Rationale: A protocol rule on Ethereum is not evidence of the same rule on Monad or another EVM network. ## States to Design ### Network cap detected Trigger: The selected chain and fork configuration expose an active transaction gas cap. User need: Know which limit governs the current action. Design response: Show the cap with network and fork context and keep block gas limit as a separate value. ### Operation within cap Trigger: The requested transaction gas limit is below the selected network cap and simulation succeeds. User need: Confirm the actual work and fee before signing. Design response: Show estimated gas used, gas limit, fee estimate, and any remaining simulation risks. ### Operation over cap Trigger: The transaction gasLimit exceeds 16,777,216 on Ethereum Fusaka or the selected network's configured cap. User need: A concrete way to continue or cancel. Design response: Block signing, show the requested and maximum limits, and offer a split or redesign only when the product can preserve the intended semantics. ### Split plan ready Trigger: The operation can be divided into ordered chunks. User need: Know the number, order, and failure behavior of the resulting transactions. Design response: Preview each chunk, dependency, gas limit, and partial-result state before the first signature. ### Partial execution Trigger: One chunk confirms while a later chunk fails or is rejected. User need: Know what changed and whether retry is safe. Design response: Show per-chunk receipts, completed work, remaining plan, and a targeted recovery action. ### Read-only simulation Trigger: The user previews an operation through eth_call. User need: Understand that read-only checks do not consume a transaction gas limit. Design response: Label simulation separately and still validate the eventual signed transaction against the active cap. ## Vocabulary - Use "Transaction gas limit" instead of "Block gas limit": The cap constrains one transaction while a block contains multiple transactions. - Use "Too large for this network" instead of "Out of gas": A cap rejection is a transaction-size boundary, not proof that execution consumed all gas. - Use "Split into [n] transactions" instead of "Retry": A split changes the operation plan and may change atomicity or partial-failure behavior. ## What to Prototype First ### Large-operation preflight Users need to know whether one transaction can carry the requested work before they sign. Covers: Under cap, Near cap, Over cap, Network unknown - Network and fork - Estimated gas used - Requested gas limit - Transaction cap - Simulation result ### Split-batch recovery A cap failure is only useful to users if the product explains what will happen to ordering and atomicity after a split. Covers: Safe split, Atomicity lost, One chunk failed, Retry - Chunk count and order - Per-chunk gas limit - Dependency warning - Progress and partial result ## Mental Model ### Transaction gas limit The sender's per-transaction gas allowance is the value constrained by EIP-7825. ### Gas used Execution may consume less than the limit; a low gas-used estimate does not make an over-cap gasLimit valid. ### Block gas limit A block can contain multiple transactions; the per-transaction cap is independent of the block's total gas limit. ### Network activation The cap applies only after the selected chain activates the relevant fork and clients enforce it. ### Operation plan Splitting an oversized transaction into chunks changes status, ordering, retry, and possibly atomicity, so the product must make that plan explicit. ## UI Components ### GasLimitCapNotice Shows the active network cap next to requested gas limit and estimated gas used. Kind: status States: loading, under-cap, near-cap, over-cap, network-unknown Props: network, fork, requestedGasLimit, estimatedGasUsed, cap ### BatchChunkTimeline Tracks each transaction in a split operation and exposes partial completion. Kind: progress States: planned, ready, submitted, confirmed, failed, blocked Props: chunks, dependencies, atomicity, onRetry ## Key Takeaways - EIP-7825 caps one transaction's gas limit at 16,777,216 on Ethereum Fusaka. - The cap is separate from estimated gas used, eth_call, and block gas limit. - Large operations need network-aware preflight and explicit split semantics. - Do not carry Ethereum's cap into Monad without chain-specific activation evidence. ## UX Patterns ### Gas-Cap Preflight Compare the requested transaction gas limit with the active network cap before signing. Components: Network/fork badge, Gas limit comparison, Simulation status, Proceed or split action User flow: - Select a network - Estimate and simulate the actual operation - Read the active transaction cap - Compare requested gas limit - Proceed under cap or review recovery ### Explicit Batch Split Turn an oversized operation into ordered, independently tracked chunks only when semantics permit. Components: Chunk preview, Dependency map, Atomicity warning, Per-chunk timeline User flow: - Identify cap violation - Calculate a safe chunk plan - Explain ordering and atomicity changes - Confirm each chunk's gas limit - Submit and track each result ## Related Standards - EIP-1559: Fee-market fields used to estimate the cost of each transaction chunk. - EIP-5792: Wallet-mediated call batches whose capability and atomicity still need to be checked. - EIP-7702: Delegated EOA implementations that may construct large batched transactions. ## Technical Notes EIP-7825 enforces a maximum transaction gasLimit of 16,777,216 (2^24) on activated networks. Txpool validation rejects a transaction above the cap and block validation rejects a block containing one. Ethereum's Fusaka mainnet upgrade activated the cap on December 3, 2025; the Ethereum Foundation documented it on October 21 and November 6, 2025 and noted that eth_call is unaffected. Client implementations such as Go Ethereum cap gas estimation when targeting Osaka. The cap is independent of block gas limit and does not prescribe how an application splits work.