fix: meter CALLCODE new-account storage gas against caller context

[RealiCZ]

Summary

CALLCODE currently charges MegaETH new-account storage gas using the stack to address, which is the code-source address.

For CALLCODE, execution happens in the caller's account context, so new-account metering should be based on the caller/storage context rather than the raw code-source address.

Affected area

• crates/mega-evm/src/evm/instructions.rs

Details

storage_gas_ext::wrap_call_with_storage_gas! currently reads the call target from stack position 1 and uses it for both account inspection and storage-gas charging:

let to = context.interpreter.stack.inspect::<1>().unwrap().into_address();
let to_account = context.host.inspect_account_delegated(mega_spec, to)?;
...
context.host.new_account_storage_gas(to)

That is correct for CALL, but not for CALLCODE.

For CALLCODE, the stack to address only selects the code to execute. The storage/account context remains the caller/current frame address. Charging new-account storage gas against the code-source address can charge when the wrong account is empty, or miss charging when the caller/storage account is the relevant account.

Impact

MegaETH storage-gas accounting for value-transferring CALLCODE can be wrong.

This is especially relevant around account-creation metering and EIP-7702 delegated-account emptiness checks.

Suggested remediation

Split the storage-gas wrapper behavior for CALL and CALLCODE.

For CALL:

• keep using the stack to address as the account being value-transferred to.

For CALLCODE:

• use the current execution/storage account, i.e. context.interpreter.input.target_address(), for emptiness checks and new_account_storage_gas(...).
• keep using the stack to address only as the code-source address for the actual CALLCODE instruction.

Add regression tests showing that a value-transferring CALLCODE meters new-account storage gas based on the caller/storage context, not the code-source address.

Please verify whether this behavior needs to be gated to the current unstable spec according to AGENTS.md.

[TroublorBot]

Now I have a clear picture of the code. Let me write the implementation plan.

---

Understanding

The wrap_call_with_storage_gas! macro uses the stack to address (code-source) for both CALL and CALLCODE when checking emptiness and charging new-account storage gas. For CALLCODE, the storage/account context remains the current frame's account (target_address()), so the emptiness check and gas charge should be against that address, not the code-source address.

Approach

1. Modify storage_gas_ext::call_code in crates/mega-evm/src/evm/instructions.rs

Instead of generating call_code via the shared wrap_call_with_storage_gas! macro (which always uses the stack to address), write a separate explicit call_code function:

• Read to from stack position 1 — used only for the underlying compute_gas_ext::call_code dispatch.
• For mega_spec.is_enabled(MegaSpecId::REX5): use context.interpreter.input.target_address() for inspect_account_delegated(...) and new_account_storage_gas(...).
• For older specs: fall back to to (preserves behavior of all stable specs — REX through REX4 — per AGENTS.md backward-compatibility rule).

The fix must be gated to REX5 because AGENTS.md prohibits changing existing stable spec behavior; REX5 is the current unstable spec.

2. Add regression tests in crates/mega-evm/tests/rex5/ (new file, e.g., callcode_storage_gas.rs):

• Deploy a non-empty caller contract that performs a value-transferring CALLCODE targeting an empty code-source address; assert that no new-account storage gas is charged (because the caller/storage context is non-empty).
• Deploy a non-empty caller contract that performs a value-transferring CALLCODE targeting a non-empty code-source, but the caller account itself is the relevant emptiness context; assert storage gas is charged correctly against target_address().
• Optionally, mirror tests for CALL to confirm its behavior is unchanged.

3. Update docs/ if any spec page for REX5 documents storage-gas charging for CALLCODE — add a note that new-account storage gas is metered against the caller's storage context. Run npx prettier --write 'docs/**/*.md' before committing.

Risks

• target_address() identity for top-level frames: Confirm that context.interpreter.input.target_address() is always the correct caller-context account at all call depths. If this is the EVM entry frame (depth 0), there is no "caller"; but CALLCODE at depth 0 is an unusual edge case worth a test.
• Interaction with EIP-7702 delegated account logic: inspect_account_delegated follows delegation chains; the account returned for target_address() vs to may differ in emptiness. Verify that state_clear_aware_is_empty behaves correctly against the current frame's (possibly delegated) account.
• Macro vs. explicit function maintenance: Future changes to the shared macro won't automatically apply to the explicit call_code function — the two implementations will need to be kept in sync manually. A comment referencing the divergence reason is warranted here.

Reply @TroublorBot go to start implementation.

[RealiCZ]

@TroublorBot go

[TroublorBot]

🚀 PR created: #284