Gas Limit

What Is Gas Limit?

The gas limit is the maximum amount of gas (computational effort) that a transaction or block is allowed to consume on an EVM-based blockchain like Ethereum. Think of it as a budget: the sender authorizes up to a certain amount of computation, and execution halts if that budget runs out before the transaction finishes.

Gas limits exist at two distinct levels. The transaction gas limit is set by the user submitting a transaction. A simple ETH transfer always costs exactly 21,000 gas, so users typically set a limit at or slightly above that number. Complex smart contract interactions require more gas, and wallets estimate the appropriate limit automatically. The block gas limit is a network-wide parameter that caps total computation per block. As of late 2025, Ethereum's block gas limit sits at 60 million gas following the Fusaka upgrade.

Without gas limits, a single buggy or malicious contract could loop forever, consuming infinite resources and halting the network. Gas limits make the EVM a bounded computation environment where every operation has a measurable cost.

How It Works

Every EVM opcode has a fixed gas cost. When a transaction executes, the EVM tracks a gas counter that starts at the transaction's gas limit and decrements with each operation. If the counter reaches zero, execution halts immediately.

Transaction Gas Limit

The sender sets the transaction gas limit when submitting a transaction. This value represents the maximum gas the sender authorizes. The actual fee depends on how much gas is consumed:

// Post-EIP-1559 fee calculation
max_fee = gas_limit × maxFeePerGas
actual_fee = gas_used × (base_fee + priority_fee)
refund = (gas_limit - gas_used) × maxFeePerGas

// Example: ERC-20 token transfer
gas_limit = 65000       // sender's budget
gas_used  = 52000       // actual consumption
base_fee  = 0.5 gwei    // protocol-set, burned
priority  = 0.1 gwei    // tip to validator
actual_fee = 52000 × 0.6 gwei = 31200 gwei ≈ $0.07

Setting the gas limit too low causes the transaction to fail with an out-of-gas error. Setting it too high has no direct financial penalty because unused gas is refunded, but the sender's wallet reserves the full amount (gas limit times max fee per gas) until the transaction confirms.

Block Gas Limit

The block gas limit constrains total computation across all transactions included in a single block. Validators (previously miners under proof of work) determine this value through a signaling mechanism: each block proposer can adjust the limit by up to 1/1024 (~0.1%) from the previous block. No hard fork is required.

Ethereum's block gas limit has increased significantly over time:

Under EIP-1559, the target block usage is 50% of the gas limit (30 million gas at the current 60 million limit). When blocks are more than half full, the base fee increases. When they are less than half full, it decreases. This creates a dynamic pricing mechanism that adjusts to network demand without requiring users to guess the right gas price.

Per-Transaction Cap

EIP-7825, finalized in the Fusaka upgrade, introduced a per-transaction gas limit cap of 16,777,216 (2^24). Even if the block gas limit allows more, no single transaction can consume beyond this threshold. This prevents a single transaction from monopolizing an entire block and stabilizes block validation times.

Gas Costs for Common Operations

Different EVM operations consume different amounts of gas. Storage operations are the most expensive because they modify blockchain state permanently:

The cold/warm distinction was introduced by EIP-2929. The first time a transaction accesses an address or storage slot, it pays the higher "cold" cost. Subsequent accesses within the same transaction pay the lower "warm" cost. Transactions can use access lists (EIP-2930) to pre-declare which addresses and storage slots they will touch, paying a discounted rate upfront instead of the cold access penalty.

Gas Estimation

Wallets and dApps use the eth_estimateGas JSON-RPC method to determine the appropriate gas limit for a transaction. This method simulates execution against the current blockchain state and performs a binary search to find the minimum gas needed.

Gas estimation has inherent limitations. Contract state can change between the time of estimation and actual execution, causing the real gas cost to differ. For this reason, wallets typically add a 10-20% buffer above the estimate. An overly generous buffer wastes nothing (excess gas is refunded), but an insufficient buffer means a failed transaction and lost fees.

What Happens When Gas Runs Out

If a transaction exhausts its gas limit during execution, five things happen in sequence:

1. Execution halts immediately with an "out of gas" exception
2. All state changes from that transaction are reverted: token transfers, storage writes, and contract deployments are rolled back entirely
3. The sender is charged the full gas limit as a fee, not just the gas consumed up to the failure point
4. The failed transaction is included in the block with a "reverted" status, proving that resources were consumed
5. The sender's nonce increments, preventing replay of the same transaction

Charging for failed transactions is an intentional design choice. If out-of-gas failures were free, attackers could flood the network with computationally expensive transactions at no cost, effectively creating a denial-of-service attack. The fee penalty ensures every computation attempt carries an economic cost, regardless of outcome.

Gas Limit vs. Bitcoin Weight Units

Bitcoin uses a different system called weight units to limit block capacity. While Ethereum's gas measures computational complexity, Bitcoin's weight units measure data size:

Bitcoin's block size limit does not account for computational complexity because Bitcoin Script is intentionally non-Turing complete. Ethereum needs gas precisely because the EVM supports arbitrary computation through smart contracts.

For deeper analysis of how different blockchains approach transaction capacity and fee markets, see the research on EIP-4844 and blob fee markets.

Use Cases

• DoS prevention: gas limits make it economically infeasible to flood the network with expensive computation, as every opcode execution costs real money
• Infinite loop protection: even if a smart contract contains a bug that causes infinite recursion or looping, execution terminates when gas runs out
• Resource pricing: different operations cost different amounts of gas based on their actual resource consumption (CPU, storage, bandwidth), creating accurate economic signals
• Network capacity planning: the block gas limit acts as a throughput knob that validators can adjust to balance throughput against node hardware requirements
• Fee budgeting: users set transaction gas limits to cap their maximum spending, with unused gas refunded automatically

Risks and Considerations

Out-of-Gas Failures

The most common risk is setting the gas limit too low. Complex contract interactions, especially those involving multiple nested calls or large storage writes, can consume significantly more gas than estimates predict. Failed transactions still cost the full gas fee, making repeated failures expensive.

Gas Estimation Inaccuracy

Gas estimation via eth_estimateGas simulates against current state, but state can change before the transaction executes. A pending transaction from another user might modify the same contract storage, changing the gas profile entirely. DEX trades are particularly susceptible: liquidity pool state changes between estimation and execution can cause gas usage to spike or the transaction to revert.

Block Gas Limit Governance

Raising the block gas limit increases throughput but also increases the hardware requirements for running a full node. Larger blocks take longer to propagate and validate, increasing the risk of chain reorganizations and reducing the number of participants who can afford to run validator nodes. This creates a tension between scalability and decentralization: a core tradeoff described by the blockchain trilemma.

Layer 2 Alternatives

High gas costs on Ethereum have driven users and developers toward layer-2 solutions that amortize execution costs across many transactions. Rollups batch transactions off-chain and post compressed data to Ethereum, while protocols like Spark take a different approach entirely by operating on Bitcoin, where the UTXO model avoids the gas paradigm altogether.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.