debug_traceCall: Storage writes from CREATE2 not visible to subsequent calls when using stateOverrides

[kidrew]

Describe the bug

debug_traceCall with stateOverrides (stateDiff + code overrides) produces different execution results on Reth vs Geth. Specifically, storage writes performed during a CREATE2 deployment step are not visible to subsequent calls within the same trace execution on Reth but are visible on Geth.

This causes unexpected execution reverts that do not occur on Geth. The issue is not present in eth_call with the same overrides - it is specific to debug_traceCall.

Observed behavior

Geth: 1 revert (expected - an early _validateSenderAndPaymaster check before the account exists). After the CREATE2 deployment, executeUserOp succeeds because isModuleInstalled(...) returns true.

Reth: 3 reverts. After CREATE2 deployment, executeUserOp reverts with ModuleNotInstalled(...) because isModuleInstalled(...) returns false.

Key divergence

The function isModuleInstalled(1, 0x00000000008bdaba73cd9815d79069c247eb4bda) reads storage that was written during the CREATE2 deployment step (bootstrapWithSingleValidator installing the module into a linked-list storage structure).

• In Geth, those storage writes are visible to subsequent calls in the same trace execution (SLOAD returns the written values).
• In Reth, the subsequent SLOAD reads return different (stale) values, leading to the ModuleNotInstalled revert.

This appears to be an execution divergence inside debug_traceCall (SLOAD results differ between clients), not just a difference in how nested reverts are reported.

Additional context

• Method: debug_traceCall
• Tracer: callTracer
• State overrides used: stateDiff (storage slot override) + code override on the EntryPoint contract
• Scenario: ERC-4337 UserOperation simulation - CREATE2 smart account deployment followed by execution against the newly deployed account in the same simulated call
• eth_call with the same overrides behaves consistently across both clients - the discrepancy is specific to debug_traceCall
• Reproduced on: Base Sepolia, Optimism Sepolia, Eth Sepolia - all Reth-based
• Confirmed reproducible on vanilla Reth nodes (not just OP Stack / Base fork)

Expected behavior

debug_traceCall should produce identical execution semantics to Geth when using stateOverrides. Storage writes from a CREATE2 deployment within the traced call should be visible to subsequent operations in the same execution context.

Steps to reproduce

Repro script (Base Sepolia)
https://gist.github.com/vr16x/5a087e9e6ec064284c6f1032797e433b

Repro script (Eth Sepolia)
https://gist.github.com/vr16x/06fe7883c65b3c0167186cea656a1353

How to reproduce

1. Run either script against a Reth node -> observe 3 execution reverts
2. Run the same script against a Geth node -> observe 1 execution revert (expected)

The scripts use viem and count occurrences of "execution reverted" in the trace output.

Node logs

N/A - this is an execution-level divergence reproducible via RPC, not a node crash or sync issue. The repro scripts above demonstrate the bug directly.

Platform(s)

No response

Container Type

Other

What version/commit are you on?

Reproduced on Reth v1.10.2 and v1.9.3.

What database version are you on?

.

Which chain / network are you on?

Eth Sepolia, Base Sepolia, Optimism Sepolia. Affects all chains running Reth as the execution client.

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct

[jsvisa]

I think #22683 workaround can fix this issue, but why #22684 is closed cc @emmajam

[mattsse]

#22684 was rolled up to alloy-rs/evm#303