Why eth_estimateGas is higher than gas used

Last updated: September 22, 2026

At a glance

What you see

The receipt's gasUsed is noticeably lower than the eth_estimateGas result you used as the gas limit. Or the opposite: a transaction sent with a limit equal to a previous gasUsed runs out of gas.

Why this happens

Ethereum's JSON-RPC documentation says eth_estimateGas "will not be added to the blockchain" and that "the estimate may be significantly more than the amount of gas actually used by the transaction, for a variety of reasons including EVM mechanics and node performance". One mechanism is EIP-150's "all but one 64th" rule: a call can pass at most 63/64 of the remaining gas to a subcall, so a transaction with nested calls needs a higher limit than the gas it ends up consuming. Another is refunds: under EIP-3529 clearing storage earns a refund of up to gas_used // 5 at the end of the transaction, which lowers the charged gasUsed but not the gas the transaction needs while it runs. Finally, the estimate is computed against the state at the time of the call; if that state changes before inclusion, so does the gas. When no gas limit is given, the documentation notes that geth uses the pending block's gas limit as an upper bound.

What to do

1. Use the estimate as the gas limit (optionally with a margin), not a previous transaction's gasUsed.
2. Expect gasUsed to be lower for transactions that clear storage or make nested calls; that difference is not overpayment of the unused limit.
3. Re-estimate right before sending when the transaction depends on state that changes often.
4. Pass the same from, value and block as the real transaction when estimating, so the simulation takes the same code path.

When this is not our problem

The gap between estimate and gasUsed comes from EVM gas rules defined in EIPs, the same on every node, whoever operates it, Triport included. The estimate is a simulation; only the gas limit you choose is up to you.