Wrong balances returned for not completely processed blocks

[phil-k1]

We're observing a longer ongoing issue with querying balances by height close to the tip & were now finally able to narrow down the issue.

We're on latest v0.0.7-beta.

To investigate the issue, we took a look at a node which is currently lagging behind & catching up with the tip. It's currently in execution stage:

2026-02-27T06:27:54.537003Z  INFO Status connected_peers=5 stage=Execution checkpoint=82757511 target=83599716 stage_progress=99.41%

Looked up block 83599716 (the execution target, which is 0x4FBA164 in hex notation) on bsctrace.com and picked a random address that has a balance change in this block, picked 0x88a5e51b20ee623a4cdb945153a67ec75837b125.

Then fetched the balance for this height from the catching up node:

% curl http://localhost:8545/ --request POST --header "Content-Type: application/json" --data '{"id": 1,"jsonrpc": "2.0","method": "eth_getBalance", "params": ["0x88a5e51b20ee623a4cdb945153a67ec75837b125", "0x4FBA164"]}'

{"jsonrpc":"2.0","id":1,"result":"0x0"}

Compare this to the balance from a healthy node (which is caught up with the tip):

% curl http://localhost:8545/ --request POST --header "Content-Type: application/json" --data '{"id": 1,"jsonrpc": "2.0","method": "eth_getBalance", "params": ["0x88a5e51b20ee623a4cdb945153a67ec75837b125", "0x4FBA164"]}'

{"jsonrpc":"2.0","id":1,"result":"0x2672378b400"}

Also note that beyond the execution target, the catching up node correctly returns "block not found":

% curl http://localhost:8545/ --request POST --header "Content-Type: application/json" --data '{"id": 1,"jsonrpc": "2.0","method": "eth_getBalance", "params": ["0x88a5e51b20ee623a4cdb945153a67ec75837b125", "0x4FBA165"]}'

{"jsonrpc":"2.0","id":1,"error":{"code":-32001,"message":"block not found: 0x4fba165"}}% 

So it appears that the nodes return wrong balances for blocks that are already fetched, but not fully processed yet, whereas one would expect that it would throw the "block not found" error for all block heights above the highest fully processed block.

Note that we are raising this issue here because we were only able to pinpoint it for BSC Reth so far, but we observed similar issues on vanilla Reth for Ethereum, so it's probable that the issue applies to Reth in general.

[constwz]

Received. I will fix this error in the next version.

[phil-k1]

Maybe also worth mentioning that we tried to reproduce the issue for Base (Optimism Reth v1.11.0), and there it seems to be handled correctly, i.e. for blocks that are already fetched but not fully processed we get:

 % curl http://localhost:8545 --request POST --header "Content-Type: application/json" --data '{"id": 1,"jsonrpc": "2.0","method": "eth_getBalance", "params": ["0x1c2f19245ef2ec72cf368dc499f013632dfa3888", "0x285965E"]}'

{"jsonrpc":"2.0","id":1,"error":{"code":-32603,"message":"no state found for block 0x3930d8c2d73ed19de62765b52fcbea80aaebec57d835864dc0ec258fda084709"}}

[phil-k1]

Received. I will fix this error in the next version.

Thanks!

[phil-k1]

Hey @constwz 👋

Just saw that you pushed a fix for this issue & have a quick question on this: After opening this ticket, we noticed that we're running into a similar issue with debug_traceBlockByNumber (call traces seemingly based off a stale state) - do you think that this has the same root cause & will be addressed by your fix as well, or is this likely something different?

Edit: Looking at the code (state_by_block_number_or_tag calling state_by_block_hash (on the Number path) calling history_by_block_hash) it seems to me that it's indeed the same issue, but would still appreciate if you could double-check this 🙏

[constwz]

Hey @constwz 👋

Just saw that you pushed a fix for this issue & have a quick question on this: After opening this ticket, we noticed that we're running into a similar issue with debug_traceBlockByNumber (call traces seemingly based off a stale state) - do you think that this has the same root cause & will be addressed by your fix as well, or is this likely something different?

Edit: Looking at the code (state_by_block_number_or_tag calling state_by_block_hash (on the Number path) calling history_by_block_hash) it seems to me that it's indeed the same issue, but would still appreciate if you could double-check this 🙏

Hey @constwz 👋

Just saw that you pushed a fix for this issue & have a quick question on this: After opening this ticket, we noticed that we're running into a similar issue with debug_traceBlockByNumber (call traces seemingly based off a stale state) - do you think that this has the same root cause & will be addressed by your fix as well, or is this likely something different?

Edit: Looking at the code (state_by_block_number_or_tag calling state_by_block_hash (on the Number path) calling history_by_block_hash) it seems to me that it's indeed the same issue, but would still appreciate if you could double-check this 🙏

Received, thank you.