CALL* does not refund the NEW_ACCOUNT state-gas charge when the call fails before entering the frame (EIP-8037)

[misilva73]

Metadata

• Hardfork: amsterdam

What was wrong?

The EIP-8037 conditional NEW_ACCOUNT state-gas charge for the CALL* family is not refunded when the call fails before entering the child frame, contradicting EIP-8037 and creating an asymmetry with CREATE/CREATE2 (which refund correctly on the analogous failures).

NEW_ACCOUNT is charged conditionally in call/callcode/etc. at src/ethereum/forks/amsterdam/vm/instructions/system.py:460-461:

if value != 0 and not is_account_alive(tx_state, to):
    charge_state_gas(evm, StateGasCosts.NEW_ACCOUNT)

…but it is never credited back on the two pre-frame failure exits:

• Insufficient sender balance — system.py:481-485 restores only call_state_gas_reservoir, which is captured after the NEW_ACCOUNT deduction, so the charge (and any portion that spilled into gas_left) is lost.
• Stack-depth limit — generic_call, system.py:338-342 restores params.gas / params.state_gas_reservoir only.

Neither branch calls credit_state_gas_refund. Compare generic_create, which does refund on its analogous pre-frame failures (system.py:112-119).

Impact: the sender of a value-bearing CALL to a non-existent/empty account is over-charged STATE_BYTES_PER_NEW_ACCOUNT × CPSB when the call fails on insufficient balance or the stack-depth limit, even though no account is created.

Sources

• EIP-8037 — account-creation charging for the CALL* family:

  If the operation is unsuccessful before entering the call frame (e.g., due to insufficient balance or due to the stack depth), or if the child frame reverts or halts exceptionally, the charged state-gas is refilled in LIFO order and execution_state_gas_used decreases by the same amount.

• Update EIP-8037: resolve EIP-7928 conflict and route state-gas refills to origin EIPs#11807 — the PR that clarifies the CALL* (conditional) vs CREATE/CREATE2 (unconditional) charging split, where this requirement is spelled out.

Additional Context

• The third EIP case (child reverts/halts) is effectively unreachable for this charge: a non-alive target has no code, so the child frame STOPs and cannot fail. Only the two pre-frame exits above are affected.
• This is pre-existing behavior, independent of the in-flight EIP-8037 PRs (feat(spec-specs, tests): update EIP-8037 to use source based refunds #2999 LIFO refill, feat(spec-specs, tests): refund EIP-8037 account creation for existing create targets #3002 CREATE pre-existing-target refund). It surfaced while cross-checking those PRs against Update EIP-8037: resolve EIP-7928 conflict and route state-gas refills to origin EIPs#11807.
• Suggested fix: credit the charge back on both branches, mirroring generic_create, e.g. credit_state_gas_refund(evm, StateGasCosts.NEW_ACCOUNT). Subtlety: the charge happens in the caller while the stack-depth check lives in generic_call, so the refund must either live in each caller's depth handling or generic_call must be told whether the account charge was applied.
• Tests: add regression coverage for a value-bearing CALL to an empty account that fails on (a) insufficient sender balance and (b) the stack-depth limit, asserting the NEW_ACCOUNT state-gas is refunded.

[misilva73]

@spencer-tb, I think we have an issue with the spec. Can you confirm? @bshastry found this while doing some fuzzing analysis.

[chfast]

I was about to report this same issue. I think this is the execution-specs implementation issue. The EIP says otherwise.

Also, there is already a test that exercises exactly this path, and its docstring documents the EIP behavior. In tests/amsterdam/eip8037_state_creation_gas_cost_increase/test_state_gas_call.py, test_call_insufficient_balance_returns_reservoir[new_account] says:

"When a CALL transfers value but the caller has insufficient balance, the call fails before any state gas is charged for the target account."

That is the opposite of what the code does: NEW_ACCOUNT is charged at system.py:460-461, before the balance check at system.py:481. The test only passes because it quietly budgets for the charge its docstring says never happens (for the new-account case it sets reservoir = sstore_state_gas + NEW_ACCOUNT) and then asserts post-state storage, not gas. So it never detects the over-charge, and once the refund is added it will keep passing while no longer exercising the failure. Both the docstring and the budgeting should be revisited with the fix.

[spencer-tb]

Thanks! This should already be fixed and covered in #3005, its in our current devnets/glamsterdam/6 branch but not in forks/amsterdam (or CI wont let us merge it atm :P)!

[spencer-tb]

@chfast I updated the test in #3005 re. your comments here: 473a8c6

[spencer-tb]

Keeping this issue open for now. Will add it to our glamsterdam-devnet@v6.0.0 tracker for now. Can close it with the tracker!