Geth Proposal Targets Gas Estimates That Miss Failed Contract Calls
An Ethereum transaction can complete even if one of its internal contract calls fails. A draft Geth change would account for those failures in gas estimates, rather than checking only whether the outer transaction finishes.
- A successful transaction does not guarantee every sub-operation succeeded.
- Draft pull request #36084 would compare internal failures with a higher-gas reference execution.
- The developer reports 64 of 67 cases fixed, but the test counts leave 111 transactions unaccounted for.
When a completed transaction misses the intended outcome
Gas measures the computational work a transaction uses on Ethereum. A wallet’s gas estimate helps set its gas limit, the maximum amount of gas it can consume. If the limit is too low, the transaction can run out of gas before it finishes.
Smart contracts can call other contracts. If an internal call fails, the calling contract may catch the failure and continue. It might record the failure, refund funds, or skip an item. The outer transaction can still complete even though a sub-operation, and possibly part of the user’s intended action, did not.
An estimator that checks only whether the outer transaction completes can miss this distinction. It may suggest a gas limit that lets the transaction finish but does not give internal work enough gas to succeed.
What the Geth proposal would change
A Geth developer proposed a change in draft GitHub pull request #36084. The proposal would have the estimator count failed internal calls and contract creations, instead of treating completion of the outer transaction as the only measure of success.
It would compare an execution with the estimated gas limit against a reference execution with a higher limit. If the estimated run has more internal failures than the reference run, the estimator would reject it. The stated aim is to avoid treating failures that also occur in the higher-gas execution as problems that can necessarily be fixed by raising the estimate.
That comparison does not guarantee that every failure has been diagnosed. The proposal’s description, as available here, does not explain how it matches failures between executions or handles cases where different gas limits produce different execution paths. Those details matter when assessing how reliably the comparison distinguishes gas-related failures from other causes.
The proposal also describes a separate “Amsterdam reference, ” intended to avoid unnecessary gas-limit increases made solely to access the state gas reservoir. The supplied explanation does not define that reservoir or provide enough detail to assess how this part of the change works.
EIP-8037 and the role of remaining gas
The proposal’s developer says EIP-8037 could make the estimation issue more common. The concern is that gas remaining after a failed internal execution may be returned to the calling contract and used to fund a fallback path, the code it runs after an operation fails.
That does not mean gas already spent on failed work is refunded. Nor does the claim alone show that EIP-8037 will cause widespread failures. The point is that a contract may be able to use its remaining gas after an internal call fails, so completion of the outer transaction is not a reliable signal that every operation succeeded.
Test results are promising, but incomplete
The developer reports replaying 432 mainnet transactions using the new rules associated with the Amsterdam update. The reported results say the change fixed 64 of 67 cases. Another 254 estimates were unaffected because the issue was absent, and 3 cases went undetected.
The figures do not account for the full test set. The 64, 254, and 3 total 321, leaving 111 of the 432 transactions unexplained if those categories are separate. It is also unclear what counted as a “case, ” though the three undetected cases appear to be the remainder of the 67 identified cases. The results are encouraging, but the missing accounting makes them hard to evaluate fully.
The same report says the gas limit increased by 4%, without specifying what the percentage measures or which transactions it covers. That should not be read as a 4% increase in transaction fees. The gas limit is a ceiling. Users generally pay for gas actually used at the applicable fee rates, not for the entire limit. A higher cap alone does not mean a transaction uses more gas or costs more, though it can allow more work to run if needed.
Key questions and answers
-
How can a transaction complete if an internal call fails?
A contract can catch a failed call to another contract and continue executing. The outer transaction may complete even though one sub-operation did not.
-
What would Geth pull request #36084 change?
The draft would count failed internal calls and contract creations, then compare failures under the estimated gas limit with those in a higher-gas reference execution.
-
Did the proposed change fix every reported case?
No. The developer reports 64 of 67 cases fixed and 3 undetected. The figures provided do not explain what happened to 111 of the 432 replayed transactions.
-
Does a 4% higher gas limit mean fees rise by 4%?
No such conclusion follows from the information provided. The 4% figure is not defined, and a gas limit is a cap, not the amount automatically charged.
The proposal addresses a real blind spot: a transaction’s success status can hide failed contract work. How well this approach handles edge cases will depend on its implementation and clearer test accounting. Until then, “transaction successful” is useful information, but it does not prove that every intended operation succeeded.
