Gas Limit
Maximum gas a transaction is allowed to consume.
The gas limit is the maximum amount of gas an EVM transaction is allowed to consume during execution. It acts as a safety cap on computational and storage work. The sender pays for gas actually used, not automatically for the entire limit, provided the transaction completes before exhausting it.
Wallets estimate a suitable limit by simulating the proposed transaction against current blockchain state. A simple native transfer has predictable use, while a decentralized exchange swap can follow different contract paths based on pool state, token behavior, and user inputs. Estimates can become stale if state changes before the transaction executes.
If execution reaches the gas limit, the EVM stops with an out-of-gas error. The intended state changes revert, but the consumed gas is charged. This rule prevents attackers from requesting unlimited computation and protects senders from unbounded execution. It also means a limit set too tightly can waste a fee without completing the action.
Gas limit is different from gas price. The limit caps units of work, while the price determines the amount paid per unit. A transaction with a large limit can be cheap if little gas is used and the unit price is low. A simple transfer can be expensive during congestion if gas price is high.
There is also a block gas limit or related protocol capacity parameter, which restricts the total work included in a block. Users cannot submit a transaction exceeding network constraints. Block capacity and target usage influence congestion and fee dynamics, while transaction limits protect individual execution.
Users should start with a trusted wallet estimate and investigate errors before adjusting. Raising the limit cannot fix a paused contract, insufficient balance, expired quote, missing approval, or failed condition. Developers should test maximum execution paths, untrusted external calls, loops, and changing state. A correct gas limit allows intended work with reasonable margin while making maximum resource exposure explicit and bounded.
Applications should avoid hard-coded limits when dependable estimation is available. Contract upgrades and changing token implementations can make yesterday's fixed value fail. Monitoring out-of-gas receipts helps developers identify regressions, while clear error messages stop users from retrying blindly and paying repeated fees.
Frequently asked questions
- Use a reputable wallet or RPC estimate based on simulating the exact transaction against current state. A modest buffer can handle limited variation, but automatic estimates are normally sufficient. For custom contracts, test worst-case paths and unusual tokens. Do not increase the limit blindly when a transaction reverts for a logic, permission, balance, or slippage reason.
- Execution stops when it consumes all allowed gas, state changes revert, and the sender normally pays for the gas used. The transaction can still appear in a block with failed status. Tokens do not move as intended, but the network fee is gone. Re-estimate and inspect contract behavior before retrying to avoid paying repeatedly for the same failure.
- A higher transaction gas limit does not normally make the sender pay for unused gas, but the account must be able to afford the stated maximum. Wallets and blocks also apply protocol constraints. An unnecessarily high cap can hide inefficient or malicious execution and make maximum-cost displays alarming, so use a credible estimate rather than an arbitrary extreme number.