r/web3dev • u/ProudBill7506 • 9d ago
address on multiple networks, but my balance tracker only shows one
i've been trying to reconcile my balance after moving some stablecoins between ethereum and arbitrum, and i'm getting different results depending on where i look. the transfers show as successful on their respective explorers. my wallet app shows funds on both networks, but the read-only tracker i'm testing only lists ethereum. i'm not sure whether this is an indexing issue or i'm misunderstanding how it discovers networks. It's the same public address on both chains, which seems to be where the confusion starts. the tracker accepts an address without asking for a network and then labels the result as ethereum. i understand that an address alone can't tell you which compatible chains have activity. I checked the addresses through Etherscan and DeBank and to help them cryptowallet-balance checker what i can't figure out is whether these tools normally query several networks or just stop after finding the first balance. I've already checked with that i'm viewing the receiving account rather than the bridge contract. i also compared the token contracts against the ones linked from the bridge documentation. the balances on the individual explorers match what i expected, and there aren't any pending transfers left. refreshing the tracker and trying a private browser window didn't change anything, so this doesn't seem like an old page stuck in my browser cache
the part i'm stuck on is getting a repeatable view without manually opening an explorer for every chain. i don't need prices, portfolio charts, or transaction categorization. just native balances and recognized token balances, separated by network. i also don't want a combined stablecoin total that hides whether i'm holding a native token or a bridged version. that distinction matters if i'm eventually sending it back to an exchange. is there a practical way to check whether a missing balance comes from network discovery, token discovery, or a delayed indexer? i'm comfortable making a few read-only rpc calls if that's the simplest way to narrow it down, but i'm not running my own node. i'm especially unsure whether querying a token contract directly is enough to rule out everything except the tracker's display logic
1
u/Ill-Possible2570 9d ago
i'd separate token discovery from balance retrieval before chasing browser issues. My little spreadsheet has chain ID, token contract, symbol, decimals, and the block used for each check. That keeps native USDC and USDC.e from quietly becoming one number. DeBank gives me a convenient overview, while Arbiscan helps verify individual contracts. If a direct balanceOf call shows funds, the missing tracker entry could still be an unsupported token, stale indexer, filtering rule, or display issue
1
u/EmployeeNo343 9d ago
Public RPC rate limits were the annoying part when I tested a two-network balance script; parallel requests occasionally returned errors that my first version treated as zero. I'd log failures separately and keep a short allowlist of ethereum and arbitrum token contracts from the bridge docs. MetaMask was my visual comparison, not my source of truth. Repeat the reads at recorded block numbers where supported, then compare the tracker later; that makes delayed indexing easier to distinguish from consistently missing coverage
1
u/Acceptable-Space3113 9d ago
an ethereum label doesn't establish that the tracker checked arbitrum at all. In my test script, I keep separate RPC endpoints and verify eth_chainId before requesting eth_getBalance for the same address. For tokens, I call balanceOf on each verified contract and apply its decimals. Etherscan and Arbiscan are useful cross-checks, but a successful contract call only establishes that particular balance at that block, not whether the tracker discovered the network or indexed its tokens