The Solidity Gas Limit Estimator lets you build up an estimate of how much gas a function will consume by listing the EVM operations it performs. It uses the post-Berlin/London gas schedule so you can set realistic gas limits and spot the operations that dominate your cost before you deploy.
Why gas estimation matters before deployment
Setting the gas limit too low causes a transaction to revert out of gas — the
user pays the gas consumed up to the failure point and still gets no result.
Setting it far too high does not cause a failure, but the frontend or API call
needs a realistic limit to avoid confusing users and to catch runaway logic.
Two-pass gas estimation (estimate here, confirm with eth_estimateGas against
a fork, then add a buffer) is the standard pre-deployment workflow.
How it works
Each EVM opcode has a fixed gas cost defined by the Ethereum Yellow Paper and later EIPs, most recently updated by the Berlin hard fork (EIP-2929, which introduced the warm/cold distinction for storage access). The estimator multiplies the cost of each operation by how many times your function runs it, then adds the mandatory 21,000-gas base transaction cost:
total = 21000 + Σ (opcode gas cost × count)Key costs in the built-in table (post-Berlin/London EIP-2929 schedule):
| Operation | Gas cost | Notes |
|---|---|---|
| SSTORE (zero → non-zero) | 22,100 | Most expensive common write |
| SSTORE (non-zero → non-zero) | 5,000 | Update an existing slot |
| SSTORE (non-zero → zero) | 5,000 | With a 4,800 refund |
| SLOAD (cold slot) | 2,100 | First access this transaction |
| SLOAD (warm slot) | 100 | Already accessed this transaction |
| ERC-20 transfer (typical) | ~50,000 | Two SSTOREs + event |
| LOG (event emission) | ~1,125 + 8/byte | Plus topic and data costs |
| External CALL (cold) | ~2,600 + gas forwarded | CALL to a new address |
| ADD, MUL, arithmetic | 3–5 | Negligible individually |
| Base transaction | 21,000 | Every transaction, before code |
Setting a safe gas limit
Because real gas depends on warm/cold access patterns, the exact code path taken
at runtime, and calldata size, the tool adds a safety buffer on top of the
raw total. Use the suggested limit as your transaction gas parameter.
The breakdown sorts operations by their total gas contribution, so the biggest consumers rise to the top. Storage writes almost always dominate. Practical optimisation advice:
- Pack state variables. Multiple small values in one 256-bit slot share one SSTORE write instead of paying 22,100 per variable.
- Use
memoryfor intermediate state. MSTORE costs only 3 gas; SSTORE costs thousands. Accumulate in memory and write to storage once at the end. - Warm slots are cheap on subsequent reads. If you read the same slot twice in one transaction, the first access is cold (2,100) and the second is warm (100).
- Avoid storage in loops. A loop over N items with one SSTORE each costs 22,100 × N for cold writes. Consider batching state updates outside the loop.
Always confirm the final number with eth_estimateGas against a local fork or
testnet run before deploying to mainnet. This tool is a planning estimate — real
gas varies by call path and transaction context.