Ethereum's Gas Ceiling Now Bounds Every Contract Call

Since Fusaka shipped, Ethereum contract execution has been bounded first by a 16,777,216-gas transaction cap, then by the sender's transaction limit and the EVM's 63/64 call-forwarding rule. The block limit still constrains aggregate work, but it can no longer give one transaction the whole block. That distinction explains why a swap may pass estimation yet fail inside a router: “gas limit” describes several narrowing budgets, not one interchangeable ceiling.

Which limit rejects the transaction first?

The protocol cap is the first hard admission boundary. A client rejects any transaction declaring more than 16,777,216 gas before the EVM executes it. Below that ceiling, four limits matter:

• Protocol cap: the maximum gas limit any Ethereum transaction may declare.
• Block limit: the aggregate execution capacity available to transactions in a block.
• Transaction limit: the sender's chosen budget for intrinsic costs and every subsequent opcode.
• Call limit: the smaller amount explicitly passed to a child contract or allowed by the EVM's 63/64 rule.

Contract code can impose another boundary by checking remaining gas and reverting, but that is application policy rather than a network limit.

An order's gas narrows at every hop

Take an exact-input swap submitted with a 300,000-gas limit. The transaction first pays its intrinsic charge, including calldata costs. The remaining budget reaches the router, which decodes the order, transfers tokens and calls the pool. Every opcode, memory expansion and account access reduces what remains.

Suppose 128,000 gas is available after the pool call's overhead. Even if the router requests all of it, the EVM can forward at most 128,000 minus floor(128,000 divided by 64), or 126,000 gas. The reserved 2,000 stays with the caller. If the pool or a token hook needs 126,001, that child frame runs out of gas. A high-level Solidity call normally propagates the failure; a low-level call can return false and let the router decide whether to revert the order.

This same nesting risk appears in bridge settlement, where one user action may cross several contracts; the withdrawal flow described by chainbrief.pages.dev illustrates why available capital and executable gas are separate constraints.

Does a higher gas limit increase the fee?

No—not unless execution uses the extra gas. The sender reserves enough ETH for the declared allowance, but unused gas is released. At the same effective gas price, a direct pool swap consuming G gas costs G multiplied by that price; an aggregator route consuming G plus routing overhead pays for the difference even if both transactions declare 300,000.

Setting the limit too low is worse: an out-of-gas transaction rolls back its state changes while consuming the supplied budget. Estimation also cannot guarantee a fill because pool state, access patterns or the selected route can change before inclusion.

The cap improves execution predictability

Before Fusaka, one transaction could theoretically approach the block ceiling. The new cap makes worst-case execution smaller and block packing more predictable; analysis of pre-upgrade activity found 99.96% of sampled transactions already at or below it. That is a genuine improvement for ordinary traders, whose swaps remain unaffected.

The trade-off falls on contract deployers, governance executors and batch liquidators doing oversized work. They must split operations, pay repeated intrinsic costs and accept state changes between parts. Traders can test the live boundary by comparing gas estimation with the submitted limit, then inspecting receipt status, gas used and the deepest failing frame in a transaction trace.