Account's state inconsistency

[infsaulo]

Problem

Account 0x1d2d5108e4979fa31d9F73ab955eCF6B00E436D3 has some inconsistency in its reported state.

At the first transaction ever reported where this address was involved - 0xf1496f187bda4e20951b55fbcdc7d6df3b3b71ca2f04f33c72a85f9c7899dac9, we see the account received 400FLOW.

However, when we check the second recorded transaction where the account was involved - 0x9290de18578d987b26a0dcf804c71df0ef5f9dcf61a6a0b818c8fdc9952bac80, this account is reported to have initial 0FLOW in its state change, and no FLOW is debited from its balance. As this address is a transaction caller, shouldn't the tx value of 125FLOW be debited from the initial 400FLOW?

Context

1. Running validation for accounts state changes on their FLOW balances found this potential issue.
2. Checking the history of transactions of the account 0x1d2d5108e4979fa31d9F73ab955eCF6B00E436D3, eventually the account's FLOW balance will be negative if we consider the debits/credits showed + the transaction's fees. (Let me know if I'm missing anything here)

[ramtinms]

I think the source of the issue might be the way blockscout populate state, for example, one issue I see is the mint address is set to 0x0000000000000000000000000000000000000000 which is wrong, it should be the miner address in my view 0x0000000000000000000000030000000000000000.

[infsaulo]

@ramtinms I'm attaching a quick manual ledger for the account, considering its transaction level history where I kept track of the account's FLOW balance over time and applying the balance changes. I've noticed in the last transaction reported we have the negative balance in FLOW for that account, lemme know if I'm missing anything that should be considered. But the logic to keep track of the accounts balance is based on the FLOW values received or paid in the transactions + fees reported.

Account 0x1d2d5108e4979fa31d9F73ab955eCF6B00E436D3 manual ledger.pdf

In fact this account holds atm 3 ERC20 tokens, and I've been collecting finer granularity info at the internal txs/calls but still can't find any additional footprint of FLOW balance changes other than the ones reported under the transaction level.

Regardless, I will keep posted if I find anything else that help us to understand.

[bjartek]

The blockscout coin_balance_cathup process is trying to get the balance for the minter address and it is failing to do so. So that might be why it has not updated other balances?
{"time":"2024-09-20T09:08:31.840Z","severity":"error","message":"failed to fetch: 0x0000000000000000000000030000000000000000@1385352: (-32000) failed to get balance of address: 0x0000000000000000000000030000000000000000 at height: 1385352, with: invalid height not in available range: 87390037\n","metadata":{"count":1,"fetcher":"coin_balance_catchup","error_count":1}}

[m-Peter]

The blockscout coin_balance_cathup process is trying to get the balance for the minter address and it is failing to do so. So that might be why it has not updated other balances? {"time":"2024-09-20T09:08:31.840Z","severity":"error","message":"failed to fetch: 0x0000000000000000000000030000000000000000@1385352: (-32000) failed to get balance of address: 0x0000000000000000000000030000000000000000 at height: 1385352, with: invalid height not in available range: 87390037\n","metadata":{"count":1,"fetcher":"coin_balance_catchup","error_count":1}}

Oh interesting find 💯 This is a know issue in the EVM Gateway, because we send Cadence scripts to Execution Nodes, that do not have that much history, or they may be from previous sporks, and we can't use these heights. We'll soon deploy an update to fix this, so bear with us 🙏

[j1010001]

The root-cause here is query that is for historical blocks that AN does not have anymore (form past upgrade) - this should be resolved once we have dry-run (local state index) implemented as part of onflow/flow-go#6539.